Confused deputy: your agent, spending your authority

The confused deputy is one of the oldest ideas in computer security: a program that holds authority its caller lacks, tricked into spending that authority on the caller's behalf. The deputy is not compromised; it is confused about whose request it is serving. Nothing is broken into, because the door was opened by someone with a key; the wrong someone asked them to.

An AI agent is this problem with better manners. It holds your grants (mail, files, repositories, calendars) and it takes requests in natural language from everything it reads. Prompt injection is exactly the confused-deputy trigger: an instruction arriving through a document, and a deputy that cannot reliably tell your voice from the document's.

Aggregation is what makes agents the worst case

The classic deputy held one authority. An agent session holds the union of every connector you attached, simultaneously, in one place where a single piece of hostile text can reach all of them.

That union is a new thing. Your mail provider never had your repository token; your calendar could not read your customer files. Each grant was scoped to a service that only did one job. The agent session is where they meet, and the blast-radius question "what could this accomplish if it went wrong" has to be asked about the combined set, because that is what one injected instruction can drive. Read-here plus write-there is the exfiltration shape, and aggregation manufactures such pairs by default.

The user-level defence is refusing the aggregation, not detecting the trick: connectors attached per task rather than permanently, separate sessions for separate trust domains, and the standing rule that the everything-connected convenience session is an incident with good ergonomics.

The protocol-level version, for builders

The MCP specification documents the same problem one layer down, in OAuth plumbing, and its security-best-practices page is the reference this page follows. The named attack: "Attackers can exploit MCP proxy servers that connect to third-party APIs, creating "confused deputy" vulnerabilities" — where "This attack allows malicious clients to obtain authorization codes without proper user consent". The mechanism is a proxy using one static client ID for a third-party API: the third-party consent screen remembers a cookie from a legitimate approval, and "Setting this cookie before consent approval renders the consent screen ineffective" for the forged request that follows. The deputy here is the proxy server; the spent authority is your previous consent.

The sibling anti-pattern is token passthrough: "an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued to the MCP server and passes them through to the downstream API". The spec's verdict: "Token passthrough is explicitly forbidden in the authorization specification", for deputy-shaped reasons: controls that depend on token audience stop working, and "a malicious actor in possession of a stolen token can use the server as a proxy for data exfiltration".

The spec's floor is audience validation: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server". In deputy terms: a deputy that checks whose authority this actually is before spending it stops being confusable at that seam.

If you run or vet MCP servers, the page behind this one is short and dense, and it is the checklist your reviewer should be holding.

The token is not the secret you think it is

A credential in an agent's reach is not "stored" in any comforting sense. It is spendable by whatever the session can be talked into. That reframes two habits:

Scopes are the real permission. The narrow token the task needs, not the broad one that is lying around. A deputy cannot overspend authority it never held: the absolute-list logic applied to grants instead of data.

Sessions are the real boundary. Two agents with two narrow grants, passing artefacts through you, cannot be confused into combining them. One agent with both can. That is the whole aggregation argument, and it is why "just add the connector" deserves the same pause as "just run it with sudo".

What goes wrong

The everything session. Mail plus files plus repo plus browser in one long-lived agent: one hostile page away from a courier with keys to all four.

The proxy that launders authority. A convenient middle service that passes tokens through untested — every client it serves inherits every weakness it has.

Consent that was cached once. The cookie-shaped approval that a forged request rides. Consent screens exist per-grant for a reason.

Trusting the requester because the channel is internal. The deputy's error in 1988 and now: authority checked against who is asking, never against where the request arrived.

Audit logs that name the deputy. Every action attributes to the agent's token — meaning yours. Untangling which requests were actually yours is the incident-response problem, at its hardest.

How to check it worked

Draw the deputy diagram for one real agent setup: every credential the session holds, every input channel it reads. Any line from an untrusted input to a held credential is a confused-deputy path, and the fix is structural — drop the grant, split the session, narrow the scope — not a promise to watch more carefully. If the diagram will not fit on a sticky note, that is the finding.