Why do MCP attacks bypass many zero trust controls?

Because zero trust can verify the source of a request without verifying that the request still means what it meant at approval time. MCP attacks exploit that gap by altering tool behaviour, injecting instructions, or shifting context after authorisation, while the session still looks legitimate.

Why This Matters for Security Teams

MCP changes the attack surface because it sits between a model, its tools, and the systems that hold real privileges. zero trust still matters, but NIST SP 800-207 Zero Trust Architecture was designed around verifying identities, devices, sessions, and policy decisions, not continuously validating whether an AI-driven request has been semantically altered after approval. That distinction is where many teams get caught.

Attackers do not need to defeat authentication if they can manipulate the meaning of a request once the session is active. In MCP environments, prompt injection, tool hijacking, poisoned context, and unsafe delegation can all turn a legitimate connection into an abusive action path. Current guidance suggests treating the model, the tool broker, and the downstream service as separate trust boundaries, rather than assuming one trust decision covers all three.

This matters because security teams often overfocus on login hardening and underfocus on what the model is actually allowed to do with authenticated access. The result is that policy says “trusted,” while the tool call that follows is doing something entirely different. In practice, many security teams encounter MCP abuse only after a legitimate session has already been used to exfiltrate data or trigger unauthorized actions, rather than through intentional control testing.

How It Works in Practice

MCP attacks usually succeed by exploiting the gap between authorization and execution. A user, agent, or integration may be approved to access a server, but the request content can be manipulated after that approval. The model may receive malicious instructions embedded in retrieved content, hidden prompts, or tool output, then pass those instructions to an MCP-enabled action with the appearance of a normal session. That is why the issue is not just authentication, but context integrity and action governance.

Security teams should think in terms of control layers:

• Authenticate the caller and the tool endpoint, but also verify the origin and integrity of the content being processed.
• Constrain tool scopes so an agent can only invoke the minimum actions required for the task.
• Log model inputs, tool selections, and downstream side effects so behavior can be reconstructed later.
• Require human review or step-up controls for high-impact actions, especially when external content can influence the request.

OWASP’s agentic guidance, including the OWASP Agentic AI Top 10, reflects this shift toward securing the decision path, not just the session. The practical control problem is to separate trusted identity from trusted intent, because a valid token can still carry malicious instruction chains. Teams should pair policy enforcement with output validation, tool allowlisting, and context filtering, and use sources such as Anthropic’s first AI-orchestrated cyber espionage campaign report to understand how attackers chain legitimate capabilities into abusive workflows. These controls tend to break down in multi-tenant agent platforms with shared connectors because context boundaries and privilege boundaries are often enforced inconsistently.

Common Variations and Edge Cases

Tighter tool approval often increases operational overhead, requiring organisations to balance resilience against developer speed and agent usefulness. That tradeoff is real, and best practice is evolving because there is no universal standard yet for how much context inspection is enough for MCP.

Some environments rely on read-only tools, assuming they are low risk. That assumption can fail when read-only data feeds influence later actions, such as ticket creation, code generation, or approval workflows. Other teams enforce zero trust at the network layer but leave the model free to chain tools once it is inside the perimeter, which creates a false sense of safety. The same issue appears in retrieval-heavy designs, where a poisoned document or malicious prompt can alter downstream behavior without breaching a perimeter control.

Where higher assurance is needed, teams should combine zero trust with agent-specific controls from the OWASP Top 10 for Agentic Applications 2026, plus adversarial AI threat modeling from the MITRE ATLAS adversarial AI threat matrix. Guidance is strongest when the MCP server is tightly bounded, the tool catalog is small, and all high-risk actions are logged and reviewable. The model of “authorize once, trust forever” breaks down in environments with dynamic retrieval, loosely governed plugins, or user-supplied content that can influence tool selection after session establishment.

Related resources from NHI Mgmt Group

• Why do Microsoft 365 and Intune attacks bypass many endpoint controls?
• Why do browser-based attacks bypass many IAM controls?
• Why do browser attacks bypass so many traditional security controls?
• How do Zero Trust controls apply to MCP server security?