The Confused Deputy Problem in MCP

The confused deputy problem in MCP is an attack where a malicious client hijacks a user's existing consent. It tricks an MCP proxy server into acting for the attacker. The proxy is the "deputy." It holds legitimate authority, but it gets confused about who it is acting for.

The result can be serious. According to the MCP spec, the attacker can end up with "access to the third-party API as the compromised user." The user may never see a consent screen.

This page explains the conditions that make the attack possible, a plain example, and the controls the spec requires. It is mainly a concern for teams that build or run MCP servers. Sources were checked on 28 October 2026.

What a confused deputy is

"Confused deputy" is an old security term. A program with real authority is tricked into using it for someone who should not have it.

In MCP, the deputy is an MCP proxy server. The MCP Security Best Practices page defines this as a server that connects MCP clients to third-party APIs while "acting as a single OAuth client to the third-party API server." Think of a server that gives AI apps access to a SaaS tool on your behalf.

Because the proxy uses one static client ID with the third-party service, that service sees every request as coming from the same app. It cannot tell which MCP client started the request.

When the attack is possible

The spec lists four conditions that must all be present:

1. The proxy uses a static client ID with the third-party authorization server.
2. The proxy lets MCP clients register dynamically, each getting its own client ID.
3. The third-party authorization server sets a consent cookie after the first approval.
4. The proxy does not ask for per-client consent before forwarding to the third party.

Remove any one, and this specific attack fails. Most fixes target the fourth condition.

How the attack works

The spec walks through the steps. In plain English:

1. A user signs in through the proxy normally. The third-party service remembers this with a consent cookie.
2. An attacker registers a new client with the proxy, using their own redirect URI.
3. The attacker sends the user a crafted link.
4. The user clicks. The third-party service sees the cookie and skips the consent screen.
5. The proxy sends the resulting authorization code to the attacker's redirect URI.
6. The attacker exchanges the code for tokens and acts as the user.

The key flaw is that consent was given to the proxy, not to the attacker's client. The proxy never asked, "Do you want this new client to have access?"

An illustrative scenario

This example is illustrative. It is not a real incident.

A startup builds an MCP server that lets AI apps read customers' project-management boards. It uses one OAuth app with the project tool and accepts dynamic registration from any MCP client.

A customer connects through Claude in the morning. That afternoon, she clicks a link in a phishing email. No consent screen appears, because her browser still has the project tool's cookie. The attacker's client now holds a token to her boards.

Who is at risk

• Builders of MCP proxy servers that wrap third-party APIs, especially those accepting dynamic client registration.
• Users of those servers, whose accounts are what the attacker reaches.
• Organizations that host internal proxies in front of SaaS tools with a single shared OAuth app.

If you only use MCP clients and well-known servers, your main job is asking vendors the right questions. Our MCP vendor security questionnaire includes them.

How to detect it

• Authorization logs. Look for authorization codes issued to newly registered clients soon after their registration.
• Unfamiliar redirect URIs. Flag redirect URIs on unknown domains, especially from clients registered once and used once.
• Missing consent events. If a client received a code without a matching consent record for that user, investigate.
• User reports. Users seeing connected apps they do not recognize in a third-party account is a late but real signal.

How to reduce the risk

On the server side (where the fix lives)

The spec says MCP proxy servers "MUST implement per-client consent." That means:

• Keep a registry of approved client_id values per user, and check it before starting the third-party flow.
• Show a consent page owned by the MCP server.
• Validate that the redirect URI "exactly matches the registered URI," using exact string matching, not wildcards.
• Generate a random, single-use state value and validate it at the callback.

The consent page itself MUST, per the spec:

If consent is tracked in cookies, the spec says they MUST use the __Host- prefix, be Secure, HttpOnly and SameSite=Lax, and be bound to the specific client ID.

On the client side

• Use pre-registered or metadata-document client IDs where the server supports them.
• Do not open authorization links from untrusted sources.

At the organization level

• Review any internal proxy that wraps SaaS tools before it goes live.
• Ask vendors whether they implement per-client consent and exact redirect URI matching.

What the MCP spec says

The authorization specification lists confused deputy attacks among the security considerations implementations MUST follow. It also notes that dynamic client registration is "deprecated and retained for backwards compatibility." That change reduces one of the four conditions over time.

A closely related rule bans token passthrough. The best practices page says passthrough "can potentially cause the confused deputy problem" downstream. For the OAuth basics, see MCP authentication and OAuth, and for common setup errors see MCP OAuth misconfigurations.

Next step

If you are building an MCP server that connects to a third-party API, get the consent flow reviewed before launch. Our MCP development team builds servers with per-client consent and exact redirect matching from the start. More threats are covered in the MCP Security Center.

Frequently asked questions