MCP security controls are now an identity governance problem

At a glance

What this is: This is an analysis of why MCP security controls have become an identity governance issue, with the core finding that user authentication and broad scopes do not safely authorise every agent, client and tool interaction.

Why it matters: IAM, PAM and NHI teams need to treat MCP as a governed identity layer because weak client validation, token handling and scope design can turn agent coordination into privilege abuse.

Context

MCP turns agent-tool coordination into a standard protocol, which means the identity decisions behind each request matter as much as the model or application doing the work. The problem is not simply that AI agents exist, but that protocol standardisation creates reusable trust paths that can be over-accepted, over-scoped, or forwarded without proper validation.

For IAM and NHI programmes, MCP shifts the control plane from isolated application auth to governed client, token and tool authorisation. Once multiple tools, servers and intermediaries participate in one workflow, the weak point is often not authentication at the edge but how identity and consent are preserved across the full interaction chain.

Key questions

Q: How should security teams govern MCP server authentication in production?

A: Treat MCP authentication as a governed access layer, not a developer convenience. Teams should verify runtime client registration, discovery, resource binding, audit logging, and enterprise identity integration before approving production use. If the provider cannot compose with SSO, provisioning, and revocation, it creates a parallel identity path that is harder to govern and harder to unwind.

Q: Why do MCP implementations need direct token validation instead of token relay?

A: Because relay turns the MCP server into a forwarding point for credentials that can be stolen or replayed elsewhere. Direct validation forces the receiving server to check the token’s audience and legitimacy itself, which keeps authority anchored to the intended service rather than to an intermediary chain.

Q: What breaks when MCP clients share broad scopes?

A: Broad scopes collapse the boundary between authentication and authorization. Every authenticated client can inherit tool reach that was meant for a narrow workflow, which makes abuse and accidental overuse harder to detect. The result is privilege creep inside the MCP layer, with the same overexposure patterns seen in unmanaged service account estates.

Q: What is the difference between per-client consent and general user authentication in MCP?

A: User authentication proves who logged in. Per-client consent proves which application is allowed to act on that person’s behalf. MCP needs both, because a valid user login does not tell the server whether the specific client making the request is trusted to use the requested tool or data path.

Technical breakdown

Why confused deputy risk is central in MCP

A confused deputy occurs when a legitimate server or client applies valid authorisation in the wrong context. In MCP, user authentication is not enough to authorise a specific client application, because another client may reuse that trust relationship if per-client consent is not enforced. The protocol therefore has to bind consent to both the user and the approved client identity, not just the credential presented at login. This is an identity governance problem because the control failure is contextual authorisation, not broken login. If the server cannot distinguish which application is acting, it will apply legitimate access in illegitimate ways.

Practical implication: enforce server-side per-client consent and verify the acting client on every MCP request.

How token passthrough turns intermediaries into theft points

Token passthrough means an MCP server or intermediary forwards a user token instead of validating it directly and obtaining its own downstream authorisation where needed. That pattern creates a long trust chain, and every proxy, logger or middleware hop becomes a potential theft point. Once stolen, the token can be replayed to impersonate the user or service that owns it. The governance flaw is that the original credential is treated as portable evidence of trust across domains that were never meant to share it. Direct validation, token audience checks and scoped delegation break that chain.

Practical implication: reject token relay patterns and validate token audience against the intended MCP server.

Why SSRF and session abuse become protocol-level identity risks

MCP implementations that consume metadata, redirect URIs or session state can be redirected into unsafe network paths if those inputs are not tightly controlled. SSRF turns metadata fields into requests against internal services, while session-based authentication lets attackers target shared state rather than per-request proof. In both cases, the identity issue is that trust moves away from the request itself and into mutable state or untrusted metadata. That makes the protocol easy to abuse across boundaries, especially when the same workflow spans cloud, local and downstream services. Strong URL allowlisting and per-request validation are therefore identity controls as much as network controls.

Practical implication: block session-based auth and validate all metadata URLs and redirect values before any downstream use.

Threat narrative

Attacker objective: The attacker wants to turn a normal MCP trust chain into unauthorised access to tools, data or internal systems without triggering a fresh approval step.

