Delegation chains, the confused deputy, and the protocols you actually deploy

Agents rarely act alone. A user asks an agent to do something. The agent calls a tool. The tool calls another agent. By the time work gets done, three or four actors have touched the request, each acting on behalf of the one before it.

Identity has to survive that chain. At every hop, you need to answer two questions, not one. Who originally requested this? And which actor is making this specific call? Lose either answer and you lose the ability to authorize the call correctly or explain it afterward.

Two claims carry the whole chain

The standards already model this. RFC 8693 defines token exchange: an actor trades the token it received for a new one to make the next call, without discarding who came before. The token carries two claims that matter here.

The sub claim is the subject, the original principal. It is the user who started the whole thing, and it does not change as the request moves down the chain.

The act claim is the actor, the party making the current call. It does change. And when one agent calls another, act nests: Agent B acting on behalf of Agent A acting on behalf of the user. Nested act is the only honest way to represent a multi-hop chain, because it keeps every link instead of collapsing them.

The failure mode has a name

The shortcut is to flatten the chain. Instead of exchanging tokens and nesting act, an agent re-mints a fresh token that says, in effect, “this is me, calling on my own behalf.” It is simpler. It also destroys the chain.

Now sub points at the agent, not the user. The original principal is gone. Attribution is gone with it: the downstream tool sees the agent and has no idea whose request set this in motion. And because the tool only sees the agent’s identity, it authorizes against the agent’s permissions, which are broader than what this specific task should allow. You over-grant on every downstream call.

This is the confused deputy: a process acting with authority that was granted to someone else, used for a purpose the grantor never intended. The flattened token is how the confused deputy gets created in an agent system. The preserved chain is how you avoid it. The difference is whether you can still inspect, at the tool, who asked and who is acting.

Where the chain lives or dies in practice

This is not only a standards story. The chain is preserved or destroyed at two protocol surfaces the primary audience is deploying right now.

Agent to tool runs over the Model Context Protocol (MCP). The mid-2025 MCP spec adopted OAuth 2.1 and RFC 9728 protected-resource metadata. That matters because it lets an agent discover what authorization a tool requires instead of hardcoding it. The agent reads the resource’s metadata, learns where to get a token and what scope it needs, and asks for exactly that. Discovery is what makes scoped, per-tool authorization practical at runtime.

Now the deployed reality, because the spec is not the same as what is running. A large share of MCP servers in the wild ship with weak or absent authorization. The protocol supports doing this correctly. Many deployments do not. That gap is the entire subject of this series: the standards exist, and the systems built on top of them skip the parts that protect the chain.

Agent to agent runs over A2A and its Agent Cards. An Agent Card is a discoverable declaration of what an agent is, what it can do, and which authentication schemes it accepts. It is how one agent learns how to call another without a human wiring the two together in advance. The card is also where an agent advertises whether it expects a delegated token or will happily take anything. Read the cards in your ecosystem. They tell you where the chain is respected and where it is about to be flattened.

These two surfaces, MCP and A2A, are the concrete places the delegation chain is either inspectable end to end or quietly collapsed into a token that lies about who is acting.

The take-away

Delegation is not a token handed down the line. It is a chain, and a healthy chain is one you can inspect at every hop: sub fixed on the original principal, act nested through every actor that touched the request. Flatten it and you have built a confused deputy that over-grants and cannot be audited.

In your own systems, the chain is preserved or lost at MCP and A2A. Check two things. Do your agents exchange and nest tokens, or re-mint flat ones? And do the MCP servers and Agent Cards in your ecosystem actually require delegated authorization, or do they accept whatever shows up?

You can now describe an agent, give it an identity, and carry that identity through a chain of calls. The next question is where the rules for all of this live. Who decides what an agent is allowed to do, and what happens the moment an agent has to act somewhere its own platform does not reach? That is the next post.