What is Token Passthrough?

The spec's language is unambiguous: MCP servers MUST validate that tokens were issued specifically for them as the intended audience, MUST reject tokens whose audience claim does not include them, and "MUST NOT accept or transit any other tokens". If a server calls upstream APIs, it must act as its own OAuth client to them — the upstream token is a separate token issued by the upstream's authorisation server, never the one the MCP client presented.

Passthrough is forbidden because it breaks OAuth's audience binding and creates a confused deputy: the downstream API sees a syntactically valid token and trusts it as though the MCP server had obtained and validated it, when in fact the server is blindly relaying whatever it was handed. Concretely this means:

• A token stolen from one service can be replayed against an MCP server that skips audience validation, then laundered onward to downstream APIs.
• Controls at the downstream layer — rate limits, allowlists, anomaly detection — see the wrong principal, so requests appear to come from a trusted intermediary.
• Audit trails cannot attribute actions correctly, because the identity in the token does not match the path the request actually took.

The pattern usually arises from convenience: a server that proxies a SaaS API simply forwards the inbound Authorization header rather than managing its own credentials. The mitigations are mandated by MCP Authorization: clients send the RFC 8707 resource parameter so tokens are bound to one server, and servers validate audience before processing any request.

PolicyLayer's gateway issues its own per-person scoped tokens for client access and holds upstream credentials server-side, so client tokens never transit to upstream servers. Every tools/call is policy-evaluated and logged against the person who made it, keeping attribution intact across the chain.