This power—letting LLMs call tools and access real data—amplifies risk. Among the most important risks is the confused deputy problem, a decades-old vulnerability pattern where a more-privileged component is tricked into misusing its own authority on behalf of a less-privileged requester. It is not unique to MCP, but MCP’s architecture makes it particularly salient if you deploy servers that act as OAuth-backed proxies to third-party APIs without enforcing per-client consent.

This article explains MCP fundamentals, why the confused deputy risk is pronounced in MCP deployments and how to design defenses without sacrificing performance or developer velocity.

Why is MCP in the news?

MCP is an open protocol, governed neutrally, that standardizes the way AI applications discover and utilize tools, access resources, and reuse prompts provided by MCP servers via transports like stdio and HTTP. Official SDKs are available for major programming languages, and the specification is continuously evolving to include features such as asynchronous operations, server identity, and official extensions. Leading vendors in the ecosystem, including Anthropic, Microsoft/GitHub, OpenAI, and Google, are supporting MCP to minimize fragmentation and facilitate portable, governed connections between AI assistants and the necessary tools and data.

Solving N×M

Before MCP, combining N tools with M AI interfaces needed N×M custom connectors. MCP simplifies this to N + M: each tool sets up a server once, and each AI app sets up a client once. This is like the “USB‑C for AI” analogy—one port, multiple devices.

What are the Security Risks?

MCP enables LLM‑driven tool execution and context access across process and network boundaries. That creates an attack surface that includes prompt/tool injection, identity/authorization gaps, supply‑chain risk from third‑party servers, and—our focus here—confused deputy when a server acts as a proxy to an OAuth‑protected API. The spec’s Security Best Practices explicitly calls out this risk and outlines mitigations.

The Confused Deputy Problem

A confused deputy occurs when a more‑privileged component (the “deputy”) is tricked into misusing its own authority to perform an action requested by a less‑privileged party. The attacker does not gain new privileges; instead, they induce the deputy to act with the deputy’s privileges. This vulnerability predates MCP and is well known in OS, compilers, cloud IAM, API gateways, and OAuth ecosystems.

Why MCP makes it pronounced

MCP servers frequently encapsulate powerful tool capabilities and sometimes forward those calls to third‑party APIs using OAuth. If a server acts as a proxy and uses a static OAuth client_id toward the third‑party authorization server—and does not enforce per‑client consent—then prior consent for one user can be reused silently for another, causing the proxy to act as a confused deputy.

Key nuance: In MCP documentation, an “MCP proxy” is not a separate protocol role; it’s a type of MCP server that forwards requests to external APIs and holds OAuth credentials. Every MCP proxy is an MCP server, but not every MCP server is a proxy.

A proxy is simply an MCP server whose implementation forwards requests to a third‑party API and holds OAuth state. Thus, clients still call servers directly—but a given server may behave as a proxy internally. The confused‑deputy risk is specific to such proxy‑style servers that do not perform per‑client consent enforcement and rely on static OAuth client identities.

How the Confused Deputy Emerges in MCP

The MCP security guidance describes a concrete flow: an MCP server acting as a proxy uses a static client ID against a third‑party OAuth server. Once a user (User A) grants consent, the third‑party server may cache that consent (e.g., via cookies/sessions) for the proxy’s client_id. If the proxy doesn’t enforce per‑client consent internally, a different MCP client (User B) can invoke the proxy, which then reuses the already‑granted authority to perform privileged actions—no new user consent required. That’s the deputy (proxy) misusing its own privileges.

Key points:

• The attacker does not escalate their own privilege.

• The proxy performs the action using its credentials (or tokens derived from its static client identity).

• The third‑party API sees the same OAuth client_id and trusts the prior consent.

• Result: cross‑user authorization leakage, i.e., confused deputy.

Illustrative Flows

Baseline (legit first‑time consent): User A - a valid user - approves scopes; third‑party binds consent to the proxy’s client_id.

Vulnerable flow: (confused deputy): User B calls the same proxy; the proxy reuses consent for its static client_id; third‑party skips consent; privileged data/actions flow to B.

Key nuance: A Confused Deputy problem is not Privilege Escalation. In privilege escalation, the attacker gains higher privileges (e.g., user to admin). In a confused deputy scenario, no new privileges are gained; instead, a privileged deputy is tricked into using its authority for the attacker.

How to mitigate the Confused Deputy problem in MCP

1. Per‑client consent enforcement (a must‑have).
   Make sure each user has their own consent record. If a user hasn’t approved access—or needs a new scope—ask again. Never reuse another user’s consent.

2. Bind identity end‑to‑end.
   Every request should include a verifiable user identity (OIDC/Entra, etc.). The MCP client, proxy, and the upstream API should all know who the request is for. Tokens and actions must map to the actual user, not the proxy.

3. Avoid static client identity where possible.
   Prefer dynamic client registration, resource indicators, PKCE, and user‑bound tokens supported by the upstream provider—per MCP authorization guidance.

4. Constrain blast radius.
   Run MCP proxy servers in isolated environments. Control egress, limit what each tool is allowed to do, and set rate limits. Treat every tool description as untrusted input.

5. Strong audit and observability.
   Log who requested what, which identity was used upstream, what scope was exercised, and where data went. Feed into SIEM to detect anomalies.

Hardened flow: The proxy enforces per‑client consent and binds tokens to the initiating user (e.g., OIDC/OAuth 2.1 patterns), preventing cross‑user reuse.

The MCP Security Best Practices explicitly documents the confused‑deputy risk pattern for proxy servers and describes required mitigations. Besides, security communities already treat confused deputy as a first‑class risk; MCP simply inherits this reality as it bridges untrusted LLM behavior with privileged tools. So this is not “just” a theoretical problem.

Key Takeaways

• MCP matters because it standardizes how AI apps use tools and data—solving N×M integration, reducing glue code, and enabling a shared ecosystem.

• However, it comes with security risks like the confused deputy problem which is amplified when MCP servers proxy to OAuth‑protected APIs without per‑client consent.

• Mitigate it with per‑client consent, identity binding, dynamic registration/PKCE/resource indicators, and strong audit/egress controls.

Acknowledgements / Sources

• MCP Fundamentals & Spec: Anthropic announcement; official docs/spec; GitHub repo. [permit.io], [modelcontextprotocol.io], [arstechnica.com], [anthropic.com]

• Ecosystem Momentum: Microsoft/GitHub announcements; industry coverage. [docs.langchain.com], [spknowledge.com]

• Security Best Practices & Confused Deputy: Official MCP security guidance. [cdata.com]