If you build remote MCP servers, there is one auth rule the spec states in bold and developers still break constantly: an MCP server must never pass through the token it received from the client. It feels harmless — you already have a valid token, why not reuse it downstream? Because that's exactly the move that turns your server into a confused deputy. Here's the failure, and how the 2026 spec closes it.
What token passthrough actually is
Token passthrough is when your MCP server takes the access token a client presented to it and replays that same token to call some other API — a database, a SaaS backend, a third-party service. The token was minted for your server. Forwarding it means the downstream service now sees a token it was never the intended audience for, and has no way to know it's being used somewhere it shouldn't be. The MCP spec is unambiguous: servers must not pass through the client's token, and must not accept or transit tokens minted for anyone else either.
The confused-deputy attack
The reason the rule exists is a classic privilege-confusion attack. Imagine a malicious or compromised server in the chain that's handed a token meant for a different, trusted server. If downstream services accept whatever token arrives without checking who it was issued for, the attacker rides a legitimate user's credential into systems it should never reach — the user's deputy, confused into acting on the attacker's behalf. Passthrough is what makes this possible: it severs the binding between a token and the one service that was supposed to use it.
How RFC 8707 fixes it
The 2026 authorization model makes that binding mandatory. Under RFC 8707 Resource Indicators, the client must include a resource parameter — naming the specific MCP server the token is for — in both the authorization request and the token request. The authorization server stamps that audience into the token. Now a downstream service can reject any token whose audience isn't itself, and a stolen or forwarded token is inert outside its one intended server. Combined with Protected Resource Metadata (RFC 9728) for discovery and mandatory PKCE, it's what makes the 2026-07-28 spec genuinely enterprise-grade.
What to do in your server
The practical pattern: treat the client's token as proof of who is calling you, then mint or fetch a separate credential — scoped to your server's own identity — for any downstream call. Never relay the inbound token outward. Keep downstream secrets in a proper store with rotation, and audit every place a token crosses a service boundary. This sits alongside the rest of your posture — permission scoping, credential rotation and access control lists — and is non-negotiable for any multi-tenant deployment.
Going further
Token passthrough is one of those bugs that passes every test and ships, because the happy path works fine — it only fails under attack. Bake the RFC 8707 audience check in from day one. For the wider picture, read MCP security best practices, enterprise managed connectors and zero-trust MCP architecture. Browse the security category for more.