Why MCP token passthrough is unsafe

Reject passthrough instead of treating the MCP server as a token pipe

MCP token passthrough is unsafe because one bearer token is being asked to cross two resource boundaries. The current MCP authorization specification requires a protected MCP server to accept only access tokens valid for its own resources; the client must not send some other service's token, and the server must not accept or transit unrelated tokens. The safe default is therefore rejection, not forwarding with an extra scope check.

When the MCP server needs an upstream API, keep the two authorization relationships separate. First, validate that the inbound token was issued for the MCP server. Then have the server act as an OAuth client to the upstream service and use a separate access token issued for that upstream API. Current MCP security considerations state this separation directly and prohibit forwarding the client-to-MCP token downstream.

Follow one token through a concrete failure path

Consider a hypothetical MCP proxy that calls a document API. In the unsafe path, a client obtains a document-API bearer token, presents it to the MCP endpoint, and the MCP server forwards it unchanged. The MCP layer has not established that it was the intended audience. Its own client identity, rate limits, request policy, and audit context may not govern the downstream call, while the downstream log can reflect the token's original identity rather than the intermediary that relayed it.

In the separated path, the client requests a token for the MCP resource by including that resource in both authorization and token requests. The MCP server validates that it is the intended recipient before processing the request. If the operation requires the document API, the server uses its own upstream OAuth relationship to acquire a document-API token with only the required privileges. A token stolen from one side is not automatically valid on the other side because each resource checks its own audience.

The failure under review is forwarding, not merely choosing an imprecise audience. Even a correctly audience-bound token for the MCP server becomes unsafe when the server reuses that same credential at a downstream API. The resource-indicators guide owns how the client names and the server validates the intended MCP resource; this page owns the architectural rule that the downstream hop must use a different authorization relationship.

Unsafe

Client token → MCP proxy → downstream APIThe same bearer value crosses distinct resource boundaries.

Separated

Client token → MCP; server token → downstream APIEach resource receives and validates a token issued for itself.

Use a fail-closed review sequence

Start with protected-resource discovery instead of accepting whatever issuer or token the client supplies. The current MCP authorization specification requires MCP servers to publish OAuth Protected Resource Metadata and clients to use it for authorization-server discovery. RFC 9728 defines a required resource identifier and an optional authorization_servers list. Where both sides publish enumerable associations, the RFC says the protected-resource and authorization-server lists should be cross-checked for consistency.

At request time, read the bearer token from the Authorization header, never from the URI query string. Validate the token using the authorization method appropriate to its format, including validity, issuer, recipient or audience, and required privileges. Return 401 for an invalid or expired token and 403 for insufficient permissions; do not retry the call with a token meant for a different service. Keep token acquisition, caching, logging, and forwarding paths separate for the MCP resource and each upstream API.

1. Discover

Bind metadata to the exact MCP resource identifierConfirm the authorization server is appropriate for this protected resource.

2. Request

Include the MCP resource in authorization and token requestsAsk the authorization server for a token intended for the MCP endpoint.

3. Validate

Reject wrong-recipient tokens before tool executionA valid token for another API is still invalid at this MCP resource.

4. Separate

Acquire a distinct credential for every upstream resourceNever use forwarding as a substitute for an upstream OAuth client flow.

Review the controls that passthrough can erase

The MCP security best-practices guide identifies more than a token-format problem. Passthrough can circumvent controls that depend on the correct audience or credential boundary, including rate limiting, request validation, and traffic monitoring. It can also make accountability harder when the MCP server cannot distinguish clients from an opaque upstream token and downstream logs attribute activity to a different identity than the intermediary that initiated the request.

The same guide describes trust-boundary and data-exfiltration risk: accepting or forwarding a token without checking roles, privileges, audience, or other metadata can turn the server into a proxy for misuse. The practical review question is not merely “does the downstream API accept this token?” It is “which resource issued or accepted it, which controls evaluated it, which identity will appear in each audit trail, and can compromise of one service extend to another?”

Make the review produce a credential-flow diagram. A passing design has one edge from client to MCP labeled with the MCP audience and another edge from MCP to the upstream API labeled with a separately issued upstream audience. Any edge that carries the same bearer value across both hops is the specific defect this page is designed to catch.

Control ownership

Which service enforces validation, rate, and request policy?Do not leave responsibility implicit between the MCP server and downstream API.

Audit identity

Can each hop identify the actor and intermediary?Preserve enough context to investigate without logging bearer-token values.

Blast radius

Can one token work at more than one resource?Narrow audiences and privileges so one resource cannot silently become a credential bridge.

Evidence boundary and remaining gaps

This page is a protocol and architecture guide, not an assessment of a specific MCP deployment. It does not establish that any named server validates issuer, audience, expiry, scopes, metadata associations, or upstream token separation. A reviewer can inspect configuration and exercise rejection paths with a token minted for the wrong resource to collect deployment-specific evidence. Those are recommended review procedures, not additional protocol requirements. The cited MCP rules remain the narrower factual baseline: accept tokens intended for the MCP resource, reject unrelated tokens, and use a separate token for an upstream API.

The 2026-08-09 research pass retrieved 51 recent items with degraded coverage, including a partial Reddit lane after HTTP 429 responses and an unconfigured X lane. No community anecdote, prevalence estimate, exploit report, adoption claim, or claim that discussion was absent is used. Incomplete retrieval cannot establish that communities were quiet. Normative statements on this page instead come from the current dated MCP specification and security guidance plus primary IETF standards; deployment behavior remains unverified until a reviewer gathers evidence from the system being assessed.