Why does the MCP spec forbid token passthrough?
In short: Token passthrough is when an MCP server accepts a client token and forwards it to a downstream API unchanged. The MCP security best practices forbid it, because it bypasses audience checks, breaks audit trails and lets a stolen token travel further. Gateways should exchange tokens or broker separate credentials instead.
What goes wrong with passthrough?
The downstream API cannot tell who the real caller is. Rate limits, monitoring and audit see the wrong party.
A token issued for one audience ends up accepted by another, so a leaked token has a wider blast radius.
What should happen instead?
The MCP server, or a gateway in front of it, should only accept tokens issued for itself. For downstream calls it should obtain its own token, for example through token exchange.
Do any gateways still allow passthrough?
Kong documents a token passthrough mode in its AI MCP OAuth2 plugin, with a note to enable it only when an upstream explicitly requires the original token. It also documents token exchange.
Sources
- MCP spec: Security best practices [mcp-sec] read 2026-11-03
- Kong AI MCP OAuth2 plugin [kong-oauth] read 2026-11-03
Other explainers are listed on the spec hub.
By The Datasheet desk · Published and reviewed 2026-11-03