MCP security is an authorization crisis for AI agents

At a glance

What this is: This is an analysis of why MCP security is fundamentally an authorization problem, with the key finding that delegated agent actions can exceed the intent of the original user session.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern tool-using agents as delegated identities, not as passive API clients or simple automation.

👉 Read Pomerium's analysis of why MCP security is an authorization crisis

Context

Model Context Protocol, or MCP, changes how authority moves through software because an agent can select tools, compose calls, and execute actions on behalf of a user. The primary security question is no longer whether a login succeeded, but whether each delegated action should be permitted in its specific context.

That shift exposes a governance gap for IAM and NHI teams. Traditional models often evaluate trust at session start, but MCP workloads can expand the practical blast radius of a single approval across multiple downstream systems, making per-request authorization and identity continuity central design concerns.

Key questions

Q: How should security teams govern AI agents that use MCP tools?

A: Treat the agent as a delegated identity with bounded authority, not as a passive integration. Require per-request authorization, preserve the originating user context on every tool call, and enforce policy where the request semantics are visible. That approach limits authorization drift and makes downstream actions auditable in a way session-only trust cannot.

Q: Why do session-based controls fail for MCP workloads?

A: Session-based controls assume the trust decision made at login remains valid across the session. MCP breaks that assumption because an agent can reinterpret input and execute many tool calls in a short period. The control failure is not authentication, but the widening gap between the original approval and the actual action being taken.

Q: What do organisations get wrong about MCP security?

A: They often focus on network isolation or prompt filtering and miss the real issue: an authorised workload can still perform an unintended action. MCP security fails when teams trust transport and service authentication to answer an authorization question that only the request context can resolve.

Q: How can teams reduce the blast radius of tool-using agents?

A: Limit the tools, parameters, and data domains an agent can reach, and evaluate each invocation against the originating principal and task scope. The goal is to prevent a single delegated request from becoming broad data access or cross-system action without a fresh authorization decision.

Technical breakdown

Identity collapse in delegated tool chains

MCP systems often abstract the initiating person away once an agent begins acting, leaving downstream services to see only a service identity or shared credential. That flattening creates identity collapse: the system can authenticate the request but still lose the provenance needed to decide whether the action matches the original intent. In practice, the agent becomes a decision layer with delegated authority, and the control problem moves from who logged in to who is actually acting at each step. This is why coarse service identity handling is insufficient once the agent can chain tool use across systems.

Practical implication: bind user context to each downstream call so the initiating principal survives delegation.

Session-level trust and authorization drift

Session-based authorization assumes the trust decision made at login remains valid for the rest of the interaction. MCP breaks that assumption because an agent can reinterpret input, change its plan, and issue many tool calls within the same session window. The result is authorization drift, where the original justification for access becomes less relevant with each new action. This is not an authentication failure. It is a mismatch between static trust decisions and dynamic execution paths, which is why session start is the wrong place to freeze permission.

Practical implication: evaluate authorization at the moment of each tool invocation, not only at session establishment.

Layer 7 enforcement for MCP authorization

Network controls can prove that traffic came from an approved system, but they cannot tell whether a specific method, parameter set, or data scope is appropriate. MCP security therefore needs enforcement at Layer 7, where semantic context exists and policy can account for the exact action being requested. This is the difference between allowing an authenticated workload onto the network and authorizing a particular refund lookup, export, or update. Without request-level enforcement, organisations implicitly trust the agent to self-limit, which is the opposite of principled authorization.

Practical implication: place policy enforcement where request semantics are visible, not just where network connectivity is established.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Authorization, not model safety, is the core MCP governance problem. The article is right to move the debate away from prompt filtering and toward the control plane that decides what an agent may do. MCP makes the agent an active decision-maker, which means the security question becomes whether delegated authority is still bounded when tool selection and execution happen inside the same runtime path. Practitioners should treat MCP as an authorization architecture problem, not an AI content problem.

