Diwan — the control plane

What if it goes wrong?

The right question. Here is the machinery that answers it. Diwan (ديوان — historically the register, the chancery) is the control plane every agent on the platform answers to. It is deterministic on purpose: it behaves the same way every time, independent of anything the agent decides.

The permission model

An action is allowed only where three things intersect:

effective permission = what this agent is provisioned to dowhat this person can authorizewhat policy allows right now

Not one gate — three, and all of them outside the agent's reach.

Capability by provisioning

An agent that isn't provisioned for a capability categorically cannot use it — enforcement by absence, decided in a registry the agent cannot edit. A separate out-of-band process registers each agent and its toolset; the agent never holds the keys to its own provisioning. There is no screenshot of this mechanism, and that is the point: what was never granted has no surface to show.

Identity on every action

Every agent acts under its own credentialed identity — a service principal, distinct from every human and every other agent. When an agent acts for you, the action carries that chain. Nothing in the ledger is anonymous.

A work item's activity line reading 'fahim created the issue' — the agent attributed by name in the product itself
Attribution in the product itself — “fahim created the issue”, by name, in the activity line.

Secrets out of reach

Credentials for your CRM, email, and calendar live on the platform's infrastructure, scoped and revocable — never inside the agent's context. Revoke a credential and the resource stops answering. The agent can't leak what it never held.

Portal integrations — Gmail, Google Drive, and Microsoft connections, each private to the person who granted it
Connections live on the platform, scoped per person — grant them, revoke them, and the agent never holds the keys.

Policy on every call

Every tool call is evaluated against version-controlled, testable policy — the same evaluation every time. The outcomes: allow, deny, narrow (run with constrained arguments), or escalate to a human. If the policy engine is unreachable, sensitive actions fail closed.

Diwan's all-time obligation mix — 6,772 calls allowed, 278 escalated to a human, 0 denied, with the OPA policy sidecar reporting healthy
Every call lands as a policy outcome — 6,772 allowed, 278 escalated to a human, 0 denied. The policy engine reports its own health.

Approvals that actually wait

Consequential moves route to the right human on the channel they already use. The agent doesn't freeze — the work pauses at the gate; the human decides; the work continues. An approval nobody answers leaves the task paused, not abandoned.

The Diwan approvals queue — two escalations held awaiting a human, with Approve and Deny buttons, resolved history below
Consequential moves pause here and wait for you — Approve and Deny are real buttons.

An audit ledger you can read

Who, what, when, with which arguments, under which decision, with what outcome — append-only, queryable. When your auditor asks “what did the agent do, and was it allowed?”, this page is the answer's address.

The Diwan dashboard — 7,051 decisions in the ledger, a 14-day decision trend, obligation mix, fleet status and spend
7,051 decisions on the record — every action, attributed and timestamped, in the ledger you can read.

The honest trust boundary

Gates govern participating agents. The hard teeth are the credentials: a governed resource only answers to a platform-issued, scoped, revocable credential. Run an agent inside the platform and here is exactly what it can touch, every move logged, dangerous moves gated. Run one outside it — and it still can't touch what we protect.

You don't have to trust the agent. You have to trust the fabric — and the fabric is deterministic.

Bring your security reviewer.

Get StartedArchitecture depth