Zero Trust Architecture Applied to MCP Agents

MCP just turned into the plumbing that connects AI agents to the tools, databases, and systems that run a company. It grew fast, roughly 35x in tool count over 13 months, and security governance never caught up. That's the whole story here: zero trust architecture already exists inside most enterprises, but it was built to verify people logging in, not agents acting on their behalf. Closing that gap is now the fastest-moving problem in enterprise AI security, and the companies solving it first are the ones who will actually get agentic AI into production.

What zero trust was built to do, and where it stops

NIST laid out the blueprint back in 2020, in SP 800-207: never trust implicitly, verify continuously, and give every transaction the least privilege it needs to get the job done. That's zero trust architecture in a sentence. In practice, it means every user gets authenticated, every device gets checked, every network request gets verified before it goes through.

The model works because it assumes something specific: that whoever, or whatever, is asking for access has a stable, verifiable identity. A person logs in. A laptop gets a certificate. A server has a known role. Zero trust checks all of that at the perimeter, at the moment of connection, and it does that job well.

Here's where it runs out of road. Zero trust was never built for an autonomous agent that takes actions across five different systems in a single session, none of which involve a human clicking "log in." SC Media put the flaw plainly: the architecture verifies the agent's identity, but not what the agent is being told. That's a perimeter model with an AI-shaped hole in it.

None of this means zero trust is broken as a concept. It means enterprises took a framework designed for human logins and pointed it at a new kind of actor, one that reasons, plans, and executes, without extending the underlying principles to match. The gap isn't philosophical. It's operational, and it's already being exploited.

The identity problem MCP inherits by design

MCP, the open standard Anthropic introduced in November 2024 for connecting AI systems to tools and data, has no built-in identity layer. No least-privilege enforcement baked in. No audit trail by default. Authentication is optional in the protocol, and role-based access control isn't part of the spec at all.

The numbers show what that looks like at scale. By early 2026, researchers had found close to 7,000 internet-exposed MCP servers, about half of all known deployments, many running with no authorization controls whatsoever. A separate scan of 2,000 MCP servers found every single one lacking authentication. Only 18% of deployments scope tool permissions at all, and 53% expose credentials as hard-coded values sitting in configuration files, just waiting to be found.

Those agents run production workloads without consistent identity hygiene, a problem that security practitioners have flagged repeatedly as the norm rather than the exception. Controlling and auditing that data access is what MCP governance layers are built around. Cerbos CPO Alex Olivier described the typical MCP API key at KubeCon North America 2025 about as bluntly as it gets: a username without a password. Broad access, no scoping, no expiry, no way to know who's actually behind the request.

Non-human identities routinely accumulate disproportionate access to cloud resources, meaning a single compromised or misconfigured agent identity can carry an enormous blast radius.

There's also a structural inversion at play. Traditional client-server security assumes the client requests and the server responds, cautiously. MCP flips that: servers often query and execute actions on behalf of connected clients, reversing the trust flow. Governance frameworks built around the old direction don't trace attacks that flow the new way. An agent set up under an engineer's personal credentials doesn't get the minimum access a task requires. It gets whatever that engineer already had.

The context-layer attack surface that existing controls cannot see

Call this the context-layer attack surface, because that's what researchers are calling it now. Malicious or manipulated content can flow straight into an agent's reasoning process and trigger actions the agent was never supposed to take, with no model compromise and no stolen credentials required.

That's the part worth sitting with. These attacks don't need a hacked password or a broken model. They exploit something more basic: once a session starts, the agent trusts its context. Tool descriptions, API responses, incoming user prompts, all of it flows into the reasoning window as trusted input, by default, in most deployments today.

MCP adds its own flavor of this problem: tool spoofing, unauthorized invocation, privilege escalation through chaining one tool call into another, data exfiltration hidden inside tool outputs. None of these map cleanly onto the governance frameworks built for older software pipelines.

