TL;DR: The MCP security best practices specification makes confused deputy attacks, token passthrough, and session-based authentication the central risks for agent and tool trust, while mandating OAuth 2.1, per-request validation, and five authorization patterns, according to Aembit. The bigger issue is that existing IAM assumptions about stable user sessions and broad token reuse do not survive request-by-request nonhuman identity behaviour.
At a glance
What this is: This is an analysis of MCP security best practices, with the central finding that confused deputy risk forces authorization to be explicit, per-client, and checked on every request.
Why it matters: IAM, PAM, and NHI teams need to treat MCP as a request-by-request authorization problem, not a session problem, because agent and tool behaviour breaks inherited trust.
Context
MCP security is a request-level governance problem because nonhuman identities can generate, chain and forward actions across trust boundaries without direct human oversight. In that model, a valid login or a valid token does not automatically mean a valid action for every client, server or tool.
The core failure mode is the confused deputy pattern: one application can be tricked into exercising authority on behalf of another if consent, audience and delegation are not checked at the point of use. For MCP, that means authentication alone is insufficient unless authorization is bound to the specific client and request.
The article frames this as an architectural constraint, not an optional hardening step. That is typical of early MCP governance guidance, where the protocol itself pushes teams away from session-based assumptions and toward explicit per-request control.
Key questions
Q: What breaks when MCP relies on sessions instead of request-level authorization?
A: Session-based authentication breaks because MCP requests can be generated dynamically by nonhuman identities and routed through tools or intermediaries that were never part of the original trust decision. A session can hide who is actually acting, while request-level authorization forces the server to verify the client, audience and operation each time.
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 are the signs that an MCP authorization model is too loose?
A: Warning signs include token passthrough between components, broad token scopes, shared sessions for workloads, and redirect URI patterns that accept wildcards or partial matches. If the server cannot prove which client requested which operation, the authorization model is relying on inherited trust rather than explicit control.
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
Why confused deputy attacks are central to MCP security
The confused deputy problem appears when a legitimate component is induced to use its own authority for an unauthorised purpose. In MCP, an agent, server or tool can carry valid credentials yet still be the wrong actor for the request. That matters because the protocol is built around nonhuman identities that chain operations and cross trust boundaries. A token or login state that proves identity does not prove the caller is the intended client for the specific operation. The security model therefore has to bind authorization to client identity, audience and requested action, not just to a user or a token.
Practical implication: treat every MCP request as a fresh authorization decision, not as reuse of prior trust.
Why session-based authentication and token passthrough fail in agentic flows
Session-based authentication assumes a stable, server-maintained state that can be trusted across multiple interactions. MCP rejects that model because agentic systems move data through intermediaries, invoke tools dynamically and may outlive the conditions under which a session was created. Token passthrough creates a second weakness: any intermediary that can see the token can potentially replay it. The specification instead requires direct token validation and per-request checks. That design reduces hidden trust inheritance and forces the server to verify that the token was issued for the right audience and the right server on each call.
Practical implication: remove session cookies and intermediary token forwarding from MCP authentication paths.
How OAuth 2.1, PKCE and audience checks constrain MCP authorization
The protocol aligns MCP with OAuth 2.1 security guidance, including Authorization Code Flow with PKCE for client applications and client credentials for server-to-server flows. PKCE protects against authorization code interception by binding the code exchange to the original request. Audience validation adds another layer by requiring the token's aud claim to match the receiving server. Exact redirect URI matching and state validation protect the authorization flow itself from interception and CSRF-style manipulation. Together, these controls do not just authenticate a caller. They constrain where a token can be used, when it can be exchanged and which client is allowed to complete the flow.
Practical implication: enforce PKCE, exact redirect URI matching and audience validation as non-negotiable MCP controls.
Threat narrative
Attacker objective: The attacker wants to borrow legitimate MCP authority to reach data or tools that were never authorised for their client or workflow.
- Entry occurs when a user authorises one application to access enterprise data through an MCP server, creating a valid trust relationship that an attacker can abuse indirectly.
- Escalation happens when a malicious application reuses that trust path, or when a compromised agent replays or misroutes a token across a different client or server boundary.
- Impact is unauthorised access through a confused deputy path, where the server applies legitimate authority to the wrong client, operation or downstream service.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
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 risk is the right mental model for MCP governance. MCP is not simply about authenticating agents or hardening API calls. It is about stopping a legitimate server from applying valid authority to the wrong client or operation, which is why per-client consent and audience validation sit at the center of the specification. Practitioners should treat authorization binding, not login success, as the control boundary.
Session assumptions fail when the caller is a nonhuman identity. Session-based authentication was designed for interaction patterns where a human session persists long enough to be managed and reviewed. That assumption breaks when agents generate requests dynamically and may forward data across multiple trust boundaries in one workflow. The implication is that MCP governance must move from stateful trust to request-scoped verification.
Token reuse becomes an architectural liability in agentic systems. Tokens that are acceptable in conventional application flows become dangerous when agents, middleware and tools can copy or echo them across boundaries. This is especially relevant to NHI governance because token scope, audience and lifetime are now as important as issuance. Practitioners should expect auditability to depend on precise token containment, not broad credential portability.
Per-request authorization is the new control point for NHI and agent interactions. The specification effectively turns every MCP call into a miniature authorization event, with server-side enforcement, exact redirect URI matching and state validation as the minimum baseline. That shifts identity governance from durable session oversight to runtime decision integrity. Teams should reframe MCP design reviews around request binding, not just identity proofing.
Runtime consent needs a named control concept: authorization binding. In MCP, authorization binding means the approved client, the token audience and the specific operation must stay linked at execution time. Without that linkage, a valid identity can still become the wrong deputy. The practical lesson is that governance must prove who may act, for which client, and on which request, every time.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Authorization binding will become the defining MCP control. Teams will get more value from proving that each request is tied to the right client, audience and operation than from adding another layer of session state. That changes governance reviews from identity confirmation to execution integrity, which is a better fit for nonhuman behaviour.
The broader lesson for NHI and agentic programmes is that token portability should be treated as a risk signal, not a convenience. When a token can move too freely between components, the organisation has lost visibility into who is actually authorised to act, and the resulting blast radius is larger than a standard application flow suggests.
For practitioners
- Enforce client-bound consent Map each approved user-to-client relationship to explicit scopes, then reject requests that do not match the approved client identifier and operation.
- Eliminate session authentication Remove session cookies and other server-maintained authentication state from MCP flows, and require token validation on every request instead.
- Block token passthrough Validate tokens directly with the authorization server and use token exchange for downstream access rather than forwarding the original token.
- Tighten OAuth flow controls Use PKCE, exact redirect URI matching, cryptographically random state values and audience validation as mandatory checks in every MCP deployment.
- Adopt workload identity for stronger trust boundaries Use certificate-based authentication or federated workload identities where higher assurance is needed, especially across dynamic server and agent estates.
Key takeaways
- MCP security best practices are built around confused deputy prevention, not just login verification or token issuance.
- Session-based trust and token passthrough do not fit agentic request patterns because they hide who is actually acting.
- Per-client consent, audience validation and exact redirect handling are the controls that make MCP authorization defensible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on MCP authentication requirements and request-bound verification for nonhuman identities. |
| NHI-10 — Human Use of NHI | The confused deputy pattern arises when human-granted authorisation is misapplied by machine actors. | |
| Recommendation — Enforce request-bound authentication so MCP clients cannot rely on inherited or reused trust. Separate human consent from machine execution so user approval does not over-authorise MCP clients. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article describes agents and tools abusing identity context across trust boundaries. |
| Recommendation — Bind agent privileges to the exact client, audience and request context before execution. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Token reuse and passthrough create credential abuse paths that extend across services. |
| Recommendation — Map token replay and cross-service abuse to credential access and lateral movement detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP authorization depends on explicit permissions and per-request entitlement checks. |
| Recommendation — Validate entitlements at each MCP request instead of relying on prior authentication state. | ||
Key terms
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
- Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
- 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.
- Per-Client Consent: A control pattern that records which specific client applications a user has approved, along with the exact scopes granted. It prevents one authenticated client from inheriting the user’s trust for another client or another task.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org