MCP Token Passthrough: Why It Is Dangerous and What to Do Instead

MCP token passthrough is the anti-pattern of accepting an access token from an MCP client without validating that it was issued for the MCP server, then forwarding that token to a downstream API. It breaks resource boundaries, weakens auditability, and can turn the MCP server into a confused deputy.

Why token passthrough creates risk

• Security controls can be bypassed when a token intended for another service is accepted here.
• The downstream API may trust the wrong audience or assume the token was already validated.
• Operators cannot reliably distinguish the MCP client from the upstream token’s identity.
• A stolen token can be replayed through the MCP server as a data-exfiltration proxy.
• The server becomes responsible for a credential whose audience and privileges it did not control.

The safe trust-boundary pattern

The MCP server acts as its own protected resource. It validates the inbound token’s issuer, audience, expiry, signature, scopes, and subject or tenant policy before processing the tool call. When it calls a downstream API, it authenticates to that API as a separately authorized client or performs a documented token exchange.

What to validate before a tool runs

• The token is presented in the Authorization header, not the query string.
• The token was issued by an accepted authorization server.
• The token is intended for this MCP server as its audience.
• The token is not expired, revoked, or malformed.
• The subject has the required tenant, role, and tool scope.
• The requested operation is allowed for this identity and environment.

What to do when calling a downstream API

• Use a server credential with the minimum downstream scope.
• Use a user-bound delegated credential only when the downstream authorization model explicitly supports it.
• Store downstream tokens server-side with encryption and access controls.
• Bind stored credentials to the authenticated user or tenant.
• Never return downstream credentials to the MCP client or include them in tool results.
• Record the authorization decision and downstream correlation ID without logging secrets.

How to detect passthrough in a review

• Search for code that copies the inbound Authorization header to an upstream request.
• Check whether the server validates audience before dispatching a tool.
• Inspect whether downstream requests use the same bearer token as the MCP request.
• Test a token issued for another service and verify that the MCP server rejects it.
• Check whether logs can distinguish the MCP subject from the downstream service identity.

Frequently asked questions