The incidents from 2025 aren't hypothetical. Invariant Labs demonstrated a malicious MCP server that quietly pulled a user's entire WhatsApp history by hijacking a tool the user already trusted. A poisoned public GitHub issue hijacked an AI assistant into leaking private repository contents, including salary data, straight into a public pull request. And researchers showed that an AI coding agent with privileged database access could be manipulated through attacker-controlled input into exfiltrating data.

OWASP has identified prompt injection as a critical security risk facing large language models. Inside an MCP ecosystem, a successful injection doesn't just produce bad text. It triggers real actions through connected tools. Security researchers and government advisories have made this official: MCP's growth has outpaced its security model, and serialization risks, trust boundary failures, and agent misuse are active, worsening problems.

Specific attacks the threat model has to account for

Tool poisoning, sometimes called a rug pull, works like this: an attacker stands up a legitimate-looking MCP server, gets it approved, then quietly changes what the tool does after the fact. Because most change-control processes don't re-check approved tools, the modified server keeps running with all the trust it earned before the switch. MCP servers can change their tool definitions between sessions, showing different capabilities than what got approved in the first place, and static approval workflows have no way to catch that.

The CVEs back this up with hard numbers. CVE-2025-6514, found by JFrog, scored a 9.6 on the CVSS scale, an OS command-injection flaw letting an attacker get full remote code execution just by having a client connect to an untrusted MCP server. CVE-2025-49596 hit the MCP Inspector tool itself, the thing developers use to test MCP servers while building them, and it lacked authentication between the client and proxy entirely, letting anyone launch commands over stdio. It got fixed in version 0.14.1, but the fact that the testing tool itself was vulnerable says something about how early this ecosystem still is.

Then in April 2026, OX Security found an architectural flaw that allowed arbitrary command execution across an estimated 200,000 vulnerable instances, a supply chain issue serious enough to generate an advisory spanning 10 separate CVEs.

Confused deputy attacks and session hijacking round out the list: attackers exploit MCP proxy servers that connect to third-party APIs, abusing the trust relationships those proxies hold to impersonate legitimate clients. Security researchers have documented two of these patterns in the wild: tool parameter injection, where unsanitized inputs lead to arbitrary command execution, and tool invocation path confusion, where naming collisions let an attacker's tool get loaded instead of the real one.

Worth noting: 62% of newly created MCP servers showed signs of AI-assisted coding in their first-month commits by February 2026, up from just 6% a year earlier. Security hygiene, in other words, is now only as good as the model that wrote the code, and classic issues like broken authorization, excessive data exposure, and injection flaws (the same categories OWASP has flagged in APIs for years) apply fully to MCP's HTTP endpoints too.

What translating zero trust to the MCP layer actually requires

Start with identity. Every agent needs its own identity, issued by a trusted authority, not a shared service account and not a static API key sitting in a config file somewhere. That means short-lived, scoped credentials, using OAuth 2.1 with PKCE, which became mandatory under the November 2025 MCP spec (the S256 code challenge method is required wherever technically possible). But the spec updates from mid-to-late 2025 layered on requirements that go beyond baseline OAuth implementations, so being spec-compliant on paper doesn't close the gap on its own.

Delegation matters just as much as identity. Token exchange under RFC 8693 lets a system issue a token that says, plainly, "Agent X is acting on behalf of User Y," giving that agent just enough access for one specific task instead of standing, broad permissions. Auth0's Token Vault, announced in 2025, is a working example: the agent trades an internal token for a fresh, scoped access token from the third-party provider, and the refresh token never leaves the vault.

OAuth scopes alone don't finish the job, though. A scope like "read:tickets" describes a category of access, not a decision about one specific request. And the token belongs to the agent, not the human standing behind it, so there's no standard field for "this agent is acting for this user, on this request, right now." The OpenID AuthZEN Authorization API, which reached final specification status in January 2026, fills that gap: it defines a standard way to ask a policy engine whether a given subject can take a given action on a given resource, in context, at the moment it matters. The operating principle underneath all of this: prompts never equal permissions. What an agent is asked to do and what it's allowed to do are two separate questions, and only a policy check answers the second one.