Identity collapse is the named failure mode this category is exposing. The original user identity disappears behind a delegated service identity, and that works only as long as the downstream blast radius stays narrow. Once the agent can chain actions across systems, provenance is flattened, audit trails weaken, and accountability becomes harder to reconstruct. The implication is that existing identity models for static API clients do not hold when the executor can compose its own action path.

Session-based trust was designed for human-paced interaction, and that assumption fails under agentic execution. A session establishes trust for bounded, user-initiated requests. That assumption fails when the actor can reinterpret input and issue multiple tool calls in seconds without a fresh approval gate. The implication is that governance processes built around fixed session windows no longer describe the real risk surface.

Per-request authorization is the control boundary MCP has made unavoidable. The article shows that network isolation and service authentication do not answer the question that matters most: whether this specific invocation, at this moment, should proceed. That shifts the discipline from connectivity control to contextual authority control, which is a material change for IAM, PAM, and NHI teams. Practitioners should re-evaluate every place where a broad session currently substitutes for a specific decision.

Layer 7 policy becomes the new identity chokepoint for tool-using agents. When the agent can pass valid network and service checks but still perform the wrong action, lower-layer controls have already missed the critical decision. The practical conclusion is that MCP exposes a governance gap between authenticated transport and authorised intent, and that gap is where modern identity programmes must focus.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most environments cannot reliably trace non-human access paths end to end.
• Use OWASP Agentic Applications Top 10 to map agentic authorization, tool misuse, and delegation risk into a concrete control framework.

What this signals

Identity collapse is the operational signal that MCP governance is slipping from user-centered access control into opaque delegated execution. Teams should expect more pressure to prove who initiated a tool call, which context survived the handoff, and where the authorization decision was actually made.

The practical planning shift is toward request-level policy, provenance preservation, and narrower tool scopes for agentic workloads. Without those controls, MCP deployments will continue to look authenticated while still behaving outside the intent of the original user session.

For practitioners

• Map delegated agent identities to the originating user Preserve the initiating principal across tool calls so billing, CRM, and support actions retain user context instead of collapsing into a generic service account. This is the minimum requirement for traceable MCP governance.
• Move authorization decisions to each tool invocation Re-check policy when the agent calls a billing API, exports data, or updates a record, rather than relying on the trust granted when the session began. This prevents session drift from becoming open-ended authority.
• Enforce policy at Layer 7 with semantic context Inspect method, path, parameters, and originating principal before allowing action, because network-level allow rules cannot distinguish a legitimate summary from a broad refund export. This is where MCP requests must be judged.
• Tighten privilege on agent tool sets Limit the tools, scopes, and data domains an agent can reach so prompt injection or instruction abuse cannot expand into unrelated billing or CRM actions. Narrow scope reduces the effect of delegated misuse.

Key takeaways

• MCP turns authorization into the primary control problem because agents can act across multiple systems inside a single delegated workflow.
• The risk is not a broken login flow but a widening gap between original intent and the actions an agent is permitted to take.
• Practitioners need per-request policy, preserved identity context, and Layer 7 enforcement if they want MCP governance to hold up under real use.

Key terms

• Authorization drift: Authorization drift is the widening gap between the access a session was granted and the actions actually performed later in that session. In MCP environments, agents can change plans, chain calls, and stretch the original approval beyond its intended context, making static trust decisions progressively less reliable.
• Identity collapse: Identity collapse happens when the originating user’s identity is flattened into a generic service or agent identity during delegation. Downstream systems can still authenticate the request, but they lose the provenance needed to judge intent, assign accountability, or enforce context-specific authorization.
• Layer 7 enforcement: Layer 7 enforcement is policy control applied at the application request layer, where method, path, parameters, and identity context are visible. It is essential in MCP because lower network layers can confirm connectivity but cannot decide whether a specific tool action matches the approved intent.

Deepen your knowledge

MCP authorization and delegated identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents that can select tools and act across systems, it is worth exploring.

This post draws on content published by Pomerium: MCP Security: Why MCP Is an Authorization Crisis. Read the original.