Avoid MCP Token Passthrough

An MCP client may present a token to the MCP server. That token proves authority for the MCP resource only when the server validates it. Forwarding the same token to an unrelated upstream API creates a confused-deputy path: a credential intended for one audience reaches another service. The MCP security guidance explicitly addresses token passthrough risk.

Draw the two trust boundaries before writing adapter code. The client authenticates to the MCP server. The MCP server then authenticates to its upstream service under a separate, approved delegation or service credential. The downstream service must know whose data is requested, but it must not receive a token for the wrong resource.

Credential flow map

If the upstream supports OAuth token exchange or delegated authorization, use the documented flow and keep the resulting token scoped to that service. If it does not, a narrowly scoped service credential may be possible, but the server still needs its own per-user permission checks. Never solve a missing exchange by copying the client's Authorization header.

Negative path

In an owned test, give the MCP client a token that is valid for the MCP server but not for the upstream API. Make one harmless call. Inspect the upstream request in a controlled mock: the client token must not appear in any header, query string, or body. Then replace the upstream credential with a revoked synthetic value and verify the MCP server denies the operation without falling back to the client token.

Check redirects, retries, and error logging. A client token can leak through a retry helper or a debug trace even when the main request path is clean. Keep a trace that shows credential classes, not values. If you cannot explain which component owns each credential, hold the connection. This separation also makes rotation and provider-side revocation easier to verify later.