Separating reasoning from acting helps too. Keep context assembly and decision-making in one plane, and isolate the actual execution of real-world actions in another. Authorize every tool call per request, not per session, so a green light at the start of a conversation doesn't quietly cover everything that follows. And sanitize what comes in: tool descriptions, API responses, and user inputs all need scanning for injected instructions before they ever reach the model. Security researchers flag unsanitized tool metadata as one of the most common, and most overlooked, exposures in current deployments.

Provenance has to gate action, not just identity. An agent shouldn't take a sensitive action based on context that came from a source nobody's verified. Every proposed action needs its own check: does the source of the information driving this decision meet the bar this particular action requires? And those thresholds, what runs automatically, what needs a human to sign off, what gets blocked outright, need to be set by administrators ahead of time. Not decided by the agent, in the moment, on the fly.

Last piece: treat every MCP server connection like a privileged access pathway, because that's what it is. Inventory them all. Classify each one by what data and actions it touches. Manage the lifecycle of every token issued, scope them tightly, and log every action immutably. Build in triggers that force re-validation whenever a tool's definition changes after deployment, since that's exactly the gap the rug pull attack depends on.

How the enforcement layer fits into existing enterprise architecture

The pattern showing up across vendors right now is the gateway model: a broker sitting between agents and enterprise systems, checking identity, context, and policy on every single step before letting it run. Instead of one trust decision at the start of a session, every agent action becomes its own transaction, verified on its own terms.

Versa's Zero Trust MCP architecture, announced May 21, 2026 and built into Versa Verbo, integrated with the VersaONE Universal SASE Platform, is one concrete version of this: identity checks, role checks, policy checks, plus administrator-defined human approvals, with every approved action logged and attributed. It's a signal that enforcement and audit trails are becoming things vendors build and sell, not things enterprises are expected to duct-tape together.

Other tools take a similar approach: a governed gateway layer designed to make accountable MCP adoption faster than the ungoverned alternative. The goal is straightforward, make governed adoption faster than the ungoverned kind, so security stops being the thing that slows teams down.

Cerbos, per Alex Olivier's talk at KubeCon North America 2025, works the problem from a different angle: an embedded policy decision point, evaluating fine-grained authorization on every request, wired directly into the agent's tool-invocation path instead of bolted on at the edge.

Anyone picking or building one of these systems should be asking a specific set of questions. Does it plug into the identity providers and policy engines already running in the stack? Can it tell the difference between reading a record and deleting one? Do the human-approval steps scale, or do they choke the system the moment agent activity gets busy? Is the audit log tamper-evident and readable in real time, because a log someone reads after an incident is a postmortem, not a safety net. And what happens when one agent calls another agent, does the original user's identity survive that hop? Most implementations still don't have a good answer for that last one.

Gartner summed up the underlying shift well in materials tied to Versa's announcement: AI introduced a new, high-volume class of digital user, agents, that traditional SSE and SASE platforms were never built to secure. That's an architecture problem, not a settings problem.

Why the organizations that govern MCP now will ship agentic AI faster

Gartner expects task-specific AI agents inside 40% of enterprise applications by the end of 2026, up from under 5% in 2025. That's not a gradual curve, it's a cliff, and the enterprises without an identity and policy layer for their agents are going to hit it without a way to slow down.

Governance, in this context, isn't a brake. It's a runway. An enterprise that's already inventoried its MCP servers, scoped its tokens, and wired policy checks into every tool call doesn't have to stop and rebuild trust from scratch every time it wants to plug in a new agent or a new capability. It already has the rails laid down.

The enterprises still running agents on shared service accounts and static API keys face a different math problem. Every new agent, every new MCP server, every new integration adds risk that compounds, because nobody's tracking who has access to what, or why. At some point that catches up, whether through an incident, an audit, or a breach that makes the decision for them.

Zero trust got built for a world of humans logging into systems. MCP built a world where agents log into other agents, chain tool calls together, and take actions with no person watching the screen in real time. Bridging those two worlds isn't optional anymore, and it isn't finished. But the organizations doing that work now, treating every agent as a governed identity and every action as a checked transaction, are the ones who'll be ready when agentic AI stops being a pilot project and starts being the default.