Token passthrough is when an MCP server accepts a token from a client without checking it was issued to that server, then forwards it to a downstream API. The MCP authorization specification forbids it. The fix is simple to state: servers must not accept any token that was not explicitly issued for them.
What the anti-pattern looks like
Imagine an MCP server that fronts a ticketing API. A client sends a bearer token. The server does not check who the token was meant for, and just attaches it to its own call to the ticketing API. It works in a demo. It is also a security hole.
The best practices page names two dimensions. One is audience validation failure: the server does not verify the token's audience claim, so it accepts tokens made for other services. The other is the passthrough itself, where the unmodified token is forwarded downstream, which can cause a confused deputy problem.
Why it matters
The page lists specific risks:
- Control circumvention. Rate limiting, validation and monitoring that depend on token audience can be bypassed if clients use tokens directly with downstream APIs.
- Audit gaps. The server cannot tell clients apart, and downstream logs show a different identity from the one that actually forwarded the request. Incident investigation gets harder.
- Data exfiltration. Someone holding a stolen token can use the server as a proxy.
- Trust boundary problems. A token accepted by several services lets a compromise of one reach the others.
- Future compatibility. A pure proxy today may need controls tomorrow, and audience separation makes that easier.
The mitigation
The page is blunt: MCP servers must not accept any tokens that were not explicitly issued for the MCP server.
In practice:
- Validate the audience of every inbound token against your server's identifier.
- Use a separate credential, held by the server, to call downstream APIs, or perform a proper token exchange.
- Record which client and user triggered each downstream call.
- Reject tokens with unexpected issuers or missing claims.
A related issue: proxy servers and consent
If your server proxies a third-party API using one static client ID, the page describes a confused deputy attack. It becomes possible when the proxy uses a static client ID, lets clients register dynamically, the third-party server sets a consent cookie, and the proxy does not collect consent per client. The mitigation is per-client consent stored server side, exact redirect URI matching and careful state parameter handling.
What users and teams can check
If you use third-party MCP servers, ask the vendor how they validate token audience and how they call downstream services. For servers you build, add a test that sends a token with the wrong audience and expects rejection.
Related reading: MCP server authentication and authorization and scoped credentials per MCP server.
Quick check
Is it ever fine to forward the client token?
The spec explicitly forbids servers accepting tokens not issued to them, which rules out blind forwarding. Use a server credential or a proper exchange.
What single test catches this?
Send a valid token issued for a different audience. A correct server rejects it.
Sources
Last reviewed: 19 October 2026.
