MCP security best practices expose the confused deputy risk

At a glance

What this is: This is an analysis of MCP security best practices, with the key finding that the spec treats confused deputy risk as the primary identity problem and requires strict per-request authentication and authorization controls.

Why it matters: It matters because MCP puts non-human identities into direct trust relationships with tools and data, so IAM, PAM, and workload-identity teams need controls that validate each request rather than assuming a stable session or a safe intermediary.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Aembit's analysis of MCP security best practices and confused deputy risk

Context

MCP security is really a request-authorisation problem for non-human identities, not just a transport or token problem. In MCP, agents, servers and tools generate requests dynamically, which means trust has to be validated on every request, for every client, and for every operation.

The article's core warning is that confused deputy attacks emerge when a server treats user authentication as blanket authorisation for downstream clients. That assumption breaks classic IAM shortcuts and puts workload identity, consent, token audience validation and server-side enforcement at the centre of MCP governance.

For IAM teams, the practical question is no longer whether an agent can authenticate. It is whether the platform can prove which client is allowed to act, which scope is valid, and which intermediate component is forbidden from relaying tokens or making authorisation decisions.

Key questions

Q: How should security teams enforce per-client authorization in MCP environments?

A: Security teams should bind each request to a specific client identity, approved scope, and approved operation on the server side. The user’s general login must never become blanket permission for any application that can reach the MCP endpoint. Consent records, exact client identifiers, and server-side policy checks are the controls that prevent confused deputy abuse.

Q: Why do token audience checks matter so much in MCP?

A: Token audience checks matter because a valid token for one service should not be reusable against another service. In MCP, agents and intermediaries move quickly across trust boundaries, so the aud claim is what stops cross-service replay after authentication succeeds. Without audience validation on every request, a stolen token can be used far beyond its intended scope.

Q: What breaks when MCP servers use token passthrough or session auth?

A: Token passthrough and session authentication both create reusable trust artefacts that are easy to intercept or replay. Pass-through leaks credentials at intermediaries, while sessions let attackers hijack a server-maintained trust state. MCP replaces both patterns with request-level validation because the protocol needs direct proof of authorisation on each call.

Q: How do organisations decide whether MCP should use OAuth, mTLS, or federation?

A: Use OAuth 2.1 for standard delegated access, mTLS for higher assurance between tightly controlled workloads, and federation when identity must span cloud or on-premises domains. The decision should follow the trust boundary, the exposure of the token path, and the operational maturity of the workload identity stack, not personal preference.

Technical breakdown

Confused deputy attacks in MCP authorization

The confused deputy problem appears when a legitimate MCP server accepts a request that was not intended for the requesting client. In this model, a user grants Application A access, but a different client can reuse that trust path unless the server validates client identity, consent and scope server-side. The security failure is not weak authentication alone. It is the mismatch between who was authenticated and who is actually authorised to act. MCP security best practices therefore treat consent registry checks, per-client scope binding and explicit operation approval as mandatory controls, not optional policy layers.

Practical implication: enforce server-side per-client consent and reject any request that is not bound to the specific client and operation.

OAuth 2.1, token audience validation, and token passthrough

MCP’s authentication model assumes OAuth 2.1 with PKCE or client credentials, but the real control point is how tokens are validated and contained. The aud claim prevents a valid token for one service from being replayed against another service, while short-lived tokens and refresh rotation reduce exposure if a token leaks into logs, tools or downstream payloads. Token passthrough is especially dangerous because it turns every intermediary into a theft point. The server must validate tokens directly and, when it needs downstream access, use token exchange instead of forwarding user credentials.

Practical implication: validate audience on every request and block token passthrough wherever an MCP intermediary sits in the path.

Why sessions and wildcard redirects fail in MCP

MCP explicitly rejects session-based authentication because sessions create a reusable trust artifact that attackers can hijack. The protocol instead requires request-level token validation, exact redirect URI matching, and state parameter checks with high-entropy values to stop code interception and CSRF-style abuse. These controls matter because agentic environments amplify small OAuth mistakes into cross-tool compromise. A wildcard redirect or a loosely checked callback is not a minor implementation flaw. It is a pathway for an attacker to intercept codes and impersonate a legitimate client in a system built on delegated trust.

Practical implication: remove session cookies from MCP auth paths and require exact redirect URI and state validation everywhere.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Confused deputy is the right named concept for MCP governance failure: the article shows that MCP does not mainly fail because authentication is absent, but because trust is misapplied across clients and intermediaries. User authentication was designed for a single authorised actor, not for a server that can be induced to act on behalf of another client. The implication is that MCP governance has to be built around explicit client binding, not inherited trust.

