Token passthrough
Also called: token pass-through, confused deputy via tokens
An MCP server accepting an access token issued for something else and forwarding it to an upstream API, bypassing its own authorization checks.
The anti-pattern: a client presents a token, and the server — instead of validating that the token was issued for this server and for this user's scope — just relays it to a downstream service. Audience checks are skipped. An attacker with any token the upstream will accept can now act through the server.
Why it matters
It collapses the trust boundaries between client, MCP server, and upstream API into one. MCP's spec now calls this out directly: servers must validate token audience and must not pass client tokens through. Deployments predating that guidance may still do it.
Real-world context
MCP's authorization guidance states plainly that servers MUST NOT accept tokens not explicitly issued for them, and MUST NOT forward a received token to a downstream API — the anti-pattern is named and banned after early implementations were found doing it.
Exposure map
Live counts of instances showing this pattern will appear here once the exposure map is collecting data.