1. Entry occurs when a malicious client, intermediary or server exploits trust in MCP metadata, consent handling or relay behaviour to gain a foothold in the workflow.
2. Credential access follows when the attacker captures tokens through passthrough, weak validation or session handling and can reuse them against legitimate services.
3. Escalation happens when the attacker leverages that inherited trust to invoke broader tools, reach internal resources or trigger actions beyond the intended scope.
4. Impact is unauthorized access to enterprise data, internal services or privileged tool actions through a protocol path that appeared legitimate at each step.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

NHI Mgmt Group analysis

MCP security controls are an identity governance problem, not just a protocol-hardening problem. The article correctly frames MCP as an interoperability layer that moves identity decisions into the path of every tool call, consent check and downstream delegation. Once that happens, identity governance has to cover client identity, token audience, consent registry state and tool scope together. Practitioners should stop treating MCP as a transport detail and start treating it as a governed access plane.

Per-client consent is the control that prevents user authentication from being over-interpreted as universal authorisation. The confused deputy pattern exists because a valid user login is easy to overgeneralise into permission for every client that can reach the same server. That assumption fails as soon as multiple applications can speak the same protocol and consume the same resources. The implication is that authorisation must bind to the acting client, not just the human or workload behind the session.

Token passthrough creates identity blast radius by preserving trust across too many hops. When intermediaries can see or relay the same bearer token, the security boundary shifts from a controlled issuer to whichever component is easiest to compromise. That is why direct token validation and token audience checks matter more than generic transport hygiene. The practitioner conclusion is simple: every additional hop in an MCP path should be assumed to enlarge compromise impact unless it is explicitly re-authorised.

Zero standing privilege becomes harder to preserve when agents can request, relay and reuse access across tools in one workflow. MCP can make privilege feel temporary while actually preserving authority across the full session chain. The result is scope creep that is invisible if teams only review initial authentication events. Identity programmes should therefore evaluate whether tool-level permissions, not just user-level sessions, are the real governance unit.

Secure MCP deployments need a named concept: protocol-spread trust debt. Standardisation makes agent coordination easier, but every reused trust path adds an obligation to prove identity, consent and scope at the right boundary. That debt accumulates when teams assume the protocol itself is the control. Practitioners should treat every MCP deployment as an exercise in reducing trust debt before it becomes operational exposure.

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

MCP is pushing identity governance upstream into the request path, where consent, audience and delegation checks now matter as much as authentication itself. Teams that still rely on generic user sessions will find that protocol-standardised agent workflows create more ways to over-authorise the wrong client than traditional application integrations did.

Protocol-spread trust debt: every place MCP reuses a credential, metadata field or delegated trust path adds an obligation that must be explicitly governed. That debt will show up first as over-broad scope, then as tool misuse, and finally as incident response complexity when no single control owner can explain who was authorised for what.

For NHI programmes, the lesson is that agent identity cannot be treated as a thin wrapper around human login. The control unit becomes the combination of client identity, request context and downstream tool permission, which means governance has to move from static provisioning to continuous request-time verification.

For practitioners

• Enforce per-client consent registries Map each approved client application to explicit user consent and revalidate that mapping on every MCP request. Do not let general user authentication substitute for client-specific authorisation.
• Validate token audience on every request Reject any token whose audience claim does not match the receiving MCP server, even when the token is signed and unexpired. Audience checks prevent portable bearer tokens from being accepted by the wrong service.
• Eliminate token passthrough in all brokered flows Issue scoped downstream credentials to the MCP server itself instead of forwarding the user token through intermediaries. This removes relay points that can expose valid tokens to logging, middleware or proxy compromise.
• Sanitise metadata, redirect and URL inputs Allowlist OAuth metadata endpoints, block private IP ranges and require exact redirect URI matches. Treat untrusted metadata as a network pivot until it has been validated and normalised.
• Move to request-level identity verification Use secretless or ephemeral identities that are checked on every interaction rather than relying on server-maintained session state. That keeps authorisation tied to the current request and reduces session hijacking exposure.

Key takeaways

• MCP security is an identity governance issue because client identity, consent and scope determine whether a valid request should be trusted.
• The main risk is not just token theft, but inherited authority that can be reused across tools, intermediaries and downstream services.
• Practitioners need request-time controls for client consent, token audience validation and URL handling if they want MCP coordination without overexposure.

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.
• 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.
• Protocol-Spread Trust Debt: Protocol-spread trust debt is the accumulated risk created when a standard protocol reuses credentials, consent and delegated authority across many hops. In MCP environments, the debt grows whenever teams assume the protocol itself is enough to prove who is acting and why.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.