AI Gateways and User-Level OAuth for MCP Servers: Token Exchange vs Passthrough (2026)

The question of how an AI gateway should handle user-level OAuth for MCP servers has a wrong answer that is also the easy one: forward the token you already have. Passthrough feels natural because the gateway is already holding a valid token and the downstream MCP server needs one, so relaying it looks like plumbing. It is not plumbing. It is the confused-deputy anti-pattern the MCP authorization spec forbids, and it quietly turns your gateway - the single service every agent trusts - into an instrument for privilege escalation.

This guide draws a clean line between the two ways a gateway can put user identity in front of an MCP server: token passthrough (the forbidden move) and token exchange under RFC 8693 (the correct one). It sits between two existing pieces you should read alongside it - OAuth for MCP servers explained, which covers the MCP authorization profile end to end, and securing LLM gateways and proxies, which covers the gateway attack surface. Here the angle is the intersection: the gateway as the identity broker between a user and a fleet of MCP servers.

The stakes are the same ones that make gateways worth securing at all. A gateway is a chokepoint, so a design flaw in how it brokers identity has org-wide reach. Get the token model right and the gateway becomes the place you enforce per-user least privilege. Get it wrong and it becomes the place a single stolen session reaches everything.

What is an AI gateway, and how is it different from an LLM gateway?

An LLM gateway fronts many model providers behind one API - the LiteLLM, vLLM, and Ollama pattern covered in the LLM gateways pillar. An AI gateway is the broader term for the same chokepoint once it also brokers tool and data access, not just model calls. In a 2026 agent stack the two roles converge: the gateway authenticates the caller, routes model requests, and increasingly proxies MCP traffic to a set of downstream MCP servers on the caller's behalf.

That second role is the new part. When a gateway only routes model calls, its token problem is limited to holding provider keys. When it starts fronting MCP servers, it inherits the full MCP authorization model - and the single most consequential decision inside it: whose identity the downstream MCP server sees. The answer determines whether your tool calls are attributable to a person, scoped to that person's permissions, and revocable per user, or whether they all collapse into one over-privileged blur.

For the mechanics of what an MCP server is and why it is a governance surface at all, see the MCP server security complete guide and MCP security explained. This guide assumes that grounding and focuses on the token flow between the gateway and those servers.

Why user-level OAuth matters for MCP (vs a shared service token)

The first fork is not passthrough versus exchange - it is user-level identity versus a shared service token. Many gateways start with the simplest thing that works: one service account, one long-lived credential, every downstream MCP call made as the gateway itself. It works on day one and fails every audit after.

A shared service token means the MCP server sees one principal for the entire gateway. You cannot tell which user triggered a tool call, you cannot scope permissions to what an individual is allowed to touch, and you cannot revoke one user without rotating a credential the whole fleet shares. It is the same over-broad machine credential problem described in non-human identity governance and AI identity security explained: a single identity standing in for many, with the union of everyone's permissions.

User-level OAuth is the target state, and least privilege is the reason. Applying least privilege for AI agents and AI access control is only possible if the downstream MCP server can see who the caller actually is. That is what makes the passthrough-versus-exchange question matter: both preserve user identity, but only one does it without breaking the token's audience.

Token passthrough vs token exchange: the core distinction

Both patterns aim for the same outcome - the MCP server acts as the end user. They differ in how the gateway produces the downstream token, and that difference is the whole ballgame.

Token passthrough reuses the inbound token verbatim. The gateway receives the user's access token, and forwards that same token to the downstream MCP server. The token's audience is the gateway (or the user-to-gateway relationship), not the MCP server. So the MCP server is handed a credential it was never the intended recipient of. If it rejects it on audience grounds, the call fails - annoying but safe. If it accepts it anyway, it is now a confused deputy: a privileged intermediary honoring a token minted for someone else. The MCP authorization spec settles the matter with a MUST NOT - a server must not pass through the token it received, as detailed in OAuth for MCP servers explained.

