A confused deputy is a program that holds real authority and can be tricked by a less-privileged party into using it. An MCP server that talks to a third-party API is a natural deputy: it holds credentials for the API, and many different clients and agents ask it to act.
The short answer: the MCP specification forbids token passthrough, where a server takes a token from a client and forwards it to a downstream API without checking that the token was issued for that server. It also requires proxy servers to ask for consent per client. Both rules exist so that the server uses its own authority only for requests it has verified.
In this piece, we will cover:
- What the confused deputy problem is
- How it shows up in MCP proxy servers
- Why token passthrough is forbidden
- Five checks to run per server
- What these checks cannot show, and where nerl0 fits
What is the confused deputy problem?
According to Wikipedia, a confused deputy is a program that another, less-privileged program tricks into misusing the first program's authority. The classic example is credited to Norman Hardy's 1988 paper. A timesharing service ran a compiler that let users pick a file for debugging output. The compiler was allowed to write to a statistics file, and a user named the system's billing file instead. The operating system checked the compiler's permissions, not the user's, so the billing data was overwritten.
The pattern is the same in MCP. The server's credentials are the deputy's authority. The client that asks is the less-privileged party. If nothing checks what the asker is entitled to, the server's authority does the work.
How does it appear in MCP proxy servers?
The MCP security guidance describes one concrete form. It involves an MCP proxy server: a server that connects MCP clients to a third-party API and acts as a single OAuth client to that API. The attack becomes possible when four conditions hold together:
- The proxy uses one static client ID with the third-party authorization server.
- The proxy lets MCP clients register dynamically, so each gets its own client ID.
- The third-party authorization server sets a consent cookie after the first authorization.
- The proxy does not ask the user for consent per client before forwarding the request.
In the guidance's account, a user first signs in normally and the browser keeps the consent cookie. Later an attacker registers a client with a redirect address of their own and sends the user a crafted link. The browser still holds the cookie, so the third-party server skips the consent screen, and the authorization code goes to the attacker's address. The attacker can then obtain tokens for the MCP server and reach the third-party API as that user.
The required fix is that proxy servers keep a server-side registry of approved client IDs per user and check it before starting the third-party flow. The consent page must name the requesting client, show the requested scopes and the registered redirect address, and use exact string matching on that address. If the server tracks consent in cookies, they must be bound to the specific client ID, not to a general flag that the user has consented.
Why is token passthrough forbidden?
The guidance defines token passthrough as an anti-pattern: an MCP server accepts tokens from a client without validating that they were issued to the server, and passes them on to the downstream API. The authorization specification states that MCP servers must not accept tokens that were not explicitly issued for them. It adds that if the server calls an upstream API, the upstream token is a separate token from an upstream authorization server, and the server must not pass through the one it received from the client.
The guidance lists four risks:
- Bypassed controls. Rate limiting, request validation or traffic monitoring may depend on the token audience. A client holding a token usable downstream can skip them.
- Broken audit trail. The server cannot tell clients apart, and the downstream logs show requests that seem to come from a different identity than the server that forwarded them. Investigation gets harder.
- Broken trust boundary. If several services accept the same token, compromising one lets an attacker use the token against the others.
- Future compatibility. A server that starts as a pure proxy may need security controls later, and separating token audiences from the start makes that easier.
The guidance also notes that a server passing tokens without checking roles, privileges or audience lets a holder of a stolen token use the server as a proxy for data exfiltration.
What do audience binding and scopes add?
RFC 8707 explains the mechanism. An authorization server often does not know where a client will use an access token, and scope values describe the type of access, not the place. The RFC adds a resource parameter so the client can name the target, which lets the server restrict the token's audience. This matters because bearer tokens work for whoever holds them. A token limited to its intended resource cannot be reused against other services.
The MCP authorization specification builds on this. Clients must send the resource parameter in both the authorization request and the token request, identifying the MCP server. Servers must validate that every token was issued specifically for them as the intended audience. The specification also recommends short-lived access tokens to limit the impact of a leak.
Scopes limit the damage if audience checks fail. The security guidance warns against publishing every scope, against wildcard scopes such as * or full-access, and against treating the scopes claimed in a token as sufficient without server-side authorization logic. OWASP makes a similar point for agents: downstream systems should enforce authorization themselves instead of trusting the model, and actions should run under the specific user's identity with the fewest privileges needed.
What should you verify per server?
The table turns the rules into questions you can ask of each MCP server that calls another system.
| Check | Question to answer | Source of the rule |
|---|---|---|
| 1. Audience | Does the server reject tokens that were not issued for it? | MCP authorization spec |
| 2. Upstream token | Does it use its own separate token downstream, never the client's? | MCP authorization spec |
| 3. Per-client consent | If it is a proxy with a static client ID, does it ask consent per registered client? | MCP security guidance |
| 4. Redirect and cookies | Are redirect addresses matched exactly and consent cookies bound to the client ID? | MCP security guidance |
| 5. Scope and lifetime | Are scopes narrow, tokens short-lived, and downstream authorization enforced? | MCP guidance, OWASP |
Checks 1 and 2 are the passthrough question. If a server cannot show you where it validates the audience, treat it as unverified. Checks 3 and 4 apply only to proxies in front of third-party APIs. Check 5 applies to every server, and the read-only by default principle is the practical shortcut: start with read access and add more only when needed.
Each of the tokens in these checks belongs to a non-human identity. The earlier piece on MCP servers as a doorway with credentials explains why the server's own downstream credential is usually the one that matters most.
The checks are derived from specification text and guidance, which tell you what a correct server should do. They cannot tell you what a specific server does internally, whether its token validation is implemented well, or whether anyone has tried to exploit it. A server may also follow the 2025-06-18 revision of the specification while a later revision changes details, so verify against the revision you target. None of the sources is a certification of any product.
Where nerl0 fits
The checks above need a starting inventory: which MCP servers exist, who owns them and which credentials they hold. nerl0 maps every AI agent and non-human identity and what each can reach. It connects read-only through each platform's own interfaces and reads configuration and permission data, never the contents of data stores. The MCP servers page is where that view starts for servers.
The Security Graph shows authority paths: agent, credential, role, crown-jewel data store. Every step is an observed relationship, and the attack path view is where you can see how far a downstream credential reaches. Issues carry severity, evidence, an owner and a recommended breakpoint, and the next scan verifies the fix. For the vocabulary, see the Academy glossary.
nerl0 does not read token validation code or inspect traffic, so it cannot confirm that a server checks audiences. A path in it is a route, not proof of use. Every answer states what it cannot show, and the piece a route is not proof of use explains why. Checks 1 to 4 still need someone with the server's configuration or code in front of them.
For the full authorization flow, see MCP authentication explained.
Summary
The confused deputy problem is what happens when a server uses its own authority for a requester who was never checked. In MCP it appears as proxy servers that skip per-client consent and as token passthrough. The specification answers with audience validation, separate upstream tokens and per-client consent. For each server, check the audience, the upstream token, the consent flow, the redirect and cookie handling, and the scope and lifetime of every token.
Sources
- Security Best Practices - Model Context Protocol, Model Context Protocol, accessed Oct 8, 2026
- Authorization - Model Context Protocol, Model Context Protocol, accessed Oct 8, 2026
- Confused deputy problem, Wikipedia, accessed Oct 8, 2026
- RFC 8707: Resource Indicators for OAuth 2.0, RFC Editor, accessed Oct 8, 2026
- LLM06:2025 Excessive Agency, OWASP GenAI Security Project, accessed Oct 8, 2026
Sascha writes about what AI agents and non-human identities can reach, and builds nerl0 to keep that visible.