Agent governance

Admin → Agent governance is for owners and admins. It lists every call an agent made to the gate — the question "may I do this?" — newest first, and follows each one past the decision: whether the permission was used, revoked or withdrawn, and what the agent reported doing with it.

The tiles#

A gate's page#

Open a gate to see, in one place:

• What the permission covers: the destination, whether it is inside or outside the organisation, the data's classification, and the artifact by name, version and SHA-256 hash. View this version opens the exact report version beside the one before it, and records that you opened it.
• Authorisation: whether the agent may act now, until when, and how many uses are left. A permission covers one use unless its policy said otherwise.
• Policy: which policy version and rule decided it, and why.
• Approval: who was asked at each stage, what each person decided and under what authority — named, as a member of a role, or as the owner of the thing acted on — and whether they saw the same scope the permission is bound to.
• Receipts: what the agent reported, each marked verified (Deliverd carried it out), hash matched (the agent reported the approved artifact, and the hash was checked) or reported (the agent's word).
• What this record does not show: said in words, so nobody reads more into the record than it holds.

Download the evidence as PDF, JSON or CSV from the top of the page. The pack is built from the same rows as the page.

Revoking a permission

An approved permission nobody has used yet can be revoked from its page, with a reason. The agent is told, and a report of acting on it afterwards is refused. A permission that has been used cannot be revoked: what was done stands in the record.

Writing policy#

Policies is where owners and administrators write the rules. Each rule names what it covers — actions, the agent's platform, the data's classification, whether recipients are inside or outside the organisation, risk, whether there is an artifact — and what happens: it goes through, it is refused, or a person approves or reviews it, in one list or in stages asked in turn. A rule can also say how long a permission lasts and how many uses it allows. Rules are checked lowest priority first, and an action no rule matches goes to a person.

• Save as draft. Nothing you save is in force. A draft can be tried on a made-up request, showing what the rules in force say now beside what they would say with the draft.
• Review and activate. Activating shows every rule the draft adds, changes and removes, warns when it takes a person out of anything, and asks you to type the policy's name. The version it replaces stays readable.
• Switch a policy off to stop its rules applying at once. Nothing goes through because of it: what its rules covered goes to a person.
• Every save, activation and switch is in the audit log. The same rules can still be pushed with deliverd policy push or the API.

Templates#

Templates are common rules — restricted data stays inside, confidential data leaving needs its owner then Compliance, public publication needs approval, and others. Add as a draft registers any actions the template needs and adds its rules as a draft version of a policy. A draft is not in force: open it under Policies, change who approves, try it, and activate it. Templates are for owners and administrators.

What a permission is, and is not#

A permission here is your organisation's authorisation, and only that. The platform an agent runs on — ChatGPT, Claude, or your own — keeps its own confirmations and safety controls, and Deliverd neither replaces nor overrides them. Except where Deliverd carries the act out itself, what an agent did is what it reported, checked against what was approved.