MCP breaks zero trust by shifting control into execution

At a glance

What this is: This is an analysis of how MCP moves AI agent activity into an execution layer that bypasses traditional zero trust decision points.

Why it matters: It matters because IAM and security teams now have to govern not just who or what can connect, but whether an AI-driven action should execute at the moment of use.

Context

MCP, or Model Context Protocol, standardises how AI agents connect to tools and services, but that standardisation also shifts operational risk into the moment of execution. Traditional zero trust models were built to evaluate requests against identity, device posture, and context, not to decide whether an AI agent’s tool invocation is appropriate once the workflow is already in motion.

The governance gap is therefore not only access control but execution control. When an agent can discover tools, invoke them dynamically, and act on prompt-influenced instructions, identity alone no longer answers the security question that matters most: should this action happen at all?

For identity programmes, that creates a new boundary between access approval and runtime behaviour. NHI, agentic AI, and human governance now intersect at the point where trust is assigned too early and revoked too late.

Key questions

Q: What breaks when MCP servers are generated without runtime controls?

A: Call volume grows faster than oversight. Agents can reach more tools, but the organisation loses the ability to explain which model invoked which service, whether the call was authorised, and how correlated failures or spend spikes should be attributed. The result is connector sprawl without operational accountability.

Q: Why does MCP increase risk even when zero trust and IAM are in place?

A: Because those controls primarily answer who can access a resource, not whether an agent’s chosen action is appropriate right now. If the agent can discover tools dynamically or follow malicious input, identity and network controls may all succeed while the executed action is still unsafe.

Q: How do security teams know if an MCP deployment is outside its intended boundary?

A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch. Strong warning signs include localhost servers accessible from the browser, public endpoints with no auth, and tool catalogs that exceed the intended use case.

Q: How should teams enforce MCP tool permissions before an agent executes a sensitive action?

A: Teams should evaluate the actual request before execution, not just the OAuth scope or access token. The MCP server or gateway should validate, freeze, and policy-check the proposed call, including recipient, body, and declared intent. If the policy denies the action, times out, or needs approval, the system should stop the send and require a separate approved path.

Technical breakdown

Why MCP changes the control plane for AI agents

MCP standardises the way agents connect to external tools, data sources, and services, which makes integration easier but also shifts decision-making closer to execution. In a traditional model, identity and access control determine whether a subject can reach a resource. In an agentic flow, the agent can discover tools, select one dynamically, and act inside an approved workflow before any separate judgment is made about the action itself. That is a structural change, not just an implementation detail. Zero trust still matters, but it now covers only part of the path. The missing layer is evaluation of intent, context, and downstream impact at the moment the tool call is made.

Practical implication: Treat MCP-enabled execution as a separate control boundary and require runtime policy enforcement at the tool invocation point.

Why identity alone no longer proves action safety

Traditional IAM answers who is making the request and whether that subject is allowed in principle to access the target. That works when the request is predictable, but AI agents can generate requests based on live context, retrieved data, and external instructions. The result is that an authenticated internal system can still issue an unsafe action. This is where context becomes the security control, not just an enrichment field. Data sensitivity, system criticality, workflow state, and prompt influence all matter. Without those signals, least privilege is reduced to static entitlement management while the actual risk is created at runtime.

Practical implication: Add decision logic that evaluates the agent’s action, not only the identity behind the session.

How prompt injection and over-permissioned tools amplify MCP risk

MCP does not create risk in isolation. It concentrates it by connecting agents to tools that may already be too permissive, poorly inventoried, or insufficiently governed. If an agent can invoke a broad tool surface, then malicious input can steer that surface toward exfiltration, workflow manipulation, or other unintended actions. The control problem is therefore a combination of tool sprawl, insufficient permission scoping, and weak invocation governance. From an NHI perspective, this resembles overprivileged machine access. From an agentic perspective, it is worse because the actor can decide what to call next, extending the blast radius within the same session.

Practical implication: Inventory MCP servers, constrain their permissions, and block unverified tool paths before they can be reached by agents.

Threat narrative

Attacker objective: The attacker seeks to turn trusted agent execution into a mechanism for data exfiltration, workflow manipulation, or broader tool abuse.

