The Confused Deputy Problem in MCP Authentication

When an MCP server receives a tool call, it faces a question it cannot answer: was the calling agent actually authorized to use these credentials?

The server sees a valid token. The token grants access. But the server has no way to determine whether the agent presenting that token was the intended recipient, whether the user who originally authorized the token intended it to be used in this context, or whether another MCP server in the chain delegated it without permission.

This is the confused deputy problem, and it sits at the heart of MCP’s authentication model.

What Makes MCP Different

The confused deputy problem is not new — it was first described by Norm Hardy in 1988. But MCP creates a particularly acute version of it because of how agents compose tool calls across multiple servers.

Consider a typical agentic workflow. A user authorizes an AI agent to access their Google Calendar via an MCP server. The agent also has access to a database MCP server and a Slack MCP server. When the agent calls the Calendar MCP server, it passes along credentials — typically an OAuth token. The Calendar server validates the token, sees it is legitimate, and returns data.

But what if the agent was manipulated by a prompt injection from the Slack MCP server into making that Calendar call? What if the database MCP server requested the calendar data through the agent as an intermediary? The Calendar server cannot distinguish between a legitimate user-initiated request and one that was triggered by an adversarial input somewhere upstream in the agent’s reasoning chain.

The token is valid. The access is authorized. But the deputy — the agent — has been confused about who it is acting on behalf of.

The Token Passthrough Problem

MCP’s current authentication story relies heavily on token passthrough. The agent receives tokens from the user (or from an OAuth flow) and passes them to MCP servers as needed. This creates several problems:

Over-scoped delegation. When a user authorizes an agent, they typically grant a broad set of permissions. The agent then has a token that works across many operations, and every MCP server it connects to potentially sees the same level of access. There is no mechanism in MCP to say “this server should only see read access” while “that server gets write access.”

No audience restriction. OAuth tokens can include audience claims, but MCP does not enforce them. A token issued for Server A might be presented to Server B, and Server B has no standard way to reject it based on intended audience within the MCP protocol.

Credential leakage through tool descriptions. MCP servers can request that agents include credentials in tool call parameters. A malicious or misconfigured server can craft tool descriptions that cause the agent to forward credentials from other servers — the tool poisoning attack applied to authentication.

CVE-2025-6514: When Theory Becomes Practice

In late 2025, the theoretical risks of MCP authentication became very concrete. CVE-2025-6514, scored at CVSS 9.6, disclosed a command injection vulnerability in mcp-remote, the most widely used MCP transport library with over 558,000 weekly downloads at the time.

The vulnerability existed in how mcp-remote handled OAuth callback URLs during the authorization flow. An attacker could craft a malicious callback URL that, when processed by the library, executed arbitrary commands on the client machine. This was not a subtle logic error — it was a direct command injection in the authentication pipeline.

The impact was severe because mcp-remote was used by virtually every MCP client that needed to connect to remote servers. A single vulnerability in the auth transport layer put the entire ecosystem at risk.

This CVE crystallized what security researchers had been warning about: MCP’s authentication surface area is large, under-specified, and implemented by a fragmented set of libraries with varying security maturity.

OAuth 2.1 With Resource Indicators

The most promising protocol-level solution is OAuth 2.1 combined with resource indicators (RFC 8707). Resource indicators allow a token request to specify exactly which resource server the token is intended for. The authorization server can then issue a token scoped to that specific server, and the resource server can reject tokens not intended for it.

In the MCP context, this would work as follows:

# Token request with resource indicator
POST /oauth/token
grant_type=authorization_code
code=AUTH_CODE
resource=https://calendar-mcp.example.com/

The resulting token would include an aud claim matching the Calendar MCP server. If the agent tried to present this token to the Database MCP server, it would be rejected. This directly addresses the confused deputy problem by ensuring each MCP server only accepts tokens explicitly intended for it.

The MCP specification’s 2025 revision incorporated OAuth 2.1, but resource indicator support is recommended rather than required. Adoption has been slow because it requires changes on both the authorization server and every MCP server.

The Landscape: Six Competing Approaches

The authentication gap has spawned a crowded solution space. At least six significant approaches are competing for adoption:

