MCP security controls are now an identity governance problem

At a glance

What this is: MCP turns agent-to-tool connectivity into an identity and authorisation problem, with confused deputy risk the clearest control failure.

Why it matters: IAM, PAM, and NHI programmes have to treat every agent, server, and tool as a separately verified identity if they want to contain delegated access across human, machine, and autonomous workflows.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Aembit's analysis of MCP security controls and agentic identity risk

Context

Model Context Protocol, or MCP, standardises how AI agents talk to tools and data sources. That consistency is useful for integration, but it also creates repeatable identity and authorisation patterns that attackers can exploit when consent, token handling, and scope enforcement are weak.

For IAM teams, the issue is not whether an agent can call a tool. The issue is whether the receiving system can prove which client is acting, which token is valid for that server, and whether the resulting access stays within the intended task boundary.

Key questions

Q: How should security teams govern MCP access in agentic workflows?

A: Security teams should govern MCP access as delegated identity, not simple application connectivity. That means binding consent to the client, validating the token audience, refusing passthrough, and constraining each tool call to the narrowest possible scope. If those controls are not enforced per request, an authorised login can become an unauthorised action path.

Q: Why do MCP implementations create confused deputy risk?

A: MCP creates confused deputy risk when a server treats user authentication as enough to authorise any client that can present the token. The user may have approved one application, but another component can reuse that trust relationship and act with the same privileges. The failure is in delegation logic, not in the original sign-in event.

Q: What breaks when token passthrough is allowed in MCP?

A: When token passthrough is allowed, every intermediary becomes a credential capture point and every downstream service inherits more trust than intended. A stolen bearer token can be replayed against the wrong resource if audience checks are weak or absent. That turns transport convenience into broad privilege exposure.

Q: Who is accountable when an MCP server authorises the wrong action?

A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.

Technical breakdown

Confused deputy attacks in MCP environments

The confused deputy problem appears when a legitimate server or client applies valid user authorisation to the wrong requester. In MCP, that means user authentication is treated as sufficient proof for any client that can present it, even when the user only consented to one application. The failure is not weak identity alone. It is incorrect delegation logic across clients, consent registries, and downstream tool calls. Per-client consent validation closes that gap only when it is enforced server-side on every request, not inferred from the original login event.

Practical implication: maintain server-side consent mapping between users, clients, and scopes so one authorised application cannot impersonate another.

Token passthrough, audience checks, and session hijacking

MCP’s security model rejects token passthrough because relaying credentials through intermediaries multiplies the theft surface. Every token must be validated directly against the authorisation server and checked for the correct audience, otherwise a signed token can still be replayed against the wrong MCP server. Session-based authentication is also dangerous in multi-server workflows because a stolen session can be reused to inject malicious events into shared streams. The protocol’s insistence on request-level token validation reflects a broader identity rule: delegation should be explicit, bounded, and re-checked at each hop.

Practical implication: ban token relays, enforce exact audience validation, and prefer per-request token checks over any server-maintained session state.

Scope minimisation and zero-trust for agentic tool use

Scope minimisation failures happen when an MCP implementation requests broader permissions than the task needs. In practice, this turns a single compromised integration into a broad privilege problem because the attacker inherits the maximum scope granted, not the minimum needed for the workflow. Zero trust for MCP therefore means verifying every agent, tool, and request as a distinct identity event, then constraining access to the exact operation and data class required. For local servers, the same principle extends to filesystem and command access, where explicit consent and input sanitisation become part of identity control.

Practical implication: design policies around task-scoped permissions and block broad scopes such as read-all-data when a specific resource grant will do.

Threat narrative

Attacker objective: The attacker aims to turn legitimate agent or server trust into unauthorised access to tools, data, or internal infrastructure without breaking the original authentication event.

1. entry: A malicious client or compromised intermediary enters through weak consent handling, token passthrough, or an unsafe metadata discovery path in an MCP implementation.
2. escalation: The attacker reuses valid credentials, exploits confused deputy behaviour, or triggers SSRF to reach internal endpoints and higher-privilege resources.
3. impact: The result is unauthorised tool execution, credential exposure, or unwanted access to internal services and data through a trusted MCP flow.

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

MCP is really a delegation-control problem disguised as a protocol question. Standardisation makes agent-to-tool interoperability easier, but it also makes authorisation failures repeatable at scale. Once multiple clients, servers, and resources share a common interaction model, any gap in consent validation or token handling becomes a reusable attack pattern. Practitioners should read MCP as identity infrastructure first and integration plumbing second.

