The confused deputy problem in MCP happens when a proxy server uses one static client ID with a third-party authorization server, lets clients register dynamically, and relies on a consent cookie. An attacker can then get an authorization code without the user approving anything. Per-client consent in the MCP server prevents it.
The four conditions
The MCP security best practices page says the attack needs all of these at once:
- The MCP proxy server uses a static client ID with a third-party authorization server.
- It lets MCP clients register dynamically, each getting their own client ID.
- The third-party authorization server sets a consent cookie after the first authorization.
- The proxy does not ask for consent per client before forwarding to the third party.
Remove any one of these and the attack path closes. Number four is the one you control most directly.
How the attack runs
A user signs in through the proxy normally, and the third party sets a consent cookie for the static client ID. Later, an attacker registers a malicious client with their own redirect URI and sends the user a crafted link.
The browser still holds the cookie, so the third party skips the consent screen. The authorization code is redirected to the attacker's address, and the attacker exchanges it for tokens. They now reach the third-party API as that user.
What the proxy must do
The specification says proxy servers must implement per-client consent before the third-party flow starts. In detail:
- Keep a registry of approved client IDs per user, and check it before forwarding.
- Show a consent page owned by the MCP server that names the client, lists the scopes and shows the redirect URI.
- Protect that page against CSRF and against framing.
- If you use cookies for consent, use the
__Host-prefix, set Secure, HttpOnly and SameSite=Lax, sign them or use server sessions, and bind them to the specific client ID. - Match redirect URIs by exact string, never by pattern or wildcard.
- Generate a random, single use
statevalue with a short life, and only set the state cookie after the user approves consent.
That last point matters. Setting the state cookie before consent makes the consent screen ineffective, because a crafted request can skip it.
Is your server a proxy?
If your MCP server holds its own credentials for another API and passes users through to it, treat it as a proxy. A server that only exposes its own data and validates its own tokens is not in this scenario.
Where Safeguard fits
Safeguard offers an MCP Guardrail and agent identity so teams can see which agents are connecting to which servers. It does not change how a server implements OAuth consent, so fix the proxy first.
Quick check
Does dynamic client registration cause this vulnerability by itself?
No. The attack needs a static client ID, dynamic registration, a consent cookie and missing per-client consent together. Dynamic registration is one ingredient.
Sources
Last reviewed: 19 October 2026.
