Zero Trust vs Least Privilege in MCP Environments
There is a version of this conversation I have watched play out dozens of times in enterprise security reviews. Someone on the …
There is a version of this conversation I have watched play out dozens of times in enterprise security reviews. Someone on the architecture side points to their Zero Trust implementation, cites the continuous verification model, and treats the MCP question as already answered. Someone else on the compliance side points to their least-privilege policies, notes that access is scoped, and arrives at the same conclusion. Neither is wrong about what they have. Both are wrong about what it covers.
Anthropic introduced MCP in November 2024 as an open standard for connecting AI agents to external tools, databases, and applications. The adoption curve was steep enough to surprise even optimistic projections: OpenAI added support by March 2025, and by early 2026, over 10,000 MCP servers had been published and integrated into ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code. Anthropic's December 2025 ecosystem update confirmed over 97 million monthly SDK downloads across Python and TypeScript. That is not an experimental protocol. That is infrastructure.
What MCP actually enables is worth naming precisely, because the security implications follow directly from it. Agents using MCP do not just query. They invoke, chain, and act. Each tool call is a potential write or exfiltration event, not just a read. An agent connected to a file system tool, a database tool, and an email tool can, in a single pipeline run, read a record, modify it, and send its contents somewhere. The Cloud Security Alliance noted in May 2026 that AI agents are now privileged identities sitting between traditional user accounts and service accounts, executing on behalf of humans with access that often exceeds what the human themselves holds. That last clause deserves a second read, because it is the operational reality that makes the security question urgent.
What Zero Trust and Least Privilege each actually do, and where one ends and the other begins
Zero Trust is an access decision model built on continuous verification. It evaluates every request against context: identity signals, device state, network location, session behavior. The key word is "continuous." Zero Trust does not assume that because you authenticated at the door, you are trusted throughout the building. It asks the question again at every threshold. What it does not do, by itself, is define how much access should exist once a request is approved. That is a different question, and it belongs to a different framework.
Least Privilege, or the Principle of Least Privilege, is a policy discipline that constrains the size of what any given access grant covers. NIST's formulation is clean: every entity receives only the minimum system resources and authorizations required for its legitimate function. The principle applies to users, applications, automated processes, scripts, and system services. It is not a human-only concept, which matters enormously in an agentic context. Where Zero Trust governs whether a request is permitted at a given moment, Least Privilege governs the blast radius if that decision turns out to be wrong.
The relationship between them is asymmetric, and getting the direction right changes how you think about gaps. Zero Trust depends on Least Privilege. Least Privilege does not depend on Zero Trust. Without Least Privilege, a Zero Trust architecture can authenticate a request with perfect fidelity and still authorize catastrophic access, because authentication says nothing about scope. Many security programs overinvest in verification checkpoints and underinvest in access minimization. The dependency flows one way.
Carry this distinction forward: Zero Trust controls who can enter and when. Least Privilege controls how far they can go once inside. Those are not redundant functions. They are sequential ones, and both have to be present for either to be complete.
What MCP ships without by default, and why that gap exists
The NSA's framing, from their Cybersecurity Information Sheet published May 20, 2026, is worth quoting at the front of this section because it establishes the structural context: "MCP's rapid proliferation has outpaced the development of its security model. Much like early web protocols, MCP was released with a flexible and underspecified design, allowing implementers freedom of design but also introducing ambiguity for safe usage."
That parallel to early web protocols is not rhetorical. It is diagnostic. MCP ships without built-in identity management, without Least Privilege enforcement, and without an audit trail. SC Media's 2026 identity security analysis confirmed this. On authentication specifically, only a small fraction of public MCP servers use OAuth by default; independent scans have established this is the exception, not the norm. On logging, the MCP specification includes basic guidance but leaves implementors to define comprehensive audit requirements, and many implementations omit logging entirely or record only minimal operational data.
The gap exists because the protocol was designed for flexibility and rapid adoption. Security was left to implementors. That is the same design philosophy that produced the early web's vulnerability surface, and it produces a similar result here: a protocol that scales before its security model does.
What this means in practice is not theoretical. An organization can have a mature Zero Trust program and a well-enforced Least Privilege policy and still deploy MCP servers that bypass both, because neither framework was applied at the protocol layer. The perimeter exists. The MCP stack runs through a gap in it.
The two distinct attack surfaces MCP creates, and why each one defeats a different framework
It helps to be specific here, because the two surfaces are genuinely different in character, not just in degree.
The first is the connection layer. This is the surface Zero Trust is designed to govern, but currently often misses in MCP deployments. MCP sessions are frequently long-lived, shared across multiple tool invocations in a single pipeline run, and carry access tokens for downstream systems. The Cloud Security Alliance noted in May 2026 that this makes the session hijacking surface broader than in traditional web applications. Beyond hijacking, supply chain entry is a persistent threat: weak registry vetting allows adversarial or hijacked servers to enter host environments. Research formalized in arXiv:2510.16558 by Li and Gao, submitted in October 2025 and revised in April 2026, describes the attack surface operating at two distinct stages, the registry and the host. There is also the "rug pull" attack, first formally described by Invariant Labs: a server behaves legitimately at installation, then silently changes its behavior after permissions are granted, requiring no user error and no network-level exploit. Four named CVEs appeared in the MCP layer in 2025 alone. CVE-2025-6514, disclosed by JFrog, was an OS command injection vulnerability in mcp-remote enabling full remote code execution, assigned a CVSS score of 9.6. CVE-2025-49596, CVE-2025-54136, and CVE-2025-54994 followed.
The second surface is the context layer. This is where Least Privilege operates, and where Zero Trust is structurally blind. Tool poisoning involves malicious instructions embedded inside a tool's description: text the agent reads and acts on, invisible to the human who approved the server. Invariant Labs disclosed this on April 6, 2025. It is not a model bug. It is a software supply chain problem, and any connected server can ship a poisoned description. MintMCP's 2026 analysis flagged roughly 5.5% of public servers as tool-poisoning-vulnerable. Because MCP supports tool chaining, a small injection at the start of a pipeline can trigger multi-step actions across systems, and the blast radius expands with every chained invocation.
The real-world demonstrations are not hypothetical. Invariant Labs showed a malicious MCP server silently exfiltrating a user's entire WhatsApp history. A Supabase Cursor agent was manipulated through attacker-controlled support tickets into executing SQL exfiltration commands. A public GitHub issue hijacked an AI assistant into leaking private repository contents, including salary data. Postmark's official MCP server, from a trusted and named source, was found to be silently BCC'ing every sent email to the maintainer's address.
The structural point is this: Zero Trust checks whether the agent should connect. It cannot evaluate whether the instructions arriving through the tool response are legitimate. That gap is exactly where Least Privilege, and content validation, must operate. The two surfaces require two different frameworks, not because the frameworks are philosophically distinct, but because the attack vectors are mechanically distinct.
Why a mature Zero Trust program still leaves the context layer exposed
SC Media named this directly in March 2026: Zero Trust architecture verifies the agent's identity but not what the agent is being told. Every tool description, API response, and prompt that enters the context window is implicitly trusted once it passes perimeter controls. Their formulation: "That is not zero-trust. That is a perimeter model with an AI-shaped hole in it."
That is pointed language, and it is accurate. The issue is structural. Zero Trust, as currently implemented in most enterprise environments, was designed for a world where the thing being verified is an identity making a request. In an agentic system, the identity is making a request, but it is also receiving instructions through the response channel, and those instructions can modify its behavior in ways that no authentication check will catch.
Non-deterministic behavior compounds this considerably. Agents interpret prior context probabilistically. A malicious actor who preconditions an agent across earlier turns, building up a pattern of instructions that biases its probability distributions toward unsafe outcomes, can drive it toward a harmful action without triggering any authentication event. The NSA flags this explicitly in their May 2026 guidance, noting that these non-deterministic behavior issues are outside the scope of traditional information security practices and require new approaches. That is a significant statement from an agency not given to overstating threats.
There is also a structural problem with static RBAC in agentic contexts. Once permissions are assigned, they remain until manually updated. Changes in system scale or business logic require creating additional roles to maintain the intended relationships, and that overhead breaks down in agentic systems where context changes per task, sometimes per invocation. Zero Trust programs that rely on static role assignments for their access decisions inherit this brittleness.
What this implies is that a Zero Trust program that has not been extended to treat each agent and each MCP server as a first-class identity, with per-call authorization rather than per-session, leaves the inner layer of the MCP stack ungoverned. Organizations with mature Zero Trust architectures have a real head start in terms of mental model and tooling. But the extension required is not trivial. Each agent and each MCP server must be treated as an identity in its own right, not as a client acting on behalf of a human identity that already passed verification.
How Zero Trust and Least Privilege divide the MCP security problem between them
The division is cleaner than it might initially appear, once you accept that the two frameworks govern different axes of the same problem.
Zero Trust's domain in MCP is governing whether an agent is ever permitted to connect, and continuously re-evaluating that decision. That means authenticating every client-server connection with no implicit trust based on network location. It means treating each agent as a first-class identity: issuing it credentials through SPIFFE, OAuth client credentials, or an equivalent mechanism, with no shared admin tokens and no static API keys. Cerbos, writing in January 2026, described the appropriate pattern for agents acting on user data: delegation tokens and on-behalf-of flows, where the agent never holds long-lived user credentials but instead requests narrowly scoped access tokens when needed. Critically, authorization should be re-evaluated per call, not per session. MCP's long-lived sessions make per-session grants particularly dangerous, because a session that was legitimate at initialization may be operating under compromised instructions ten tool calls later. Registry governance also falls here: every MCP server should have a registry entry before agents are permitted to connect, because an ungoverned server is an unaccountable identity.
Least Privilege's domain in MCP is governing how much an authenticated agent can touch, and keeping that surface as small as the task allows. Not every agent needs every tool. Enforcing tool-level Least Privilege means scoping each agent's MCP access to the specific tools its task requires, and scoping credentials to specific tools and data rather than to the server as a whole. The governing question is a blast radius question: if this agent's session is hijacked, or its context poisoned, what is the maximum damage? Least Privilege is the mechanism for keeping the answer to that question bounded. And Least Privilege applies to the content layer too, not only to the access layer: what flows into the agent's context window needs validation, not just what identity connected.
The dependency runs in one direction, and it is worth making explicit again: Zero Trust cannot limit blast radius. It can only gate access. Least Privilege cannot govern whether access should be granted. It can only constrain what happens after. Enterprises that choose one over the other leave the other's gap entirely unaddressed.
A principle worth naming: agentic AI adds a new axis to the access control problem. It is not just who is accessing what. It is what instructions are arriving through the access channel. Security architecture that does not cover both axes is not covering the problem.
What authoritative bodies now require, and the compliance pressure behind these controls
The NSA published "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation" on May 20, 2026. It identifies uncontrolled automated actions and lack of input screening as primary risks, and it requires that all MCP tool actions be logged in detail: what tool was requested, by whom, and what resulted. That logging requirement is not aspirational; it is a minimum, and it is intended to integrate into existing security monitoring infrastructure.
OWASP published its MCP Top 10 in mid-2025, and it is now the canonical reference for MCP security review. The threat categories it formalizes map directly onto the two-framework gap: tool poisoning, schema poisoning, tool shadowing, command injection through unsanitized agent input, shadow MCP servers deployed outside governance, and context over-sharing across shared agent sessions. These are not novel threat categories invented for AI. They are known attack patterns adapted to a new surface.
The EU AI Act's high-risk obligations became enforceable on August 2, 2026. MCP gateways used on regulated data are inside scope. The tool-calling layer is not excluded.
Compliance implications are already concrete. Tool poisoning enables data exfiltration through legitimate tool channels, which creates reportable breach scenarios under GDPR, SOC 2, and HIPAA. The confused deputy problem, where an agent acting on behalf of one user is manipulated into accessing another user's data, creates multi-tenant breach scenarios with direct implications under the same frameworks.
The broader signal is convergence. Governance frameworks are arriving at the same two requirements from different directions: verify identity continuously, and constrain access to what is necessary. Treating MCP deployments as exempt from either is no longer a defensible posture, and it is becoming less defensible with each compliance cycle.
The operational gaps that appear when organizations implement one framework without the other
Three gaps appear with regularity, and each one has a characteristic failure mode.
The first is Zero Trust without Least Privilege. The agent's identity is continuously verified, but once verified, it holds broad tool access across the MCP server. A context-layer attack that passes authentication controls can now invoke any tool the agent holds access to. The rug pull attack is the clearest illustration: Zero Trust verified the connection at installation; the server changed its behavior afterward; no Least Privilege constraint limits what the now-malicious tool can do. Effective blast radius: unlimited within the agent's credential scope.
The second is Least Privilege without Zero Trust. Access is scoped correctly, but the identity presenting those credentials is not continuously evaluated. Session hijacking exploits this directly. Long-lived MCP sessions carrying narrow but real access tokens become valuable targets; once hijacked, the attacker operates within the Least Privilege scope, but there is no ongoing identity check to interrupt the session. Supply chain attacks at the registry level exploit the same gap: a hijacked server that passed initial vetting presents its credentials normally while its behavior has already changed.
The third gap is more commonly overlooked: neither framework extended to the audit layer. Organizations that apply both frameworks to connection and access often treat logging as operational rather than security-critical. The NSA's logging requirement is a minimum, not a ceiling. Real-time visibility into what an agent touched, which tools it invoked, what data it accessed or modified, is what distinguishes a functional safety net from a postmortem capability. Gartner projects that over 40% of agentic AI projects will be cancelled by end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. The audit gap is a direct contributor to the "inadequate risk controls" category, because without it, there is no mechanism for detecting that a control failed before the damage is done.
What implementing both frameworks together looks like in a working MCP deployment
Start with agent identity. Before any MCP server connects to anything, every agent and every server needs a provisioned identity: a credential, a scope, a registry entry. No shared tokens. No ambient credentials inherited from the service account running the host. If the agent does not have a discrete, verifiable identity, neither framework has anything to operate against.
From there, the connection layer gets Zero Trust treatment at the per-call level. Each tool invocation is an authorization event, not just the initial session establishment. This is more granular than most existing Zero Trust implementations, which tend to operate at the session or request level rather than the individual tool call level. The tooling exists to do this, particularly with OAuth client credentials flows and delegation tokens, but it requires deliberate configuration rather than default behavior.
Least Privilege then operates at two levels simultaneously. At the tool level, each agent's MCP access is scoped to the tools its specific task requires, nothing broader. At the data level, credentials are scoped to the specific data the tool needs to access, not to the server or the database as a whole. The governing question at both levels is the blast radius question: what is the worst credible outcome if this specific agent's session is compromised at this specific point in the pipeline?
Content validation covers the axis that neither framework addresses natively. Tool descriptions, API responses, and any text entering the agent's context window should be treated as potentially adversarial input and screened accordingly. This is not a solved problem in the way that OAuth is a solved problem, but it is a defined problem with tractable approaches: schema validation, output filtering, sandboxed execution environments for tool responses.
Logging closes the loop. Every tool call, every agent identity, every result. Not as an operational record but as a security artifact, integrated into the same SIEM infrastructure that handles the rest of the environment's event data. Without this, the other controls are present but unauditable, which is a different kind of gap: not a gap in prevention, but a gap in detection and response.
None of this requires abandoning what mature programs have already built. The Zero Trust architecture that governs user and service account access provides the mental model and much of the tooling. The Least Privilege policies that govern application permissions provide the policy framework. What MCP requires is extending both, deliberately, to a new class of identity that did not exist in the environment two years ago, and accepting that the extension is not automatic. The protocol does not do it for you. The frameworks do not apply themselves. The question is whether the extension happens before an incident or after one.
