Guide · agent authorisation
Policy-based authorisation before an AI agent acts
What you want is for your organisation's rules to be asked before an agent does something consequential, for the answer to be allowed, refused or a named person decides, and for every answer to be on the record. That is authorisation at the moment of action, and it has two halves: the policy that settles the routine cases, and the person who settles the rest.
Three questions the check answers
| Question | Example |
|---|---|
| May this agent call this tool at all? | The support agent may read orders but never issue refunds. |
| May it, with these arguments? | Refunds under €200 go ahead; anything larger needs someone. |
| Who decides when the rules do not settle it? | A refund over €2,000 goes to the finance lead, who answers from their phone. |
The building blocks
- A decision point the agent calls before it acts, with the action and its arguments.
- Policy written by people, never by the agent: roles, attributes and conditions on the arguments.
- A default for what no rule covers. Deny, or ask a person — never allow because nobody thought about it.
- A check where the action runs: a hook, a gateway, or a token the tool verifies, so it does not rely on the model choosing to ask.
- A record of every decision, the rule behind it, and what ran afterwards.
Tools for the policy half
Open Policy Agent (policy in Rego), Cedar, Cerbos, OpenFGA and Permit.io are authorisation engines: they answer from policy, quickly, whether a principal may perform an action on a resource, and several run as a local decision point beside your service. They are the right tool for fine-grained permissions across an application. Asking a named person is not what they are built for.
Where a person comes in
Some actions should never be settled by policy alone: they are rare, expensive, irreversible, or the rule would need judgement. For those the right answer from the check is not yes or no but a person decides — the agent waits, the person who owns the decision is asked where they are, and their answer comes back as the decision. The policy and the person should write to the same record.
How Deliverd does it
In Deliverd an agent declares the action at a gate before it acts, with its arguments, and gets one of three answers: allowed, refused, or a named person decides. Rules on registered actions, included in Business Starter, Business and Enterprise, settle the routine cases with conditions on the arguments; an action no rule covers goes to a person; and the organisation's ethics rules can send an allowed action to a person but never let a refused one through.
Agents cannot write the rules or register actions. A call the gate lets through can carry a signed decision token that the tool verifies before acting, and a hook in a coding agent can make the check outside the model. Every answer, the rule behind it and what ran are recorded and export as evidence. It sits beside an authorisation engine rather than replacing one: the engine for permissions, Deliverd for the actions a person should own.
Questions
- What does Deliverd do with an action no rule covers?
- It sends it to a person. Nothing is allowed because nobody wrote a rule about it.
- How is this different from Permit.io or Open Policy Agent?
- Those decide from policy whether a caller may act, across an application. Deliverd decides who has to say yes to a consequential action, reaches them, and keeps the record. Many teams use an engine for permissions and Deliverd for the actions a person should own.
- Can an agent change the rules?
- No. Registering actions and writing rules refuse an agent's key, and writing rules also needs an owner or administrator.