Skip to content

Authorization at Agent Scale

Coadaptive Layer · Chapter 05

This chapter extends: SF² Investment Portfolio (Section 04) · Platform Effects, SF² Process Stewardship (Section 02). Scope: the confused-deputy problem in MCP and agent-mediated workflows.

The authorization failures showing up in agent systems are a forty-year-old problem wearing new clothes. The confused deputy, named by Norm Hardy in 1988, is the correct lens for almost everything going wrong in MCP and agent-mediated workflows, and the reason the usual fixes do not work is that OAuth and RBAC were built for a human delegating to a program rather than a program delegating to another program three hops down a chain no human is watching.

The confused deputy problem (Hardy, 1988)

Hardy's original case is a compiler with elevated permissions. A user asks it to write debugging output to a file they name, the compiler dutifully writes there using its own authority, and the user names a system file they should never have been able to touch. The compiler was confused rather than compromised, holding authority for one purpose and getting tricked into wielding it for another. The deputy did exactly what it was told, with permissions that were never the caller's to spend.

The pattern generalizes to any system where one component acts with its own authority on behalf of a less-privileged caller. That is the exact shape of an agent calling a tool, a tool calling a service, a service reaching data. Each hop carries the authority of the actor rather than the requester, and somewhere down the chain a request gets honored with privilege the original asker never had. Every agent that acts on behalf of a user is a deputy, and a deputy is one crafted request away from being a confused one.

Why OAuth and RBAC don't address agent-to-agent

OAuth and RBAC both assume a human at the boundary. OAuth delegates a user's consent to an application; RBAC gates actions by the role of the person performing them. Both answer the question "is this human allowed to do this," and both fall apart when the actor is an agent acting for another agent acting for a user who has gone to lunch. Roles do not compose across hops, and consent granted once at the top of a chain says nothing about what the fourth agent down should be allowed to do with it.

The correction is to attach authority to the request rather than to the actor. A capability travels with the request, names exactly what may be done with it, and narrows at every hop so each deputy can pass along less than it holds but never more. This is not hypothetical: it is how macaroons work, where any holder can append a caveat that further restricts a token and none can broaden it, and it is how Fly.io and AWS STS already scope delegated credentials in production. It is the same capability model Boundary Enforcement argues for at the substrate, applied to the delegation chain: authority that flows with the work and shrinks as it moves, instead of roles that sit still while requests move past them.

This does not make the actor's identity irrelevant. You still have to know which agent is which, and scoped machine identity, the way SPIFFE and SPIRE hand each workload a short-lived cryptographic credential, is how a deputy proves it is the one it claims to be. Identity is necessary and not sufficient: it says who the actor is, never how much it should be able to spend three hops down the chain. That bound is what attenuation provides and identity structurally cannot, which is why the CSA's agent identity framework pairs a verifiable identity for the durable agent with scope-limited, time-bound grants for what it may do. Scope the actor and attenuate the capability: the first names the deputy, the second holds the line. Attenuation can only narrow because the layer that checks the caveat sits outside the deputies passing the token, and that invariant holds for as long as no holder can reach the verifier itself, the same reachability condition that dates the substrate guarantee in the three-layer model.

The confused deputy and authority attenuation along a delegation chain A delegation chain runs left to right: caller, agent, tool or MCP server, service, data. The top band shows actor authority under OAuth or RBAC, which sits still: each deputy acts with its own broad standing authority rather than the caller's, so somewhere down the chain a request is honored with privilege the original asker never had. That is the confused deputy. The bottom band shows the correction: a capability attached to the request, which narrows at every hop. Each deputy can pass along less than it holds but never more, drawn as a wedge that tapers from left to right. Attenuation can only narrow because the layer that checks the caveat sits outside the deputies passing the token. Callerless privileged Agentdeputy Tool /MCP server Servicedeputy Data The confused deputy: actor authority sits still OAuth and RBAC ask "is this human allowed?" Each hop carries the authority of the actor rather than the requester. broad standing authority, unchanged at every hop → one crafted request is honored with privilege the caller never had The correction: capability attached to the request, narrowing per hop A capability travels with the request, names exactly what may be done, and shrinks at every hop. Each deputy passes along less, never more. full grant least narrows at each hop; macaroon-style caveats let any holder narrow the token, none broaden it Why attenuation can only narrow The layer that checks the caveat sits outside the deputies passing the token. The invariant holds for as long as no holder can reach the verifier itself.
Under OAuth and RBAC the actor's authority sits still at every hop, which is the confused deputy. The correction attaches a capability to the request that can only narrow as it travels down the chain.

MCP and the modern instantiation

The Model Context Protocol is the current canonical case, because it standardizes exactly the moment authority changes hands: an agent reaching a tool or data source through a server. MCP gets the plumbing right and the authority model is where the risk concentrates. A server that holds broad credentials and serves whatever an agent asks is a confused deputy by construction, and the agent asking may itself be acting on injected instructions from the input surface.

The design implication for anyone building agent platforms is to treat every server and every tool as a deputy that must be scoped rather than trusted. Give it the narrowest capability that lets it do its job, make authority flow with the request so it cannot be reused for another, and assume the caller may be confused or compromised. Scoping a deputy at design time costs little; discovering the confused deputy unscoped in an incident review costs a great deal.

See also