1. Entry occurs when an AI agent reaches tools through MCP inside an approved internal workflow, which means the initial request is already treated as trusted.
2. Escalation follows when the agent dynamically discovers additional tools or invokes over-permissioned ones beyond the original task boundary.
3. Impact occurs when prompt-influenced execution or malicious input drives the agent to exfiltrate data or manipulate downstream workflows without a separate human decision point.

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.
• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

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

MCP creates an execution-layer trust gap: Zero trust was built to govern access decisions, not to arbitrate whether an AI agent’s action should proceed once a tool call is already in flight. That is why MCP changes the problem space from authorisation to runtime governance. The implication is that identity proof alone no longer tells practitioners whether a request is safe.

Identity does not equal intent when agents execute tools: An authenticated agent can still carry out the wrong action because the security question has shifted from who asked to what the system is about to do. This is not a failure of authentication so much as a mismatch between identity controls and autonomous action sequencing. Practitioners have to stop treating successful authentication as evidence of safe behaviour.

Context-aware decision-making is the missing control layer: MCP makes tool invocation the new enforcement point, which means data sensitivity, workflow state, and system criticality become part of the authorisation decision. That is a governance requirement, not a monitoring enhancement. The field needs controls that sit at execution time, because post hoc review cannot undo an unsafe agent action.

Overprivileged tool surfaces now resemble overprivileged NHIs: When agents can discover and invoke broad MCP tools, the blast radius depends on how tightly those tools are scoped and whether their permissions were designed for machine speed. This is a familiar NHI pattern expressed through a new interface. The practitioner takeaway is to govern the tool surface as a privileged identity boundary, not as a mere integration layer.

Shadow AI becomes a visibility problem only after it becomes an execution problem: If teams cannot inventory which MCP servers are active or how they are invoked, they cannot govern their control surface. The named concept here is the execution-layer trust gap, which describes the space where access has been approved but action has not been judged. Practitioners need to close that gap before agent adoption outruns policy.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Execution-layer trust gap: MCP forces practitioners to move governance closer to the actual tool call, because an approved identity is no longer enough to justify an action. This is where traditional zero trust models stop being complete and where runtime policy starts to matter more than static entitlement.

The practical shift is from access review to invocation review. If the agent can choose tools, change course, and act inside a trusted workflow, then the programme has to judge context, not just control entry points. That change affects both NHI governance and emerging agentic AI controls.

53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.

For practitioners

• Define an execution control point for MCP traffic Place policy enforcement at the agent-to-tool boundary so each invocation is evaluated before downstream action occurs. Do not rely on upstream authentication or workflow approval as proof that the action itself is safe.
• Inventory every MCP server and connected tool Create and maintain a live list of MCP servers, the tools they expose, and the permissions each one can exercise. Unknown or unowned servers should be treated as uncontrolled execution paths.
• Scope tools for the minimum agent task Reduce tool permissions to the narrowest viable action set and remove broad, catch-all entitlements that let agents branch into unrelated operations.
• Block unverified tool invocation paths Require explicit verification for newly discovered or previously unseen tools before an agent can call them in production workflows.
• Add context signals to authorisation decisions Use data sensitivity, system criticality, and workflow state when deciding whether an agent action should execute, rather than relying on identity alone.

Key takeaways

• MCP turns AI agents into runtime actors that can reach tools through trusted workflows, which exposes a control gap that identity alone cannot close.
• The risk is not only access sprawl but decision sprawl, because the system can still execute unsafe actions after authentication succeeds.
• Practitioners need execution-time policy, tight tool scoping, and live inventory of agent-facing services to keep AI workflows within governance boundaries.

Key terms

• Execution Layer: The execution layer is the operational point where identity policy becomes system change. It is where approvals, provisioning, revocation, and session controls either complete successfully or fail in ways that create drift. For practitioners, this is where governance is proven, not merely documented.
• Execution-Time Policy Enforcement: Execution-time policy enforcement checks each proposed action immediately before it runs and blocks anything outside policy. This approach matters for autonomous agents because it still works when the agent is in a permissive mode or operating on untrusted inputs. It turns written rules into a real control.
• Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
• Execution-Layer Trust Gap: The gap between approved access and safe action when a system can reach a tool or service but still needs a separate judgment about whether the action should proceed. In AI agent governance, this gap grows when workflows trust the request source instead of the action itself.

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.