Why do MCP and zero trust conflict in agentic environments?

Why This Matters for Security Teams

zero trust assumes every request must be verified, but MCP changes the risk profile because the request can become an instruction stream, not just a lookup. In agentic environments, an identity that is allowed to call a tool may still be unsafe if the agent is manipulated, over-scoped, or able to chain actions faster than humans can review them. That is why the conflict is not theoretical.

NHIMG research on The State of MCP Server Security 2025 shows how quickly trust assumptions break when tool access is embedded in configuration and execution paths. The parallel risk on the agent side is visible in AI Agents: The New Attack Surface report, where rogue actions and scope creep already appear in live deployments. That combination creates a gap between policy intent and runtime reality.

Current guidance suggests that organisations should treat MCP not as a simple integration layer, but as an execution surface that must be governed separately from identity approval. The zero trust model from NIST SP 800-207 Zero Trust Architecture remains important, but it does not on its own decide whether a tool call is safe in context. In practice, many security teams encounter MCP misuse only after an agent has already chained actions beyond its intended scope, rather than through intentional design review.

How It Works in Practice

The practical fix is to split identity, authorization, and execution control into separate checks. Zero trust still evaluates who or what is asking, but MCP governance must also evaluate what the agent is trying to do, which tool is being invoked, and whether that action fits the current task context. For autonomous systems, best practice is evolving toward runtime policy evaluation rather than static allowlists alone.

That is why teams increasingly combine workload identity, short-lived credentials, and policy-as-code. Workload identity proves the agent instance or service, while just-in-time access limits how long the agent can act. Runtime policies can then decide whether a given MCP tool call is permitted in that moment. This model aligns with emerging recommendations in the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework.

• Use zero trust to verify the caller, then apply context-aware authorization to verify the task.
• Issue ephemeral secrets per tool call or per workflow step instead of long-lived static tokens.
• Log tool invocation intent, arguments, and downstream side effects as separate events.
• Restrict high-risk actions such as deletion, exfiltration, or privilege escalation to explicit approval paths.

This approach is reinforced by NIST AI governance thinking in the NIST AI Risk Management Framework, which emphasizes measurable controls and ongoing monitoring. It also matches NHIMG guidance across the OWASP Agentic Applications Top 10, where prompt injection, overbroad tool use, and hidden action chains are recurring failure modes. These controls tend to break down when MCP servers are treated as trusted internal plumbing because agents can still pivot through approved tools into unapproved outcomes.

Common Variations and Edge Cases

Tighter MCP control often increases workflow friction, requiring organisations to balance automation speed against the cost of review, token issuance, and policy maintenance. That tradeoff is especially visible in developer tooling, SOC automation, and customer support agents, where teams want broad access for efficiency but need narrow permissions for safety.

There is no universal standard for this yet, so implementations differ. Some teams enforce approval only for destructive actions, while others require intent checks for every tool call. Some environments can rely on strong workload identity and scoped OIDC tokens, but air-gapped or legacy systems may not support fine-grained runtime policy enforcement. In those cases, compensating controls such as gateway mediation, session recording, and tool-level rate limits become more important.

Edge cases also appear when an agent can chain benign actions into a harmful sequence. A single MCP request may look safe under zero trust, yet the sequence can still leak data or create privilege escalation. NHIMG coverage of incidents such as CoPhish OAuth Token Theft via Copilot Studio and Analysis of Claude Code Security shows why tool authorization must account for chaining, not just isolated requests.

For this reason, current guidance suggests treating MCP as an execution risk layer that sits on top of identity trust, not inside it. Where organisations fail is usually not in choosing zero trust, but in assuming that a trusted agent will behave like a trusted human.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• What do security teams get wrong about zero trust in agentic access environments?
• What breaks when agents trust MCP tool descriptions by default?
• What are MCP Authorization Extensions and how do they help organizations?