Token passthrough sends the inbound identity token to the downstream server unchanged, so both layers must trust the same issuer and audience. Token forwarding passes custom headers through the gateway to support a separate downstream auth system. Passthrough can preserve end to end identity, while forwarding should be treated as an exception path because it weakens centralized control.
Why This Matters for Security Teams
In an mcp gateway, token handling is not just a routing choice. It determines whether the gateway preserves end-to-end identity, creates a trust boundary, or quietly becomes a credential relay. That matters because downstream MCP servers, tools, and agent workflows often operate with broader execution authority than a normal web request, which makes token misuse more consequential than a simple integration bug. The risk is not theoretical: the AI Agents: The New Attack Surface report notes that 80% of organisations say their AI agents have already acted beyond intended scope.
Security teams often get this wrong by treating passthrough and forwarding as interchangeable implementation details. They are not. Passthrough keeps the original identity token intact, but only works when the issuer, audience, and trust model remain aligned across layers. Forwarding, by contrast, usually exists to accommodate a separate downstream auth system, which can weaken centralized policy enforcement and make audit trails harder to reason about. The difference is especially important in agentic environments, where runtime behaviour is dynamic and OWASP Agentic AI Top 10 highlights how tool chaining and delegated authority expand attack surface. In practice, many security teams encounter token misuse only after a downstream system has already accepted a request that the gateway never fully intended to authorize.
How It Works in Practice
token passthrough is the cleaner model when the MCP gateway and downstream server can share the same identity trust assumptions. The gateway receives an inbound token, validates it, and forwards that same token unchanged. This preserves the original subject, scopes, and audience relationships, which helps with non-repudiation and consistent authorization decisions. It also reduces token translation risk because the gateway is not minting a new credential or inventing a new trust contract.
Token forwarding is different. The gateway passes custom headers or metadata through to a downstream system that has its own authentication logic. That can be useful for legacy services or special-purpose integrations, but it should be treated as an exception path. Once custom headers become the auth mechanism, the gateway may no longer be the sole policy enforcement point. Current guidance suggests keeping that path narrow, documented, and subject to additional inspection. This is where controls for secret exposure matter too: NHIMG’s Guide to the Secret Sprawl Challenge shows how credentials leak when identity material is copied into too many places.
For operational design, teams should evaluate:
- Whether the downstream service can validate the original issuer and audience without token translation.
- Whether custom headers contain identities, scopes, or routing hints that could be replayed.
- Whether the gateway can log, redact, and correlate identity context without exposing secrets.
- Whether short-lived, audience-bound tokens can replace long-lived credentials in the flow.
Where agents are involved, this distinction becomes more important because autonomous systems can chain tools, retry actions, and fan out requests in ways that humans do not. The better pattern is to combine gateway validation with runtime policy checks and tightly scoped credentials, rather than assuming a forwarded token behaves like an independently verified identity. These controls tend to break down when the downstream service accepts opaque headers from multiple callers because provenance and audience validation become ambiguous.
Common Variations and Edge Cases
Tighter token handling often increases integration overhead, requiring organisations to balance stronger identity assurance against legacy compatibility. That tradeoff is most visible in multi-service MCP deployments, where one server supports modern OIDC-based identity while another still depends on application-specific headers or session cookies. There is no universal standard for this yet, so teams should label these flows explicitly in architecture diagrams and policy docs.
One common edge case is token exchange. Instead of blindly forwarding the inbound token, the gateway may swap it for a downstream audience-specific token. That is often safer than forwarding, but it only works if the exchange process is tightly governed and logged. Another edge case is agent delegation: when an AI agent acts on behalf of a user, the gateway must preserve both the user context and the workload identity, not collapse them into one ambiguous credential. For that reason, workload identity and runtime policy are becoming more relevant than static role grants, as reflected in the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s coverage of the Vercel Context.ai OAuth Supply Chain Breach. In short, passthrough is best when trust is shared, forwarding is a compatibility exception, and neither should be used to hide weak authorization design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Covers identity and tool authorization risks in agentic flows. |
| CSA MAESTRO | IAM | Addresses identity propagation and trust boundaries in agent workflows. |
| NIST AI RMF | GOVERN | Supports governance over autonomous system identity and access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Relevant because gateways can expose or relay sensitive identity tokens. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires explicit policy enforcement at each boundary. |
Enforce per-request verification and avoid implicit trust between gateway and downstream service.
