Why MCP Servers Must Not Pass Tokens Through

Token passthrough is when an MCP server accepts a client's access token without checking it was issued for that server. The server then forwards it to another API. The MCP specification forbids it outright. The rule is short: MCP servers "MUST NOT accept or transit any other tokens."

It can look like a shortcut. The client already has a token for the downstream service, so why not reuse it? Because it breaks the checks that keep tokens from being reused where they do not belong.

This page explains what passthrough is, why the spec bans it, how to detect it in a server, and what to build instead. Sources were checked on 28 October 2026.

What token passthrough is

An access token is like a temporary key card. A good key card says which door it opens. In OAuth, that "door" is the token's audience, the service it was issued for.

The MCP Security Best Practices page defines token passthrough as an anti-pattern. It is where a server accepts tokens "without validating that the tokens were properly issued to the MCP server" and passes them through to the downstream API.

The page splits the problem into two parts:

1. Audience validation failure. The server does not check the token was meant for it, so tokens issued for other services work.
2. Passthrough. The server forwards those unmodified tokens to downstream services, which may wrongly trust them.

Why the spec bans it

The best practices page lists four groups of risk.

The page also warns that a server passing tokens without validation lets "a malicious actor in possession of a stolen token" use the server "as a proxy for data exfiltration." And it links passthrough to the confused deputy problem, where a downstream API trusts a token it should not.

An illustrative scenario

This example is illustrative. It is not a real incident.

A company builds an internal MCP server for its billing API. To save time, the server takes whatever bearer token the client sends and forwards it to billing. It never checks the audience.

An attacker steals a token that was issued for a low-risk analytics app on the same identity provider. Billing accepts it, because it only checks the signature. The MCP server's logs show a normal request, and billing's logs show the analytics app. Nobody can trace what happened.

Who is at risk

• Teams building MCP servers that wrap existing internal or SaaS APIs.
• "Thin proxy" servers designed to forward requests with as little logic as possible.
• Organizations with one identity provider issuing tokens for many services, where a missing audience check opens many doors.
• Buyers of hosted MCP servers who cannot see how tokens are handled.

How to detect it

If you build or review a server, look for these signs:

1. No audience check. The token validation code checks signature and expiry but not the audience claim.
2. Incoming token reused outbound. The same Authorization header received from the client is sent to the upstream API.
3. No resource parameter. Clients are not sending the resource parameter, so tokens are not bound to the server.
4. Identical identities in logs. Downstream logs show end-user tokens arriving directly, with no record of the MCP server as a distinct client.

For vendor-built servers, ask in writing. Our MCP vendor security questionnaire includes the exact questions.

How to reduce the risk

On the server side

• Validate the audience. The authorization spec says servers "MUST validate that access tokens were issued specifically for them as the intended audience," per RFC 8707.
• Reject everything else. Invalid or expired tokens MUST receive an HTTP 401 response.
• Get your own upstream token. When your server calls another API, it should act as its own OAuth client with its own token for that API. Do not reuse the client's token.
• Keep tokens out of URLs and logs. The spec says tokens MUST NOT be included in the URI query string.

On the client side

• Send the resource parameter with every authorization and token request. The spec says clients MUST, using the MCP server's canonical URI.
• Only send a server tokens issued by that server's authorization server. The spec makes this a MUST NOT for anything else.

At the organization level

• Make audience validation part of your server review checklist. Our MCP security checklist includes it.
• Issue tokens with specific audiences on your identity provider rather than one token for everything.
• Keep short token lifetimes so stolen tokens expire quickly.

What the MCP spec says

The authorization page's token handling section is direct:

• MCP servers "MUST validate that access tokens were issued specifically for them as the intended audience."
• MCP clients "MUST NOT send tokens to the MCP server other than ones issued by the MCP server's authorization server."
• MCP servers "MUST only accept tokens that are valid for use with their own resources."
• MCP servers "MUST NOT accept or transit any other tokens."

The best practices page restates the mitigation in one line: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." For a step-by-step OAuth walkthrough, see MCP authentication and OAuth. For related errors, see MCP OAuth misconfigurations.

Next step

If your team is planning a server that wraps an existing API, design token handling first. Our MCP development team builds servers that validate audience and use separate upstream credentials. You can find more threats in the MCP Security Center.

Frequently asked questions