Token passthrough and the confused deputy in MCP servers that call other APIs

What it is

The MCP Security Best Practices document describes several attacks on servers that sit between a client and a third-party API.

Token passthrough is defined there as an anti-pattern: the server accepts a token from the client without validating that it was issued to the MCP server and passes it on to the downstream API. The document states that the authorization specification explicitly forbids it.

Confused deputy: an MCP proxy server that uses a static client ID with a third-party authorization server, combined with dynamic client registration and a consent cookie left by an earlier approval, can be abused so that a malicious client obtains an authorization code without the user's fresh consent. The server is the deputy; its trusted position is borrowed by someone else.

Why it matters

Both patterns erase the boundary that lets anyone reason about who did what. With passthrough, the downstream API sees a token but not the MCP server's own checks, rate limits or audit trail; a token stolen elsewhere can be replayed through the server. With a confused deputy, the user's earlier consent is reused for a client they never approved. Agents make this worse because they call tools at machine speed and rarely surface consent screens to a person.

How to apply

• Validate every incoming token: issuer, audience (it must name your server), expiry and scope. Reject tokens minted for another resource.
• Obtain separate downstream credentials for your server and map them to the calling user explicitly; never forward the inbound token.
• For proxy servers using a static client ID upstream, obtain the user's consent per client at your own server before redirecting to the third-party authorization server, and do not let a consent cookie substitute for it.
• Validate redirect URIs exactly against those registered.
• Request the narrowest scopes; the guidance lists scope minimisation among its mitigations.
• Log the calling client and user for every downstream call.

Pitfalls

• Treating "the token worked downstream" as proof it was meant for you.
• A single shared service credential used for all callers, which makes every user as powerful as the most privileged one.