Governance
Six controls that keep agents in bounds
Governance you can only describe in a prompt is not governance. In Zahen the rules sit in the execution path: the agent cannot read past a permission, cannot widen its own scope, and cannot do anything consequential until a person has said yes and that yes has been recorded.
A prompted rule is a request, not a control
“Always ask before sending” in a system prompt is a request. A model under pressure, a very long context or a carefully worded input will eventually not ask — and you will find out afterwards.
So none of the six controls below live in a prompt. They are checks in the path an action has to travel: the agent proposes, the runtime decides, and where the runtime says no there is no way through — including for us.
The six controls
What is enforced, and where
-
Permission-filtered retrieval
Access control is applied before the search runs, not after it. A document the requester may not open is never a candidate, so it cannot leak out through a summary or a citation.
-
Approval before consequence
Actions are classified by risk. A high-risk one suspends the run, hands out the exact draft it would execute, and waits. No decision means no action — the run is parked, not abandoned.
-
Separation of duties
The invoker cannot be the approver. Zahen checks the signed decision against who started the run and rejects a self-approval, even where the surrounding system would have permitted it.
-
Scope that only narrows
A run's scope is typed and fixed when it starts, and can only be reduced. There is no path by which an agent, a tool or an injected instruction widens what this run may touch.
-
Credential-free tool calls
Zahen holds no keys to your systems. Every tool call goes back to your application, which re-authorizes the named requester against live data before it answers or acts.
-
Append-only audit
Every retrieval, proposal, decision and system call is written once. Records are not editable by an operator or by us, and the trail exports for a reviewer who was never in the room.
The approval gate
What a person actually sees, and when
- 01
The agent proposes
The model returns an intended action rather than a completed one. At this point nothing has happened in any of your systems.
- 02
The runtime classifies it
Low-risk reads carry on. Anything with an effect outside the run is gated, by your policy rather than the model's judgment.
- 03
The run suspends
State is checkpointed durably, so a gated run can wait minutes or days — across a restart — without losing its place.
- 04
A person sees what would happen
The draft is handed out with a hash of it, so what the approver read is provably what would execute, rather than a paraphrase of it.
- 05
The decision comes back signed
Approve, edit and approve, ask for more information, or escalate. The decision is bound to that specific approval on that specific run, and cannot be replayed onto another.
- 06
Zahen acts, or refuses
On approval it executes through your systems and records it. Without one it does not proceed. Either way the trail says what was decided, by whom, and when.
What we claim, and what we do not
Each deployment is isolated. Secrets are scoped to the tenant that owns them. Customer data is not used to train or fine-tune models. The audit trail is yours to export, and removing a tenant leaves a tombstone rather than a silent hole, so the deletion is auditable too.
And the other half of the answer: Zahen holds no third-party security certification today, and we will not imply one. What we will do is tell your risk team exactly which controls are implemented, which are on the roadmap, and which do not exist — in writing, before you commit to anything.
A vendor who overstates its controls is the specific risk this product exists to remove. It would be a strange way to start.
Talk to the team that built it
Bring the workflow you would not let an unsupervised agent near. That is the one worth governing first.