Access is not authority: why valid tokens still allow wrong actions

Most security reviews of an AI agent ask three questions. Is the agent who it says it is? Is its token valid and correctly scoped? Is the connection to the tool trusted? These are good questions, and an agent can answer yes to all three while doing something your organisation never agreed to.

What access controls actually prove

Identity, tokens and connections establish access: which systems an agent can reach and which operations it may call. They are built to answer who is this, and what can it touch?

A token is the clearest example. The OAuth bearer token specification defines a bearer token as "a security token with the property that any party in possession of the token (a 'bearer') can use the token in any way that any other party in possession of it can" (RFC 6750, section 1.2). That is a statement about possession, not intent. A valid token says nothing about whether this particular call, with these arguments, is one the organisation wants made today.

Scopes narrow the set of operations, but they stay coarse. A scope such as "update supplier records" covers changing a phone number and changing the bank account that receives payments. Those two actions carry very different risks, and the token cannot tell them apart.

An ordinary example

Imagine an agent that keeps supplier records up to date from incoming email. It has a workload identity, a token scoped to the supplier-master system, and a trusted connection. One morning it reads an email asking for a supplier's bank details to be changed, and it prepares the update.

Every access check passes:

• The agent's identity is valid.
• The token is valid and covers supplier updates.
• The connection to the system is trusted.

Now ask the questions that matter to the finance team:

• Does the person this agent acts for still stand behind it? Perhaps they moved team last week.
• Does any mandate cover changing bank details, or only contact details?
• If someone approved this change, did they approve this account number, or just "a supplier update"?
• If the change runs, will anyone be able to show afterwards exactly what was authorised and what happened?

None of these is an identity question, and no token can answer them. They are questions of authority: whether this exact action is still authorised, at the moment it would run.

Why the gap is getting wider

Before agents, the gap between access and authority was mostly covered by people. A clerk with access to supplier records still knew not to change bank details on the strength of one email. Their judgement filled the space between "can" and "may".

An agent does not bring that judgement with it. It acts on instructions, and it can act many times a minute. The security community has started to name this risk. The OWASP Top 10 for LLM applications lists "excessive agency" and traces it to excessive functionality, excessive permissions and excessive autonomy. One of its mitigations is to "require a human to approve high-impact actions before they are taken" (OWASP LLM06:2025).

Approval helps, but only if it is tied to the action that actually runs. An approval given to a request type, rather than to an exact set of fields, can cover something the approver never saw.

The extra question: is this exact action authorised, now?

An authority check sits between the agent and the system it is about to change. It does not replace identity, tokens or policy. It consults them, then asks the per-action question they were never designed to answer.

In Delegrity, that check has four stages.

1. Bind. The request is normalised into one exact action and given a deterministic fingerprint, called the action digest. The same record names the agent, the person or team it acts for, and the mandate that covers it.
2. Decide. The mandate is checked, your policy engine is consulted (Delegrity speaks an AuthZEN-compatible policy consultation, so your engine stays the decision point), and where a person must approve, the approval is bound to that exact digest.
3. Grant. Just before execution, authority is resolved again and the approved action is compared with the one about to run, field by field. Only if nothing material changed is single-use execution authority issued.
4. Prove. A receipt is produced over a hash-chained evidence record, so a reviewer can later check what was authorised, by whom and on what basis.

In the supplier example, the mandate might cover contact details but not bank details, so the request stops at Decide. Or the change might be approved, and then the account number differs at Grant, so no execution authority is issued. Either way, the agent's identity and token stay valid. Authority is what changes.

What this does not replace

An authority check does not authenticate agents; your identity provider still does. It does not write your policies; your policy engine still decides. It does not make a careless mandate safe; it makes the mandate explicit and checkable.

What it adds is a record tying each action to its principal, mandate and approval.

A practical starting point

You do not need to put every agent action behind an authority check. Start with one action that can move money or change who gets paid, and ask four questions of it:

• Who does the agent act for, and how would you know if that changed?
• What mandate covers this action, and what does it exclude?
• What exactly does an approver see, and is their approval tied to those exact fields?
• What evidence would you show an auditor afterwards?

If the honest answer to any of them is "the token allows it", you have found the gap between access and authority.

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