Threats
Confused deputy problem
definition
The confused deputy problem occurs when a program with legitimate privileges is manipulated by a less-privileged party into misusing that authority on the attacker's behalf.
In depth
The term dates to a 1988 paper by Norm Hardy describing a compiler with billing-file write access that could be tricked into overwriting that file for a caller who had no such right. The pattern generalises to any system where authority travels with the *component* rather than with the *request*, and it is the underlying shape of CSRF, of SSRF, and of a long tail of OAuth flaws.
An AI agent is an unusually good deputy to confuse. It holds broad standing authority — repository write access, a cloud credential, an internal API token, a database connection. It takes instructions in natural language. And it processes untrusted content from arbitrary sources as part of its normal operation. Every ingredient the pattern needs is present by design.
MCP adds a specific instance the specification calls out directly. A server that proxies to a third-party authorization server, using a single static client ID, can be induced to issue or reuse authorization in a context the user never intended — the proxy is the deputy, and its consent is mistaken for the user's. This is why the spec insists that servers must not accept tokens that were not explicitly issued for them, and why token audience validation is not an implementation detail.
The correct fix is architectural and unglamorous: bind authority to the request rather than to the component. Pass the user's identity through to the resource, scope credentials per task rather than per agent, require explicit consent for each dynamically-registered client, validate token audience at every hop, and require confirmation for actions whose authority exceeds the requester's.
Why it matters for governance
Most agent deployments get this wrong in the same way, and it is the fastest thing to check: the agent holds one broad service credential and every user's request borrows it. From the resource's perspective every action was taken by the agent, so authorization decisions cannot reflect who asked, and the audit log cannot answer who caused it. Per-user identity propagation and narrowly-scoped, short-lived credentials are the fix — and they are also what makes attribution possible after the fact.
Frequently asked
- How does the confused deputy problem relate to prompt injection?
- Prompt injection is a way to confuse the deputy. The privilege escalation comes from the agent's standing authority; the injection is just the mechanism for redirecting it.
- Why does the MCP specification call this out?
- Because a server acting as an authorization proxy is structurally a deputy. If it accepts tokens not issued for it, or relies on a static client ID to imply consent, an attacker can borrow authority the user never granted.
Sources
Primary sources for the claims on this page. Specifications and vendor documentation change — verify against the source if a detail is load-bearing for a decision you are making.