MCP token passthrough is an anti-pattern in which an MCP server takes the access token a client presents, does not check that the token was issued for the server itself, and forwards it unchanged to a downstream API. The MCP specification forbids it outright: an MCP server must not accept any token that was not explicitly issued for that server. The correct design uses two credentials, one audience-bound to the MCP server and a separate one the server obtains for its own downstream calls, so every hop validates a token meant for it.
The pattern is tempting because it is the shortest path to a working integration. A developer builds an MCP server that wraps an internal API, the client already has a token that the API accepts, and forwarding it looks like zero-cost reuse. This post explains why the specification treats that shortcut as a vulnerability, how it shows up in real deployments, and what to build instead. For the OAuth foundations behind it, see MCP OAuth 2.1 and PKCE explained.
What the specification actually says
The MCP security best practices define the problem in two parts. The first is an audience validation failure: the server does not verify that a token was intended for it, for example by checking the audience claim described in RFC 9068. The second is passthrough proper: the server not only accepts a token with the wrong audience but also forwards it unmodified to downstream services.
The mitigation is a single normative line: MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server (MCP security best practices). That rule covers both halves. If the server rejects tokens minted for other resources, there is nothing valid to pass through.
Why passthrough is dangerous
The specification lists four risk groups. Each one maps to a failure that security teams already know from service-to-service auth.
Security controls are skipped
The MCP server or the downstream API may enforce rate limits, request validation or traffic monitoring that depend on the token audience. When a client can get a token that the downstream API accepts directly, and the MCP server just relays it, those controls are applied to the wrong party or not at all. The server stops being a policy point and becomes a pipe.
Audit trails stop telling the truth
With an upstream-issued token that may be opaque to it, the MCP server cannot tell one client from another. Meanwhile the downstream API logs a request that looks like it came from the original token holder, not from the server that actually made the call. During an incident, both logs point at the wrong actor. If you are building an evidence trail for agent activity, this alone disqualifies the pattern; see how to monitor MCP tool calls for what a useful record contains.
The server becomes a proxy for stolen tokens
If the server forwards tokens without checking claims such as audience, roles or privileges, anyone holding a stolen token can route requests through the server. The server lends the attacker its network position and its reputation with the downstream API.
Trust boundaries leak across services
A downstream resource server trusts specific callers and makes assumptions about their behaviour. If one token is accepted by several services without proper validation, compromising one service exposes the others. This is the confused deputy problem in its most direct form: the downstream API believes it is serving a validated, upstream-checked request, and nobody actually checked.
The specification adds a fifth, quieter risk: future compatibility. A server that starts as a "pure proxy" will eventually need its own controls. Retrofitting audience separation later is harder than starting with it.
How passthrough shows up in practice
Few teams write "forward the client's token" as a design decision. It tends to arrive through one of these routes:
| Pattern | What it looks like | Why it is passthrough |
|---|---|---|
| Header relay | The server copies the inbound Authorization header onto its outbound request |
The downstream API sees the client's token, not one issued to the server |
| Shared identity provider, no audience check | Client and API trust the same IdP, so the API accepts any token from it | The MCP server never confirms the token names it as audience |
| Broad-audience tokens | Tokens are minted with a wildcard or multi-service audience "to keep things simple" | Every service accepts every token, so validation proves nothing |
| Personal access token in the client | A user pastes a downstream PAT into the MCP client config and the server forwards it | The client holds a credential for the downstream API directly |
| Gateway that only routes | A proxy in front of several MCP servers forwards client credentials untouched | The proxy adds a hop but no new trust decision |
The last row matters for anyone evaluating MCP gateways. A gateway in the path is not a control by itself. It is a control only if it validates the inbound token for its own audience and uses separate credentials downstream.
What to do instead
The replacement design is simple to state: every hop gets a token meant for that hop.
1. Validate the inbound token for your own audience
The MCP server is an OAuth resource server. It checks the signature, expiry, issuer and the audience claim, and rejects anything not issued for its own identifier. Clients ask for that audience explicitly. Our MCP server authentication guide covers discovery metadata and validation in detail.
2. Get a separate credential for the downstream call
The server then authenticates to the downstream API as itself or on the user's behalf through a deliberate exchange, never by forwarding. Common options:
- Token exchange (RFC 8693). The server presents the validated inbound token to the authorization server and receives a new token whose audience is the downstream API, with scopes narrowed to what the tool needs. The new token can record both the user and the server as the acting party. See agent-to-tool authorization with token exchange.
- Server's own client credentials. For calls that do not need user context, the server uses its own client-credentials grant. The downstream API then sees the server as the caller, which is the truth.
- Brokered credentials. A credential broker or gateway holds the downstream secret and attaches it to the outbound call after a policy decision. The client and agent never see it.
3. Narrow scope at each hop
The downstream token should carry only the scopes the specific tool needs, not everything the user could do. Least privilege at the tool level, described in scoping MCP tool permissions, reduces the blast radius when any one token leaks.
4. Log both identities
Record the end user, the agent and the MCP server on every call. When the downstream API logs the server as caller and the server logs which user and agent it acted for, an investigator can join the two.
Checklist: is your MCP server doing passthrough?
If any box stays empty, treat it as a finding, not a backlog nicety.
The Praesidia angle
Praesidia addresses the credential half of this problem at the gateway layer. MCP servers are registered once in an organization-scoped registry, and their credentials are encrypted at rest and held at the proxy. Credentials are attached after policy evaluation, so agents that call through Praesidia never hold the downstream secret, and rotating it changes nothing on the agents. Tool calls that pass through Praesidia are policy-gated, and Praesidia records the decisions it makes in an append-only, hash-chained audit trail, with the agent, the policy decision and the latency. Recording never fails a call, so a record can be missing. Calls that do not pass through Praesidia are not recorded. That is the discover, secure, prove sequence applied to a single hop: know which servers exist, keep credentials off the agent, and keep the record.
For the full governance surface around registered servers, see the MCP server governance guide.