MCP security is an authorization crisis for AI agents

At a glance

What this is: Pomerium’s analysis says MCP creates an authorization problem for AI agents because delegated tool use can expand into multiple valid but unintended actions without breaking authentication.

Why it matters: IAM and security teams need to treat agentic tool use as a per-request authorisation problem, because session trust and coarse network controls do not preserve user intent across delegated actions.

Context

MCP security becomes an identity and authorisation problem when a user delegates a task to an AI agent that can choose tools, compose calls, and execute actions across systems. In that model, the security question is not whether the agent can authenticate, but whether each downstream action still matches the originating intent and authority.

Pomerium’s analysis shows why session-based trust breaks down in delegated workflows. Once authority is flattened into a shared service identity or inherited from an initial login, least privilege and auditability degrade even when every API call is technically valid.

Key questions

Q: What breaks when MCP authorisation is only checked at session start?

A: The system loses the ability to judge whether later tool calls still match the original intent. An agent can reuse valid session trust to issue broader queries, updates, or exports without a new decision point, so the control becomes too coarse for delegated execution.

Q: Why do authorised MCP sessions still create data security risk?

A: Because approval to call a tool does not guarantee the payload is safe. An authorised AI client can still pass PII, credentials, restricted content, or unsafe arguments through the session, and those values can be stored, forwarded, or echoed back unless the traffic is inspected.

Q: How do security teams know whether MCP authorization is actually working?

A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.

Q: What is the difference between agent delegation and ordinary service-to-service access?

A: Ordinary service-to-service access usually assumes a stable workload and a narrow purpose, while agent delegation can select tools, chain requests, and shift context mid-task. That makes the authorisation decision dependent on semantics and intent, not just on credentials or network path.

Technical breakdown

Identity collapse in MCP delegation

MCP systems often hide the originating user behind an agent or service identity. That matters because downstream services then see a valid caller, but not the principal whose intent should bound the action. When the agent retrieves data, selects a tool, and chains calls, identity can collapse into a generic execution context. The result is not an authentication failure. It is an authorisation model that no longer has a stable subject to evaluate. Practical implication: preserve originating identity across delegated tool calls so each action remains attributable to the correct principal.

Practical implication: preserve originating identity across delegated tool calls so each action remains attributable to the correct principal.

Why session-level authorisation drifts

Traditional sessions assume that once a user or workload is trusted, subsequent requests remain within that trust boundary. Agents break that assumption because they can generate many tool invocations in seconds, change plans mid-session, and react to new input without a new human decision point. A session start check cannot distinguish the benign call from the later broadened query or export. Practical implication: move authorisation from session establishment to the moment of each tool invocation, where the actual parameters and context are visible.

Practical implication: move authorisation from session establishment to the moment of each tool invocation, where the actual parameters and context are visible.

Why Layer 7 enforcement matters more than network controls

Network isolation and service-to-service authentication are useful, but they do not answer the core MCP question: should this specific action be allowed for this principal at this moment? That decision depends on semantic context such as method, path, parameters, and origin, which only exists at Layer 7. If enforcement happens lower in the stack, the system can still permit an unintended but authenticated action. Practical implication: enforce policy where the tool call is understood, not just where the packet is allowed.

Practical implication: enforce policy where the tool call is understood, not just where the packet is allowed.

Threat narrative

Attacker objective: The objective is to induce an authorised agent to perform actions beyond the user’s intended scope while remaining fully authenticated.

1. Entry occurs when a user delegates a support, billing, or CRM task to an MCP-enabled AI agent operating within an existing trusted session.
2. Credentialed access is reused as the agent invokes multiple tools under inherited authority, so each call remains valid even as scope expands.
3. Escalation happens when prompt-influenced instructions or broad parameters widen the action set without a fresh authorisation decision.
4. Impact is the successful execution of unintended downstream actions, such as broader refund queries or data export, without any authentication bypass.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization drift is the correct name for MCP risk: the failure is not that an attacker breaks authentication, but that valid authority keeps expanding after the initial delegation decision. Pomerium’s analysis is useful because it shows the system can remain technically functional while the governance model becomes inaccurate. The practitioner takeaway is that delegated execution needs a new authorisation boundary, not just better model safety.

Identity collapse is the hidden control failure in agentic workflows: when the downstream service sees only the agent or a shared service account, the originating user disappears from enforcement logic. That breaks least privilege, attribution, and reviewability at the same time. In practice, this means MCP governance cannot be separated from identity propagation.

Session trust was designed for bounded human behaviour: that assumption fails when an agent can replan, retarget tools, and chain calls inside one uninterrupted session. The implication is not simply more monitoring. It is that session-based trust is structurally too coarse for delegated, multi-step agent execution.

Layer 7 authorisation becomes the control plane for MCP: coarse network isolation and transport authentication do not answer whether a billing query, refund export, or CRM update is appropriate for the current context. The control gap is semantic, not infrastructural. Practitioners should treat tool invocation as the decision point, not the network session.

Autonomous behaviour would collapse the remaining trust assumptions even further: the assumption that a human can reliably approve or correct each action is only barely adequate when the agent is assistive. If the system can select and sequence tools with runtime independence, those assumptions fail outright. The implication is that identity governance must distinguish between delegated assistance and true autonomy before authorisation logic is designed.

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 drift is the governance pattern teams need to watch: MCP turns one delegated request into a sequence of tool calls, so control quality depends on per-request enforcement rather than session trust. The programme question is whether policy can still see the originating principal at the moment of action, not whether the platform can authenticate the session.

MCP security is now an authorisation architecture issue, not an AI safety sidebar: if an agent can call billing, CRM, or support tools under inherited authority, then coarse network controls will miss the real decision point. In practice, organisations should assume that delegated actions will outpace review unless the identity and intent of each call remain visible.

24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026: that scale shows how quickly MCP environments can accumulate exposure when configuration, delegation, and tool access are not governed together. Teams should treat MCP rollout as a combined identity and secrets problem, not a feature toggle.

For practitioners

• Preserve originating identity through delegation Bind the human or workload principal to each downstream tool call so billing, CRM, and support services can evaluate the real actor, not a flattened agent identity.
• Evaluate authorisation on every tool invocation Treat each MCP action as a fresh decision point and require policy checks on the exact parameters, method, and target resource before execution.
• Move controls to Layer 7 enforcement Apply context-aware policy where the request semantics are visible, because network boundaries and service-to-service authentication cannot judge intent.
• Limit inherited session authority Shorten the trust carried by an established session so an agent cannot reuse broad approval across multiple unrelated actions without reevaluation.

Key takeaways

• MCP shifts the security problem from authentication to authorisation because agents can chain valid actions beyond the original user’s intent.
• Session trust and network controls are too coarse for delegated tool use when the meaningful decision happens at invocation time.
• Identity propagation, per-request policy, and Layer 7 enforcement are the controls that determine whether MCP remains governable.

Key terms

• Authority Drift: Authority drift occurs when different systems hold conflicting versions of identity data and no clear owner resolves the mismatch. It is a governance failure that leads to duplicate work, stale entitlements, and access decisions based on partial or inconsistent records.
• 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 access control: Access control that operates at the application layer by inspecting request attributes such as host, path, headers, and context. In Kubernetes, it allows security teams to express policy in terms closer to application risk than network reachability.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.