Podcast: Zero Trust Breaks Against MCP: Why “Verified” No Longer Means Safe

Tova Dvorin (00:01.534) There is a new NSA advisory that landed in may twenty twenty six, and it is, frankly, one of the more significant things the agency has published on AI infrastructure. NSA Cybersecurity Information Sheet U0 six three three one six two six The Model Context Protocol Security Design Considerations for AI driven automation. Adrian, before we get into the specifics, what is MCP and why is the NSA weighing in right now? Adrian (00:26.656) MCP, Model Context Protocol. It’s the de facto standard for connecting AI agents to the tools and services they use. It was originally popularized by Anthropic in November 2024 and it has spread globally remarkably fast. AutoGen Studio, Harvey AI, Copilot, Agent Verse, they all use it. The reason NSA is weighing in now is that MCP has gone from experimental. to production deployments across finance, legal, healthcare and software development faster than its security model has matured. That’s the pattern that tends to precede serious incidents. Tova Dvorin (01:08.968) Welcome to the Cyber Resilience Brief, a Safe Reach podcast. And this is our episode on why Zero Trust Doesn’t Cut It in the Wonderful Zany World of MCPs in 2026. Adrian, this advisory is framed around security design considerations, which suggest real design gaps, not just misconfiguration. What is the core problem that the NSA is identifying here? Adrian (01:29.56) So MCP was released with a flexible, under specified design. The advisory draws the comparison to early web protocols. HTTP came out without what we now consider table states for security, and the ecosystem had to bolt on security afterwards. MCP is at that same phase, but there’s an additional structural wrinkle. MCP inverts the familiar request pattern. Instead of clients requesting data from servers, MCP often has servers querying and executing actions on behalf of connected clients. That inversion creates attack paths that aren’t well mapped yet. And the advisory is explicit. The theoretical risks are now actually concrete. Researchers have released vulnerable MCP server implementations demonstrating real exploits. These aren’t hypothetical. Tova Dvorin (02:21.044) That is an interesting inversion. You know, walk me through, walk us through what it means practically for a security team trying to reason about exposure. Adrian (02:29.453) So in a classical web interaction, the client asks, the server responds, and the scope is relatively clear. With MCP, your AI agent is the client, but the MCP server is doing things on its behalf. It’s calling tools, it’s retrieving data, it’s executing tasks. And because those servers can be third party implementations that evolve over time, you’ve introduced a degree of autonomous action into your infrastructure that your traditional access control models weren’t designed to contain. An agent that can call twenty different tools across your environment has a blast radius your IAM policy never modelled. Tova Dvorin (03:10.43) So let’s get into the more specific security gaps. The advisory identifies several categories. What’s the most fundamental problem within these? Adrian (03:19.511) So we just mentioned their blast speakers unlinked. Bose speakers unlinked. I hope they didn’t pick one up. I’ll start again. We just mentioned their Tova blast radius for model context protocol and AI. People are used to discussing blast radius for attacks. This is a subset of those attacks, and many people have yet to even contemplate, never mind consider the blast radius for compromise of any of their AI systems. Access control or the absence of it is the heart of this. The advisory is unusually direct. Associating a session to an identity is not defined by the protocol. It is optional at the implementer’s discretion. MCP components, client service, proxies hosts, can be configured to access or process data without any required access control measures. Many implementations omit authentication entirely. Those that do include it often lack role-based enforcement. No crud permission separation, no R back inst instantiation. this is the foundational gap because without identity at the protocol there, everything you want to build on top of it with zero trust has no native hook to anchor to. Tova Dvorin (04:31.867) And zero trust is exactly the framework most enterprises are currently running towards. US federal agencies have an adoption deadline of twenty twenty seven on that end, so there’s a direct collision course happening here. Adrian (04:42.914) That’s the tension that the advisory surfaces Toba, even if it doesn’t quite name it that way. Zero trust, as codified in this special project 800-207, has three pillars. Verify explicitly, assume breach, least privilege. The first pillar presupposes a policy enforcement point at the protocol layer that you can interrogate per request. MCP doesn’t give you that natively. You can build one externally, identity aware proxy, DLP layer, mutual TLS, and the advisory effectively tells you to, but the protocol itself provides no native primitive for request level verification the way that zero trust presupposes. Tova Dvorin (05:28.275) So the enterprise CISO who believes their zero trust architecture covers their MCP deployment is mistaken and possibly very no, sorry. Covers their MCP deployment, they’re mistaken. Adrian (05:39.769) For MCP, yes, and in two specific ways that go beyond the authentication gap tover. The first is what I’d call trust decay. Classical Zero Trust continuously evaluates identity, device posture, and network signal. What it does not continuously evaluate is whether the semantics of a tool description have changed. The advisory flags this explicitly. An approved MCP server can silently update its tool description, and there are attacks out there doing this right now. After it has been vetted. The document’s exact language is that a previously benign and approved AI service could later access sensitive resources on demand without triggering any review. That is a class of trust decay zero trust was not architected to detect. Tova Dvorin (06:28.797) The server is approved, the credentials are valid, but the thing you approved is no longer the thing that’s actually running. Adrian (06:34.7) You sound like Dr. Seuss Tova. This this one of these things is not like the other thing. and that’s correct. That leads to the third gap, which is the most significant form of of an attacker’s perspective from an attacker’s perspective. Verified is not the same as benign. Zero trusts verification primitives, authentication, signatures, certificate pinning, tell you a message is from who it claims and has not been tampered with in transit. Tova Dvorin (06:37.299) we get it. Adrian (07:02.316) They cannot tell you whether the content of a correctly signed tool, output, is a prompt injection payload, a poison descriptor, or an indirect instruction to a downstream agent. The attacks in this advisory nearly all plus classical zero trust checks. The malicious actor does not subvert identity, it subverts meaning. Tova Dvorin (07:24.967) The advisory gives real world case studies too. Walk me through the ones that are the most operationally significant. Adrian (07:31.193) So three standout TOVA. First, the WhatsApp MCP exploit. Research has demonstrated that a malicious MCP server, introduced into an environment that also had a legitimate WhatsApp MCP integration could coerce the MCP client into exposing WhatsApp message history without user notice or approval. The technique worked because the malicious server’s tool descriptions manipulated the client’s behaviour. And critically, The malicious server advertised a benign instruction at installation, then switched it to a malicious instruction on its second usage, a rug pull in MCP terms. The approval was real, the thing you approved was not. Tova Dvorin (08:13.427) It’s the ultimate bait and switch in a way, you know, the trust is granted installation and then the behavior changes silently when you’re not looking. That’s the trust decay problem made concrete. Adrian (08:22.378) Exactly. The second real example was the GitHub MCP server implementation. It granted blanket access across all repositories, public and private, rather than the narrowly scoped permissions tied to specific repos or operations. Malicious or compromised hosts could read sensitive content from private repositories and write it into public ones without the user’s explicit awareness or intent. This is the least agency problem. OWASP coined that term, something we’re releasing soon as well. It extends least privilege to agentic systems. Not just what can this identity access, but what can this specific tool do, how often and where. The GitHub implementation had none of that scoping. Tova Dvorin (09:10.707) And then of course there’s the remote code execution vulnerability, CVE twenty twenty-five forty-nine fifty-nine six. Adrian (09:17.302) CVE 2025 49596 just flows off the tongue. You delivered it beautifully, that’s over. Was disclosed in MCP Inspector, a product used to test MCP servers during development. The inspector accepted unverified inputs allowing a malicious actor to trigger remote code execution via crafted messages. Fixed in version 0.14.1, it falls under CWU. CWE, sorry, Common Weakness 94, code injection. One of the four CWE categories that advisory specifically calls out as relevant to MCP environments where user-provided logic reaches execution. The lesson is that the tool chain around MCP is exposed as the protocol itself. Your development and testing infrastructure is part of the attack surface. Tova Dvorin (10:11.473) And then there is the output poisoning chain, which feels like the most systemic risk of anything in the advisory. Adrian (10:17.536) It it’s the one that has the widest blast radius. The advisory describes how MCP agents can produce outputs that, if trusted by downstream agents or systems, are misinterpreted as executable prompts rather than passive content. In a multi agent workflow where one’s agent output becomes the next agent’s input, a single poisoned output can cascade across the entire pipeline. Unauthorized behaviour, data exfiltration, control flow hijacking across chained MCP processes. The research on what has been called toxic flows in agentic systems describes this as systemic and not isolated. Every one of these attacks passes classical zero trust checks. The messages arrive from valid sources correctly signed on expected channels. The malicious actor does not subvert identity, it subverts meaning. Tova Dvorin (11:13.395) So let me see if I can pick up what you’re putting down here. We have a protocol that is already in production at scale with gaps that classical zero trust cannot address. That sounds like a one-legged man in a soccer kicking contest when it comes to CISOs and defenders. So what does a defensible posture actually look like in this crazy game? Adrian (11:29.944) So the advisory’s recommendations group into four practical areas. First, design for boundaries, align tools with data classification zones. Publicly available tools handle public data sets, and tools that interact with sensitive or regulated data are explicitly controlled and segregated. Data originating from a user facing plugin should not be blindly accepted by a privileged back end model. Dynamic tool discovery, one of MCP’s headline features, should be treated with caution unless coupled with an origin verification. Second, validate and constrain. Every tool invocation gets parameter validation against a well-defined schema, checking for malformed inputs, missing fields and excessive sizes. Sandbox each tool’s execution content using SecComp, App Armour, SC Linux or App Containers on Windows. Treat every tool execution triggered via MCP as a potentially high risk auction. Tova Dvorin (12:30.195) Adrian, the advisory also has specific guidance on message signing. You know, that was something I hadn’t seen in most MCP discussions before this. Adrian (12:38.434) right, Tova, and its table states that MCP is not required. The protocol currently relies on transport layer encryption, TLS. The protocol itself cannot enforce or verify encryption and is unaware of message integrity beyond the transport. The advisory recommends extending the standard with cryptographic signatures directly within the JSON payload, binding requests to time and context, time-bound signatures. Expiration time stamps, replay protection metadata. This is OSP ASVS V7 session management applied to an AI protocol there. The guidance exists, MCP’s implomators just haven’t been required to follow it. Third area, instrument everything. All tool invocations logged, including exact parameters, identities involved, cryptographic hashes of results, integrated into your seam. Anomalous message flows tagged in real time. Tova Dvorin (13:35.495) There’s a fourth area here as well. You know, you mentioned scanning the local network for shadow MCP. Adrian (13:40.953) This one tends to get overlooked and it shouldn’t. The advisory explicitly recommends The organisations regularly scan their networks for insecure or unauthorised MCP servers. It names specific tools, MCP scanner, ramparts, cyber MCP, and proximity. Four things you’re looking for: unauthenticated MCP servers accessible without login, vulnerable deployments with known security flaws, unauthorised MCP deployments running outside approved change control, and unregulated internet connectivity. A very important detail. MCP servers may dynamically change ports, which means a one-time static scan is insufficient. The advisory calls for periodic scans with differential reports. If your scan ran six months ago and you haven’t run it since, that’s not a scan, it’s a snapshot, and snapshots don’t protect you from the protocol that keeps moving. Tova Dvorin (14:36.413) There’s a concept emerging from the analysis of this advisory, zero standing trust. What is that and why does it matter more than just saying do zero trust properly? Adrian (14:46.456) So zero standing trust, you heard it here first, is the honest evolution of zero trust for the authentic for the zero standing trust, you heard it here first, is the honest evolution of zero trust for the agentic world. Classical zero trust as deployed in most enterprises collapses in practice into network segmentation plus single sign-on plus a quarterly access review. That was never what NIST Special Project 800-207 intended. The specification calls for continuous verification at every request. Our friend continuous again. Zero standing trust extends that to say no permission, no identity binding, no tool descriptor, no context window is durably trusted. Everything is re-verified per request, per hop, and per semantic change. The word standing is the key. Standing trust is trust that persists beyond the moment it was granted. In MCP environments, that persistence is where the attacks live. Tova Dvorin (15:50.547) Her semantic change, that’s genuinely new. Not just reverifying identity, but reverifying whether what you approved is still what is actually running. Adrian (15:59.117) That’s the critical extension, Tova, and it’s why the Anthropic Zero Trust for AI Agents Framework, which was published alongside this advisory landscape, is worth the CISO’s time. It structures controls across three tiers: Foundation, Enterprise, Advanced, and it is explicit that the foundation floor has been raised in response to AI accelerated offence. Short-lived tokens. Cryptographically rooted identity, identity-based isolation, automated first-pass alert triage. These are now entry requirements, not aspirational targets. The framework also introduces what it calls the impossible versus tedious test for any control. Does this make the attack impossible or just tedious? Important differentiation: Agentic attackers have unlimited patience and near zero per attempt cost. If your containment relies on friction, you should assume it will fail against a determined adversary. Tova Dvorin (16:58.449) Now apply that test to the current MCP posture at most organizations. Adrian (17:03.596) So, authentication is optional, that’s not tedious, that’s just absent. Tool descriptions can change silently after approval. That’s not tedious, that’s just undetected. Token lifecycle management is unspecified, bearer tokens without rotation policies, without eigenpotency enforcement. These are not friction problems, these are architectural gaps. The anthropic framework is clear that static APA keys and share the service account passwords are no longer a legitimate foundation pop posture. They are among the first things an attacker with model assisted code analysis will find and should be treated as already compromised. Tova Dvorin (17:42.183) Now for the CESA listening, what are the three concrete actions that you’d recommend they take this quarter? Adrian (17:47.705) First, inventory. Do you know how many MCP servers are running in your environment right now? Most organisations don’t. Run the network scan, use the tools of the advisory names, and apply the most stringent code review profile to any MCP server project you identify, especially newer integrations. Second, mandate authentication. Authorisation in MCP is optional by specification, but it does not have to be optional in your deployment. Any MCP server handling sensitive or regulated data gets identity aware proxy enforcement, mutual TLS and RBAC before it stays in production. Third, instrument. Every tool invocation logged with parameters and identity. Integrated into your seam. Correlated against behavioral baselines. If you cannot identify an anomalous tool call within an hour of it occurring, your dwell time is too long for this threat surface. Tova Dvorin (18:47.901) And on the validation side, how do teams confirm their controls are actually working, not just deployed? Adrian (18:53.474) This is where the advisory is read carefully, essentially an adversarial exposure validation brief. Even though it doesn’t use that language. Every concern it raises is empirically testable. Tool poisoning. Does your detection fire when a tool description silently changes scope after approval? Cross-server message bleed. Can context from one server contaminate another? Parameter injection at the JSON RPC layer. Does your validation hold under a crafted malformed input? Indirect prompt injection from a trusted upstream agent into a privileged downstream one. These are not theoretical, they’re test cases. You cannot prove a defensible posture by inspecting policy, because that protocol does not carry enough policy to inspect. You have to prove it by exercising the attack chains. The defenders I’ve seen handle this well are running continuous validation against these technique chains, not quarterly, continuously. Safe Breach customers use that continuous validation loop to close exactly this class of gap. But the principle holds regardless of platform. If you’ve not exercised your MCP tool poisoning detection, you do not know whether it works. Tova Dvorin (20:11.399) And what are you watching for the next six months on this topic? What do you predict? Adrian (20:15.406) Two things. First, I’m watching for the first publicly attributed breach that traces back to MCP exploitation. The tooling is documented, the vulnerable implementations are in the wild, the advisory landed in May 26. When a confirmed exfiltration event is attributed to tool poisoning or a rug pull attack in production AI deployment, this moves from a practitioner conversation to a board conversation overnight. Organisations should be ahead of that moment, not reactive to it. We’ve all got clear notice this is coming. Second, I’m watching the specification itself. The advisory is explicit. MCP’s security posture depends entirely on implementation discipline rather than protocol guarantees. Oasis KOSI, the MCP maintainers, the standards community needs to close the gap. When protocol mandates authentication rather than recommending it, The security floor rises for every implementer simultaneously. Until then, each deployment is only secure as the individual team that built it. Tova Dvorin (21:19.205) It’s the perennial problem, Adrian. Security is optional rather than the default, and waiting for an incident to make it mandatory. The brief for this week is that the advisory is NSA CSI U slash O slash six three three one six two six May twenty twenty six. Read it alongside the Anthropic Zero Trust Ray Agents White Paper. Inventory your MCP estate, mandate authentication on sensitive deployments, instrumental entry into your SIM, and validate the controls actually fire. That’s the work. Thanks, Adrian. Adrian (21:49.826) This is the way. One final thing before we go, and this matters for the network teams. MCP servers may dynamically change ports between scans. A differential scanning approach, comparing current state against the previous baseline, we refer to it as tracking the drift at Safe Breach, is what gives you visibility into new or modified services. That is explicitly what the advisory recommends, and it is more operationally useful than a point in time inventory. Stay adversarial. Tova Dvorin (22:20.628) Stay adversarial. But until next time, stay safe. Stay safe with Safe Breach.