Confused deputy problem

The confused deputy problem is what happens when a program holding legitimate credentials is tricked into using its own authority on someone else's behalf. The deputy is not compromised and its credential is not stolen. It is asked to do something, it holds the permission required, and nothing checks whether the requester was entitled to that outcome. The tool validates the credential, never the legitimacy of the request.

Norm Hardy named the pattern in a 1988 paper, and it has been reactivated almost verbatim for AI agents. SC World argued in May 2026 that the underlying problem is 38 years old and that the identity fixes shipped for the Model Context Protocol do not touch it, noting that the confused deputy is no longer a compiler. MCP Blog placed the same problem at the heart of MCP's authentication model in March 2026, and June 2026 arXiv work on intent-guarded agent control positions itself against this gap.

The original problem

Hardy's example was a compiler on a shared timesharing system. The compiler ran with a privilege its users did not have: write access to a billing file, so it could record usage. Users invoked it with an input file and an output filename, and nothing stopped a user from naming the billing file as the output. The compiler dutifully wrote there, because it genuinely held that permission, and the billing records were destroyed.

What makes the story durable is where the flaw sits. The user had no write access, the compiler's access was correct and necessary, and the authentication worked. The bug was that the compiler conflated two authorities, its own and its caller's, and used the wrong one to satisfy a request it never examined. Every later instance has the same shape: an intermediary with more power than its caller, and no mechanism binding an action to the caller's entitlement.

Why AI agents make unusually good deputies

An AI agent is an intermediary by design. It is deployed because it can reach systems the person talking to it cannot, and it is given broad scope because narrow scope means constant escalation. A support agent with read access across the entire CRM can answer any customer's question, which is the point, and can also read any customer's record, which is the problem.

Three properties make agents worse deputies than the 1988 compiler. Their instructions arrive in natural language, so the boundary between a request and an injected command is blurry rather than syntactic, and prompt injection turns any text the agent reads into a candidate instruction. They act across many systems in one session, so one confused decision can move data between security domains. And they are cooperative by training: a model optimized to be helpful looks for a way to satisfy an unusual request rather than refusing it, close to the opposite of the posture a deputy should hold.

The concrete version is mundane. An agent with broad CRM scope, asked by one customer to look up "my order," can be steered by a plausible-sounding message toward an identifier belonging to a different customer. The lookup succeeds, the credential was valid, and the access log shows an authorized read.

How it shows up in MCP and tool-calling architectures

The pattern surfaces at every layer of a modern agent stack. In tool calling, a function like get_order accepts an order ID and returns the order, and the agent holds a service credential authorized for all orders. Whether this order belongs to the authenticated customer is a question the function usually does not ask, because in its original life it was called by application code that had already checked.

In Model Context Protocol deployments the gap widens, because a server sits between the agent and the underlying system and typically authenticates with its own credential rather than a delegated one. Two identities now separate the customer from the data, and neither knows who asked. Add multi-agent delegation, where a router hands work to specialist agents that hand work to tools, and the caller's entitlement is several hops removed from the credential that finally executes. MCP tool poisoning manufactures this condition deliberately: the attacker supplies the instruction that makes the deputy misuse its authority.

Why authentication fixes do not solve it

Most of the security work on agent protocols in 2026 has been authentication and authorization work: proper OAuth flows, resource indicators, token audience restrictions, clearer separation between authorization and resource servers. That work closes real vulnerabilities, particularly token passthrough and token reuse across services.

It does not address this problem, because authentication answers who is calling and authorization answers whether that caller may perform this operation. The confused deputy scenario passes both. The agent is who it claims to be and it is permitted to read customer records. The missing check is a third one neither mechanism performs: whether this operation, on this resource, is what the initiating party was entitled to ask for. No credential contains that answer.

Mitigations that actually narrow the gap

Capability-scoped, short-lived tokens. Instead of one credential authorized for every record, mint a token at the start of an interaction scoped to the authenticated customer's resources and expiring with the session. The deputy then cannot exceed the caller's entitlement even when instructed to. This is the closest thing to a real fix, and it requires cooperation from the systems being called.

Per-request authorization inside the tool. Push the ownership check into the function rather than assuming the caller performed it. A get_order that takes both an order ID and a session-bound customer context, and refuses mismatches, is immune to this class regardless of what the model was told.

Intent validation at the action boundary. AI intent validation compares the proposed action against what was actually requested, which is precisely the check the deputy skips. Paired with tool-call guardrails that verify target records against the party in the conversation, it turns the missing question into an enforced one.

Narrow tools and attributable identities. A tool that does one thing to one kind of resource is a weaker deputy than a general query interface, and giving each agent and server its own non-human identity with a traceable delegation chain makes misuse attributable after the fact. Neither eliminates the problem. Together with scoped credentials they reduce it from a systemic weakness to a bounded one, which given the age of the problem is a reasonable target.