mcp-front (Stainless) provides a gateway that sits between agents and MCP servers, handling authentication and authorization centrally. It intercepts tool calls and applies policy before forwarding them. The advantage is that individual MCP servers do not need to implement auth themselves. The disadvantage is introducing a centralized chokepoint.

IBM ContextForge takes an enterprise-oriented approach, integrating MCP authentication with existing enterprise identity providers. It focuses on SAML and OIDC federation, making MCP fit into corporate SSO infrastructure.

Microsoft MCP Gateway integrates with Azure Active Directory and provides per-tool authorization policies. It is tightly coupled to the Microsoft ecosystem but offers the most granular access control of any current solution.

mcpjungle is an open-source aggregator that routes tool calls to multiple MCP servers through a single connection, applying authentication and rate limiting at the routing layer. It is popular in the open-source community but lacks the policy granularity of enterprise solutions.

Agentic OAuth extensions from several vendors extend the OAuth 2.0 framework with agent-specific grant types and token formats. These approaches add claims for agent identity, delegation chains, and tool-level scoping directly into the token.

Agent tokens offer a zero-infrastructure alternative. Instead of OAuth flows, agent tokens are pre-provisioned API keys scoped to specific agents and tool sets. They sacrifice the dynamic authorization of OAuth for simplicity and predictability. For teams that cannot deploy authorization servers or gateways, agent tokens provide a pragmatic middle ground — the agent presents a static token that the MCP server can validate against a simple allowlist.

No clear winner has emerged. The fragmentation itself is a security risk, as implementations that bridge multiple approaches introduce additional complexity and potential vulnerabilities.

NIST Enters the Picture

NIST is now evaluating MCP alongside OAuth 2.0/2.1 with OIDC, SPIFFE/SPIRE, SCIM, and NGAC as candidate standards for agentic AI identity governance. This is significant because NIST’s assessment will likely influence which approaches receive federal funding, enterprise adoption, and regulatory backing.

NIST’s draft concept paper identifies five unsolved problems in agentic authentication: agent identification, key management, zero-trust least-privilege enforcement, delegation chain tracking, and audit trail integrity. MCP currently addresses none of these comprehensively at the protocol level, though various implementations cover subsets.

The fact that NIST is evaluating MCP at all — placing it alongside established identity standards — signals that the protocol has reached a level of adoption where institutional governance is necessary. But it also highlights how much work remains.

What the Confused Deputy Means in Practice

The confused deputy problem in MCP is not academic. It manifests in concrete attack scenarios:

Cross-server credential theft. A malicious MCP server crafts a tool description that causes the agent to include credentials from other servers in its tool call parameters. The server collects these credentials and uses them directly.

Privilege escalation through composition. An agent with read-only access to Server A and write access to Server B is manipulated into reading sensitive data from A and writing it to an attacker-controlled location via B. Neither server’s individual auth policy is violated.

Delegation chain confusion. Agent A delegates a task to Agent B, forwarding its credentials. Agent B uses those credentials to access resources that Agent A’s user authorized but never intended for Agent B’s task.

What You Should Do Now

While the ecosystem sorts out its authentication story, there are practical steps to reduce confused deputy risk:

1. Use separate tokens per MCP server. Do not reuse tokens across servers, even when the same OAuth provider issued them. Request tokens with resource indicators where supported.

2. Implement server-side audience validation. If you operate an MCP server, validate the aud claim on incoming tokens and reject tokens not explicitly scoped to your server.

3. Audit token flows through your agents. Trace which tokens your agent presents to which servers. Look for cases where a single token is used across multiple servers — each one is a potential confused deputy vector.

4. Prefer gateway architectures for multi-server deployments. A gateway like mcp-front or an MCP proxy can enforce per-server token scoping even when the underlying MCP servers do not implement it themselves.

5. Watch the NIST process. The standards that NIST endorses will likely become the baseline for enterprise MCP deployments. Aligning with those standards now reduces migration pain later.

The confused deputy problem in MCP authentication is solvable, but only if the ecosystem converges on solutions that work at the protocol level rather than relying on each implementation to get it right independently. Until then, treat every MCP server connection as a potential trust boundary violation.