TL;DR: A gateway that reuses its own login for every downstream call hides which AI agent actually made the call. Security teams call this the confused deputy problem. The fix is token exchange: mint a new, narrower, short-lived token for each tool call that names the real agent, not the gateway.
Key takeaways:
The confused deputy problem happens when a trusted middle system, like an AI gateway, uses its own broad credential to act for an agent with narrower rights.
Security teams raised this exact problem, in close to these words, on seven separate client calls between late May and the end of August 2026.
RFC 8693, the IETF's OAuth token exchange standard published in January 2020, is the fix most teams settle on.
Token exchange swaps a wide credential for a narrow one before each downstream call: shorter life, one audience, one scope.
Without it, your logs show "the gateway" made every tool call. With it, your logs show the real agent, every time.
What is the confused deputy problem in an AI agent gateway?
The confused deputy problem happens when a trusted go-between uses its own strong permissions to do something for someone with weaker permissions. The go-between isn't malicious. It's just following orders it can't fully check.
Give this an AI shape. Your AI agent gateway sits between your agents and the tools they call: a CRM, a ticket system, an MCP server that reaches into SaaS apps. The agent has its own login. But when the gateway makes the real downstream call, it often uses its own login instead of the agent's. The tool on the other end sees the gateway. It never sees the agent.
That's the deputy getting confused. An attacker doesn't even have to trick it. The gateway just does what it was built to do: act with its own authority on someone else's behalf, with no way for the tool underneath to tell the two apart.
Why does this happen even when the agent logged in correctly?
Most AI gateways were built the way API gateways always have been: one shared service account, one wide credential, every request behind it waved through with the same power.
That design holds up fine when a human asks a human-scale question. It breaks with agents, because one agent can call dozens of tools a minute, and every call needs its own answer to one question: who is actually asking right now?
Picture a user's own AI assistant querying an MCP server, the connector standard that lets an AI agent reach live tools and data. If that MCP server then calls a SaaS app or an on-prem system using one shared API key, the key is wider than what the original user was ever allowed to touch. The agent asked a narrow question. The system answered with a broad key, and nothing in between checked whether the two matched.
How does token exchange fix the confused deputy problem?
Token exchange fixes it by handing the gateway a new, narrower token for every single downstream call, instead of letting it reuse one wide credential over and over.
The standard behind this is RFC 8693, the IETF's OAuth 2.0 Token Exchange specification, published in January 2020. It defines one grant type: hand in a token that proves who's asking, get back a token that says exactly what they may do next, for a short time only.
Here's the mechanism in plain steps. The agent's gateway holds an inbound token, proof of which agent this is, issued when the agent first logged in. For each tool call, the gateway takes that inbound token to the identity provider and asks for a new one. The new token names the same agent as the subject, the one it's speaking for. Its audience, meaning which system is allowed to accept it, is the one tool server being called, not anything else the gateway can reach. Its scope, meaning what it's allowed to do, covers only what that single call needs. Its life is minutes, not hours.
The tool server gets that narrow token and checks that the audience matches itself. Then it logs the real agent's name instead of the gateway's. If someone later asks what an agent actually touched, the answer sits in the log. It isn't buried inside the gateway's own account.
This pattern already has a name outside the RFC. Microsoft calls its version On-Behalf-Of, and it predates the IETF standard by about four years. Different wire format, same idea: hand in proof of who you are, get back a narrower proof of what you may do right here, right now.
None of this needs the agent to hold its own long-lived secret. The inbound token, the exchange, and the outbound token can all live for minutes and never touch a disk.
How often does the confused deputy problem actually come up?
This isn't a risk a vendor invented to sell a gateway. Security teams raised the confused deputy problem by name, or described it in close to these words, on seven separate client calls between late May and the end of August 2026: a life insurer, a direct-sales company, a health tech firm, a regional bank, a healthcare payer, a pharmaceutical company, and a credit-union service organization.
Seven different industries. The same missing check, every time. The gateway could prove the agent had logged in. It couldn't yet prove which agent made the call it was about to make. That's also the exact spot where the broader shift security teams have made toward asking about MCP governance before they bring a server in keeps ending up: not on whether to use MCP, but on what the gateway does with the credential once the call goes through.
What should security teams do about the confused deputy problem?
Start with the calls your gateway already makes, not with a new product. Most AI gateways can add token exchange onto an existing OAuth setup without a rebuild.
Four moves, in order. First, stop letting the gateway use one standing credential for every downstream call. That single credential is what turns a gateway into a confused deputy in the first place. Second, wire token exchange into the one or two tool integrations your agents call most, and confirm the downstream logs now show the agent's name instead of the gateway's. Third, extend it outward from there, one integration at a time, instead of trying to cover the whole estate on day one. Fourth, put a watch on any downstream call that still shows the gateway's own name rather than a token-exchanged one, so drift gets caught fast.
This is also where scoping an agent's access to only what it needs and fixing the confused deputy problem turn into the same project. A narrow token that names the wrong caller is still a problem. A wide token that names the right caller is still too wide. You need both: the right agent, and the right amount of access for that one call.
John Kindervag, who created Zero Trust, has a line for the piece this misses even when identity gets done right: identity is crackable. Knowing who an agent is doesn't tell you what it just did. A gateway that logs its own name instead of the agent's proves that point twice over. It got the login right and still lost the trail.
Frequently asked questions
Is the confused deputy problem specific to AI agents, or is it an old problem with a new name?
It's an old problem. The term dates back decades, to any system where a trusted program used its own permissions for someone with fewer. AI agents make it worse, because one agent can trigger hundreds of downstream calls an hour, and each one needs its own answer to who's really asking.
Does putting OAuth at the front door of my gateway already solve this?
No. OAuth at the front door proves the agent logged in. It says nothing about what credential the gateway uses for the call it makes next. The confused deputy problem lives at that second hop, not the first.
What's the difference between token exchange and just passing the agent's original token downstream?
The Model Context Protocol specification itself forbids passing a user's original token to a downstream server, because that token was scoped for a different audience. Token exchange mints a new token built for exactly that one downstream call instead.
Do I need a full identity overhaul to add token exchange?
No. If your identity provider already supports OAuth, it likely already supports RFC 8693 token exchange. Entra, Okta, PingFederate, and most other OAuth-based identity providers do. The work is wiring it into your gateway's call path, not replacing your identity stack.
How short should these downstream tokens live?
Minutes, not hours. The shorter the life, the less damage a leaked token can do, and the sooner a revoked agent actually stops working across every tool it touches.
Security teams keep finding the same missing check: the gateway logged in correctly, and the log still lied about who made the call. Fix the second hop, and the log stops lying.