Per-client consent is the control that separates user intent from client capability. User authentication alone was designed for a world where the authenticated party and the acting party are the same thing. That assumption fails when one user-approved application can trigger another client or intermediary to act on its behalf. The implication is that consent must be tied to the client identity, not just the user session.

Token passthrough is a standing credential problem in a new wrapper. Forwarding a user token through intermediaries preserves trust too broadly and extends the credential's usefulness beyond the original boundary. That pattern turns every proxy, logger, and middleware component into a potential capture point. Practitioners should treat any architecture that relays bearer tokens as a trust-amplification design, not a convenience feature.

Scope minimisation fails when task intent is known only at runtime. MCP implementations often know what the agent needs only after the interaction begins, which means provisioning-time privilege assumptions can be too broad or too narrow. Granular policy is therefore the relevant control, but the deeper point is that static scope assignment does not fit dynamic agent workflows cleanly. Security teams should expect scope drift to show up first in tool-rich environments.

Identity blast radius: MCP makes the consequences of one weak client or one overbroad token propagate across several systems at once. That is not just privilege creep, it is delegated access becoming chainable across tools, resources, and authentication boundaries. The practitioner takeaway is to model the downstream radius of each agent identity before production rollout.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control baseline, see OWASP Agentic AI Top 10 for how identity, tool use, and delegation risks cluster.

What this signals

Runtime delegation will become the core governance issue for MCP deployments. Teams that treat MCP as a transport standard will miss the control reality: the risk sits in who may act, on what resource, under which client identity, and with what downstream scope. The practical programme change is to inventory MCP paths as identity pathways, not just integration endpoints, and to align them with the NIST AI Risk Management Framework where agentic decision-making is involved.

Scope creep is the earliest sign that agentic access is drifting beyond its intended boundary. Once an MCP integration needs broad data access to keep working, the policy model is already lagging the workflow. A better signal is whether each agent can prove task-scoped legitimacy at request time, which is where the OWASP Agentic AI Top 10 becomes directly useful.

Per-client consent becomes the named control gap teams should watch. As more workflows traverse multiple tools, the risk is no longer that an agent can connect, but that the wrong client can inherit the right token. That is why MCP programmes should be reviewed alongside workload identity, secretless access, and least-privilege enforcement, not in isolation.

For practitioners

• Enforce per-client consent registries Map each approved user-to-client relationship server-side and require every MCP request to match a specific client identity and granted scope. Do not treat general user login as permission for any application that can present the token.
• Block token relay paths Prohibit token passthrough through proxies, middleware, and logging layers. Issue server-specific credentials for downstream calls and verify token audience on every validation event.
• Constrain MCP scopes to task boundaries Replace broad permissions such as read-all-data with resource-specific grants that match the workflow step. Review any integration that asks for more access than the operation actually needs.
• Harden discovery and local execution paths Allowlist OAuth metadata URLs, block private IP and link-local targets, and require explicit consent before filesystem or command execution in local MCP deployments.

Key takeaways

• MCP standardisation improves interoperability, but it also turns delegation mistakes into repeatable identity failures across tools and servers.
• Confused deputy abuse, token passthrough, SSRF, and scope minimisation failures are the main control gaps practitioners need to model before rollout.
• Per-client consent, token audience validation, and task-scoped access are the controls most likely to contain MCP risk in production.

Key terms

• Confused Deputy: A confused deputy is a system that has legitimate authority but applies it on behalf of the wrong requester. In MCP environments, the risk appears when user approval for one client is reused by another, so the server cannot distinguish user intent from client identity. The failure is in delegated authorisation, not in authentication alone.
• Token Passthrough: Token passthrough is the practice of forwarding a bearer token through intermediaries instead of validating it directly and issuing a scoped replacement credential. In MCP, it expands the attack surface because any proxy, logger, or middleware layer can capture the token and replay it elsewhere. The safer pattern is direct validation with fresh, bounded credentials.
• Per-Client Consent: Per-client consent is a server-side control that binds user approval to a specific application or agent identity, along with the scopes it may use. It prevents one authenticated session from becoming blanket permission for every connected client. In MCP, this is essential because user login and acting client are often not the same entity.
• Scope Minimisation: Scope minimisation is the practice of granting only the permissions needed for a specific task or transaction. For MCP and other non-human identities, it must be evaluated at the workflow level because agents can chain tool use quickly and expand exposure if granted broad scopes. The control reduces blast radius when a client is compromised.

Deepen your knowledge

MCP security controls for agentic workflows are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are translating protocol design into governance decisions, it is worth exploring.

This post draws on content published by Aembit: MCP security controls for agentic AI and identity governance. Read the original.