Token passthrough is a standing credential exposure window: when an MCP server forwards tokens instead of validating them and exchanging them, it turns every intermediary into a viable capture point. That assumption fails because agentic flows are built to move data across trust boundaries, not to preserve a single safe authentication path. Practitioners must treat forwarded tokens as a broken model of delegated access, not a mere implementation shortcut.

Session-based authentication was designed for human-paced trust, not request-by-request machine trust: the spec’s prohibition exists because sessions create a stable artefact that MCP does not need and cannot safely rely on. That assumption fails when non-human identities generate requests dynamically and can chain operations without human oversight. The implication is that identity governance for MCP has to move from session custody to per-request enforcement.

Exact redirect matching and state validation are the control boundary that stops client confusion: partial matches, wildcards and predictable state values create room for code interception and callback abuse in delegated flows. The article makes clear that client identity is not established by a generic OAuth success event. It is established only when the callback, the redirect URI and the state value all line up exactly, which is the minimum viable boundary for MCP trust.

Context-aware access control is the next pressure point for non-human identity governance: the article’s conditional policy examples show that static roles alone do not express the real risk of an agent, host or environment at runtime. That matters because MCP traffic crosses tools, clouds and compliance zones, and policy decisions must account for posture, timing and environment. Practitioners should expect MCP governance to converge with workload identity, not sit beside it.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• In our Ultimate Guide to NHIs, 91.6% of secrets remain valid five days after notification, which shows how slowly governance catches up once credentials move.
• That same lifecycle gap is why the Ultimate Guide to NHIs remains a practical reference for rotation, offboarding and access review design.

What this signals

With 30.9% of organisations storing long-term credentials directly in code, MCP governance cannot rely on the assumption that secrets stay contained to a clean authentication boundary. The more agentic the workflow becomes, the more valuable exact request scoping and direct token validation become as operational controls, not just protocol hygiene.

Delegated trust debt: MCP systems accumulate risk when identity decisions are pushed into intermediaries that were never meant to authorise access. That creates a programme-level problem for IAM teams, because token validation, consent and workload posture now have to be designed together rather than managed by separate control owners.

Teams aligning MCP with Zero Trust should cross-check their design against NIST AI Risk Management Framework only where autonomous decision-making is present, and otherwise keep the focus on workload identity, consent and per-request enforcement. The governance direction is clear: static trust constructs are too coarse for dynamic tool chains.

For practitioners

• Enforce per-client consent registries Map each user to approved client applications and approved scopes on the server side, then reject requests that cannot be bound to a specific client and operation. The consent screen must show the requesting client, the resources involved and the duration of access.
• Validate audience claims on every request Reject any token whose aud claim does not match the MCP server identifier, even if the token is signed and unexpired. Treat audience mismatches as a hard control failure, not an authentication warning.
• Eliminate token passthrough from intermediary services Require direct token validation against the authorization server and use token exchange when downstream services need access on behalf of the user. Do not allow proxies, logs or middleware to carry the user’s original token.
• Remove session cookies from MCP authentication flows Use request-level tokens only, with exact redirect URI matching and cryptographically random state validation in the OAuth callback path. If the current workload stack depends on sessions, redesign that trust path before MCP rollout.

Key takeaways

• MCP security fails when servers inherit trust from user authentication instead of binding authorisation to the specific client and operation.
• The evidence in the specification points to a governance gap, not just a protocol gap: token passthrough, session auth and loose redirect handling all widen the attack surface.
• Per-request token validation, exact audience checks and server-side consent are the controls that matter most for keeping MCP identity flows contained.

Key terms

• Confused Deputy: A confused deputy is a trusted system that is tricked into using its legitimate authority on behalf of an attacker. In MCP, the problem appears when a server treats one client’s authorisation as if it applies to another client, turning valid trust into an abuse path.
• Token Passthrough: Token passthrough is the practice of forwarding a user or client token through an intermediary instead of validating it and using a separate downstream credential. In MCP architectures, this creates a replay and theft opportunity at every hop and breaks the server’s own trust boundary.
• Per-Client Consent: Per-client consent is a control that records which specific application is allowed to act for a user and under what scope. For MCP, it is the minimum proof that a request came from an approved client, not just from an authenticated user or signed token.
• Audience Validation: Audience validation checks that a token was issued for the exact service receiving it. In MCP, this prevents a valid token for one server from being reused elsewhere, which is critical because agent-driven workflows often move across multiple tools and trust domains.

Deepen your knowledge

MCP security best practices, OAuth 2.1 validation, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing request-by-request trust controls for agents and tools, it is worth exploring.

This post draws on content published by Aembit: MCP security best practices and the confused deputy problem. Read the original.