Mandates, not permissions: how organisations should delegate to AI agents

When organisations give an AI agent something to do, they usually give it permissions: a service account, a role, a set of scopes. That is how software has always been connected to systems, so it is the natural place to start.

But delegation to a person has never worked that way. When a manager asks someone to pay suppliers, the delegation carries a purpose, limits, an owner and an end date, and everyone understands that it can be withdrawn. This article argues that agents need the same structure, which we call a mandate, and describes what a good one contains.

Permissions answer the wrong question

A permission answers can this identity call this operation? It is static, broad and attached to the agent.

That causes three problems once agents act on behalf of people.

Permissions do not say who the agent acts for. An agent with a service account acts as itself. When it changes a record, the log names the agent. It rarely names the person or team whose intent it was carrying out, so accountability is lost exactly when it is needed.

Permissions are broader than intent. A role that lets an agent update supplier records lets it change any field on any supplier. The intent might have been keep contact details current for our top suppliers. The permission cannot express that, so the gap between intent and capability is simply left open.

Permissions outlive the reason for them. When the person who set up an agent leaves, their account is closed. The agent's credentials usually are not, because they were never tied to that person. The employee left; the agent did not.

The security community describes the result as "excessive agency": agents with more functionality, permissions or autonomy than their task needs (OWASP LLM06:2025). Tightening permissions helps, but permissions alone cannot express purpose, limits per action or a link to the person who delegated.

What a mandate is

A mandate is an explicit, versioned statement of delegated authority. In plain terms it records:

• Who delegates. The principal: the person or team the agent acts for, and who remains accountable.
• Who acts. The agent, as a separate, named party.
• What may be done. The capability, described as an action on a target, such as update supplier contact details rather than write to supplier master.
• Within which limits. Amounts, fields, counterparties, time windows, and which actions need a person's approval.
• Until when. An expiry, and the ability to revoke at any moment.

The important difference from a permission is that a mandate is checked per action. Each time the agent proposes something, the question is not can it reach this system? but does a current mandate cover this exact action, for this principal, right now?

Revocation has to bite immediately

A mandate that can be revoked but whose revocation takes effect "eventually" is not much better than a permission.

In Delegrity, each mandate carries a revision and an authority epoch. Revoking or changing a mandate moves its epoch. A decision made under the old epoch no longer covers the action, even if it was made a moment ago and the agent is mid-flight. The agent's identity and token remain valid throughout; it is the authority that has gone.

This matters most for the cases people worry about: someone leaves, a supplier relationship ends, a workflow is paused after an incident. In each, you want the next action to stop, not the next credential rotation.

Mandates make approvals meaningful

Mandates also decide when a person must be involved. A good mandate does not require approval for everything, which trains approvers to click through. It requires approval where the consequence is high: a new payee, an amount over a threshold, a change to bank details.

When approval is required, it should be tied to the exact action. In Delegrity the approval is bound to the action's digest, and the action is rechecked against the approved snapshot just before it runs. If anything material changed, no execution authority is issued. Our article on the beneficiary-swap problem covers this in detail.

Keep the systems you have

Moving from permissions to mandates does not mean replacing your identity provider or your policy engine.

• Your identity provider still says who the agent is and who the principal is.
• Your policy engine still holds organisation-wide rules. Delegrity consults it through an AuthZEN-compatible call and records the consultation. The OpenID AuthZEN working group exists to standardise how authorisation information passes between such components (OpenID AuthZEN).
• Your approval channel is still where people approve.

The mandate is the layer that joins them for one action: this agent, acting for this principal, under this mandate, approved for these exact fields, at this moment.

Writing your first mandate

Start with one agent and one consequential action. Write the mandate down before you write any configuration:

1. Name the principal who is accountable for the action.
2. Describe the action as narrowly as you honestly can.
3. List the limits, and mark which ones require a person's approval.
4. Set an expiry, and decide who can revoke it.
5. Decide what evidence you want for each action, and who will read it.

If you find you cannot write one of these down, that is useful to know before an agent acts on it, not after.

Delegrity is at design-partner stage. It has no production customer evidence and no independent certification yet.