Token exchange mints a new token. The gateway presents the user's token to the authorization server as a subject_token and requests a fresh access token scoped and audience-bound to one specific MCP server. The new token names the user as the subject and records the gateway as the actor, so the delegation chain is explicit and the audience is correct. This is the RFC 8693 flow, and it is the standards-based way to achieve user-level identity without the confused-deputy gap.

Passthrough keeps the user identity but breaks the audience. Exchange keeps the identity and fixes the audience.The gateway token rule

Audience and resource indicators: the control that makes exchange safe

Token exchange is necessary but not sufficient. Minting a new token does nothing if the MCP server accepts any valid-looking bearer regardless of who it was minted for. Two controls close that gap, and they are the same ones that anchor the whole MCP authorization model.

RFC 8707 Resource Indicators let the client - here, the gateway acting as an OAuth client - declare the canonical URI of the MCP server it intends to call, in both the exchange request and the resulting token. RFC 9068 defines the JWT access-token profile whose aud claim carries that binding, and the MCP server validates it, refusing any token whose audience is not itself. Together they turn a broadly usable token into a single-target credential. A gateway that runs token exchange but omits audience validation on the downstream server has reintroduced the confused deputy it was trying to fix.

This is why the fix is a pair, not a single control: mint correctly (exchange, with the resource parameter) and validate correctly (audience check on the server). The OAuth for MCP servers guide walks the full MUST-grade control set - PKCE, RFC 9728 protected resource metadata, RFC 8414 authorization-server discovery - that surrounds these two.

Which RFC covers what

The gateway-to-MCP identity flow leans on a small stack of OAuth standards. Knowing which one does what makes it easy to read a gateway's docs and tell whether it implements the safe pattern or the forbidden one.

If a gateway's documentation talks about forwarding, relaying, or passing the user token to backends, that is passthrough. If it talks about exchanging, minting downstream tokens, on-behalf-of, or audience-bound tokens per resource, that is exchange. The vocabulary is a reliable tell.

How a gateway should broker per-user identity to MCP servers

Put the pieces together and the correct flow is concrete. It is more work than passthrough, and that extra work is exactly the security.

1. The user authenticates to the gateway via the OAuth 2.1 authorization-code flow with PKCE (RFC 7636). The gateway receives a token that represents the user-to-gateway relationship.
2. When the agent needs a downstream MCP server, the gateway discovers that server's authorization server via RFC 9728 protected resource metadata, then RFC 8414 metadata for the token endpoint.
3. The gateway calls the token endpoint with the RFC 8693 exchange grant, presenting the user's token as the subject_token and the target MCP server as the resource (RFC 8707).
4. The authorization server returns a new access token whose audience is that specific MCP server, scoped to the minimum the call needs, with the user as subject and the gateway as actor.
5. The gateway calls the MCP server with the exchanged token. The MCP server validates the audience (RFC 9068) and enforces the user's own permissions.
6. For a proxy-style gateway fronting several downstream services, explicit user consent is obtained per service rather than reusing one prior grant across all of them.

That last point matters for multi-server gateways: reusing one consent silently across downstream services is its own confused-deputy variant, and the same trust-boundary discipline shows up in agent-to-agent security and trust boundaries. Managing the credentials the gateway itself holds - its client secret, its exchange grants - is a secrets management for AI agents problem, kept well out of the passthrough path.

Failure modes and real incident patterns

The passthrough anti-pattern is not hypothetical. The clearest real-world shape is the GitHub MCP confused-deputy issue documented by Invariant Labs in May 2025: an agent holding a single token that spanned both public and private repositories was steered by a malicious public issue into reading private-repo data. One over-scoped, reused credential crossing a trust boundary - the exact failure user-level exchange with per-resource scoping is designed to prevent. It also maps onto Simon Willison's lethal trifecta, analyzed in the lethal trifecta write-up: private data access, untrusted content, and an outbound path combining into an exfiltration route.

The gateway's own authorization logic is a second failure surface, and the LiteLLM record shows why you cannot lean on it alone. The allowed_routes privilege escalation (CVE-2026-47101) let a low-privilege user mint a key carrying admin-only routes, and the /user/update self-promotion flaw (CVE-2026-47102) let an org admin set their own role to proxy admin - both covered in the LLM gateways pillar. If a gateway's role model can be bypassed, then whatever token policy it enforces can be bypassed too. The LiteLLM MCP-preview command-injection to RCE (CVE-2026-42271) made the point sharper still: the gateway's MCP integration was itself the vulnerable code path.

