Why is token passthrough a threat?
In short: Token passthrough is an anti-pattern where an MCP server forwards a client's token to a downstream API. It defeats audience checks, hides the real caller and widens the damage from a stolen token. The MCP security best practices forbid it. Gateways mitigate it by brokering or exchanging credentials per call.
What happens?
The server accepts a token not issued for it and forwards it downstream.
The downstream API trusts it, and audit sees the wrong party.
How does a gateway mitigate it?
- Accept only tokens issued for the gateway itself.
- Exchange or broker a separate short-lived credential for each downstream call.
Which scored gateways document a mitigation?
| Gateway | Documented control | Source |
|---|---|---|
| NewCore | The agent never holds the tool's own credential. | [nc-secure] |
| Aembit | Exchanges credentials on the agent's behalf. | [ae-home] |
| Idira | Obtains MCP server tokens for agents and manages rotation. | [id-docs] |
| Kong | Token exchange in the AI MCP OAuth2 plugin; passthrough is optional. | [kong-oauth] |
Facts only. A gateway missing here may still mitigate the threat; we list what its public pages document.
Sources
- MCP spec: Security best practices [mcp-sec] read 2026-11-03
- NewCore: Secure [nc-secure] read 2026-11-03
- Aembit home [ae-home] read 2026-11-03
- CyberArk Secure AI architecture [id-docs] read 2026-11-03
- Kong AI MCP OAuth2 plugin [kong-oauth] read 2026-11-03
All eight threats are listed on the threats hub.
By The Datasheet desk · Published and reviewed 2026-11-03