← Blog

Your Agent Has Credentials, Not Authority

Many autonomous AI architectures I look at are reproducing a failure mode that has been named in the security literature for almost forty years, and reproducing it without seeming to notice. The failure mode is the confused deputy. The framing was Norman Hardy’s, in 1988. The shape, almost forty years later, is the same.

Hardy described a compiler service that needed to write to a system billing file in order to log compilation charges — a perfectly legitimate part of its operation. A user invoked the compiler and specified the billing file as the destination for compiler output. The compiler wrote to it. The compiler had permission. The user did not. At the moment of the write, the system could not distinguish between the compiler writing to the billing file for its own purposes and the compiler writing to the billing file on behalf of a user who should never have had access. The compiler’s infrastructure permission was treated as authority for any action it was asked to perform, regardless of who was asking or why.

User no billing access invokes Compiler the deputy has write permission Billing File restricted resource user-directed output own billing charges at the write boundary these two operations are indistinguishable The system checks permission, not whose authority the write serves. Both paths succeed. Only one is authorised.
The Confused Deputy. The compiler has legitimate permission to write to the billing file. A user directs the compiler's output to the same file. At the write boundary, the system cannot distinguish between the two operations, and both succeed.

Hardy called this the confused deputy. The deputy in this case was the compiler; what it was confused about was whose authority it was exercising.

I find this useful as a lens on the current AI stack because many autonomous AI systems are deputies by construction. They receive instructions, reason about them, and act through tools and services that carry infrastructure privileges: database credentials, API keys, service accounts, network access. Without an explicit delegation that says “this principal authorises this system to take this kind of action under these conditions”, the system derives its authority from what it can do. A tool connector with database admin credentials will execute any query the model requests, because the connector is authorised at the infrastructure level. Whether the workflow that asked for the query is itself authorised to read or change that data is a separate question, and in many architectures no component asks it.

Identity Is Not The Same As Authority

Many teams answer the question “is this identity permitted?” reasonably well. They authenticate, check role membership, and confirm credentials. The question they do not answer, and the question the confused-deputy framing has been asking for nearly four decades, is the one that matters at the action boundary: is this specific action authorised, under this specific delegation, right now, against this specific target?

Identity tells you who is acting. Delegation tells you why this actor is permitted to take this action, under whose authority, within what scope, with what constraints, and until when. Conflating the two is how systems built with serious access control still end up taking actions no human ever authorised.

Delegation Has To Constrain Authority

The minimum shape of a delegation is one that constrains authority along four properties. These are not optional refinements. If any one of them is missing, the artefact may still carry useful information, but it is not, in the relevant sense, a delegation.

The first property is scope. The delegation specifies what actions are authorised and against what targets. A delegation to read customer records does not authorise their deletion. Scope is the boundary of authority, not the boundary of capability.

The second is time. Authority is not permanent, so the delegation has an expiry. A delegation granted for a particular task expires when the task completes or when the time bound elapses, whichever comes first.

The third is revocation. The delegation can be withdrawn before it expires, and revocation must itself be verifiable. In practice that means the revocation status has to be checkable with freshness bounds. If revocation status cannot be confirmed, the delegation should not be treated as valid.

The fourth is chain traceability. Every delegation traces back to a human principal through a chain of explicit grants. Each link narrows scope, because no delegator can grant broader authority than they themselves hold. The chain is the provenance of authority, and without it there is no answer to the question of whose authority any particular action is being taken under.

In capability-security terms, authority is not a property of identity. It is carried by explicit, transferable and constrained artefacts that exist separately from the credentials any one party happens to hold.

Ambient Authority Makes Deputies Confused

The opposite of explicit delegation is ambient authority: authority that is available simply because the system exists in an environment where it is permitted to act, and that takes shape in infrastructure credentials, service accounts, shared API keys, and the inherited permissions of the deployment context.

Ambient authority is a common default in autonomous AI systems I have looked at. The system’s authority is, in effect, whatever its deployment environment allows. Nothing else limits it: not a scoped delegation, not an expiry, not a revocation surface that another party can call.

Confused deputies are manufactured this way, not through malice or exotic misconfiguration, but through the simple absence of explicit delegation. When every action is implicitly authorised by infrastructure privileges, no action is specifically authorised by anyone.

The Structural Consequence Is Unbounded Capability

Without delegation, there is no answer to the question governance exists to answer: under whose authority was this action taken?

The system has credentials and can prove its identity. But identity tells you who acted. Delegation explains why this actor was permitted to act, under whose authority, within what scope, until when. An autonomous AI system with credentials but no delegation is a deputy that cannot distinguish its own authority from anyone else’s; it will act on whatever it is asked to do, constrained only by what the infrastructure happens to permit.

Credentials let the system act. Delegation explains why this particular action may be taken. Without that second artefact, every consequential action the system takes is resting on assumption, and the confused-deputy literature has been telling us for forty years what assumption does at the action boundary.