Secret exposure is the third pattern. The MLflow AI Gateway secrets-exfiltration flaw (CVE-2026-4035) is a reminder that the gateway holds the very credentials passthrough would otherwise scatter downstream - concentrating them is only safe if the gateway is hardened and the tokens it issues are audience-bound and short-lived. These failure modes line up with documented agentic threats in the OWASP Top 10 for agentic applications and the OWASP LLM agentic controls checklist, which helps justify the controls to GRC.

A decision matrix for gateway token handling

Use this to choose the pattern per downstream MCP server, because the right answer depends on the trust relationship, not on convenience.

The default should be token exchange. Passthrough earns a place only in the narrow case where the gateway and the MCP server genuinely share an audience and trust domain, and even then the server must validate the audience claim rather than assume it.

How Anomity surfaces and governs this at the endpoint

Be clear about the boundary: a gateway is a network-layer control. It governs the traffic that flows through it - authentication, token exchange, egress, rate limits - and it does that well when it implements exchange correctly. What it cannot do is see what never reaches it. An MCP server a developer launched locally over stdio, an agent configured to call a server directly, a tool call that routes around the gateway entirely - none of those appear in the gateway's view. That is the layer runtime governance at the endpoint covers, and it complements the gateway rather than replacing it.

Anomity is endpoint agentic governance. First, inventory: it discovers and inventories every AI agent and MCP server on every managed endpoint - including the ones no gateway fronts - so you know which servers exist, which agents reach them, and which of those paths bypass the gateway you thought was the single door. That inventory is the precondition for the token discipline above; you cannot reason about passthrough on servers you have not found, the same gap behind building an MCP server registry and an AI agent inventory.

Second, decide at the hook. On agents that expose a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. That governs a call to an MCP server whether or not it traversed the gateway, so a direct-to-server path that skipped exchange is still checked at the source. It is a backstop for the case the gateway structurally cannot see, described further in runtime monitoring and anomaly detection.

Third, keep the record. Every discovered server, agent, and decision lands in a queryable 90-day audit trail that routes to SIEM, Slack, email, or Jira, feeding the AI agent audit trail an investigation actually needs. Anomity collects metadata only, with secret redaction on the endpoint, and is SOC 2 Type II. It does not terminate OAuth, mint tokens, or replace your gateway - it inventories and governs the agentic endpoint so the gateway's identity model has a backstop where its visibility ends. See how Anomity fits your existing controls.

You can't govern what you can't see.The Anomity principle

What to do next

The work is sequential, and the first three items close the largest share of the exposure.

1. Audit how your AI gateway hands identity to downstream MCP servers: passthrough, a shared service token, or RFC 8693 token exchange. Anything but exchange (or an audience-matched passthrough) is a finding.
2. Confirm every downstream MCP server validates the audience claim (RFC 9068) and honors the resource indicator (RFC 8707) - exchange without validation is not safe.
3. Migrate shared service tokens to user-level exchange so attribution, least privilege, and per-user revocation hold at the MCP layer.
4. Enforce per-service consent on multi-server gateways so one grant is not silently reused across trust boundaries, per agent-to-agent trust boundaries.
5. Inventory MCP servers and agents that bypass the gateway entirely, and govern their calls with allow/deny/log at the endpoint hook.
6. Fold gateway token misuse and confused-deputy scenarios into the AI agent incident response playbook with a queryable audit trail behind it.

The decision framework for an AI gateway handling user-level OAuth for MCP servers reduces to three moves: never pass the inbound token through, use RFC 8693 token exchange to mint an audience-bound token per downstream server with the user preserved as the subject, and govern the agent's call at the endpoint so the paths the gateway cannot see are still covered. The gateway is the broker on the wire; endpoint governance is the backstop at the source. To see Anomity inventory your MCP servers and agents, govern tool calls at the hook, and keep the audit trail across your fleet, request early access.