Podcast: Blind With Scissors: The NSA’s MCP Warning for Every Agentic AI Deployment

Tova Dvorin (00:02.09) Welcome back to the Cyber Resilience Brief, a Safe Breach podcast. I’m Tova Dvorin, your host, and I’m joined as ever by Resident Defensive Cybersecurity expert Adrian Culley. Adrian, the NSA dropped a cybersecurity information sheet last week in May 2026, squarely aimed at something most CISOs are still pretending isn’t on their network, the Model Context Protocol, or MCP. This is the plumbing of every agentic AI deployment shipped in the last 18 months. Adrian Culley (00:28.29) And the NSA is in character, characteristically dry language telling enterprises that the protocol security model has not kept up with the protocols adoption. The advisory compares MCP to early web protocols, flexible, underspecified in production before the threat model caught up. The NSA doesn’t usually publish on emerging integration protocols. When they do, it’s because the protocol has crossed a line from interesting ubiquitous to load bearing in industry. Tova Dvorin (01:02.346) Let’s set up the scene a little more here, and let’s backtrack a little bit for listeners who are not as familiar with MCPs. What exactly is an MCP? What does it do, and why does it matter for cybersecurity? Adrian Culley (01:14.606) So model context protocol, MCP, each word is important, but it’s an application layer protocol, open-sourced by Anthropic in November 2024. It lets an AI system talk to tools and data sources in a standardized way. Think of it as a USB connector for artificial intelligence. And remember the world before we had USB connectors when your Apple mouse wouldn’t work with your Windows. PC. MCP lets everything in AI talk to everything else. When you ask Claw.co.pilot to check your calendar, query its database, post to Slack, it’s MCP underneath. The Connective Tissue of Agentic AI. Tova Dvorin (02:01.078) So it’s essentially the brain, it’s the neural network, but giving it access to everything can present some security challenges. Adrian Culley (02:08.279) The design pattern is inverted from what most architects are used to. In a normal client server world, the client requests the server responds. MCP often has servers querying and executing on behalf of clients. And also important note, neither the client or the server needs to be physical. They can be, but they can also be entirely logical, which also means you can have multiple layers of MCP client and MCP server within a logical instance. The NSA flags this inversion explicitly. They say it creates very important new and largely not well traced attack paths. The NSA’s words. Tova Dvorin (02:51.19) So the USB C for AI framing, which Rs technically used in which the NSA sites, fits in and makes sense too. Once you have a universal connector, you have a universal attack surface, and it might be one where you can’t see where the tunnels are going. Adrian Culley (03:04.457) Exactly that Tova. Autogen Studio, Harvey AI, is in the legal sector, a Gentiverse, Microsoft Copilot. The advisory names all of those. Running production workloads through MCP servers, often built in a weekend by somebody who’d never written authorization code in their life. And the advisory is sharp on the consequence. It lists arbitrary code execution vulnerabilities under four common weakness enumeration, CWE. Categories 77 through 95 as a recurring class ace in your AI plumbing. Tova Dvorin (03:43.692) Okay, let’s walk through these eight concern categories that are mentioned here, starting with access control. Adrian Culley (03:50.041) So the foundation is missing. The advisor is framing, associating a session to an identity is not defined by the protocol, but optionally achieved at the discretion of the implementer. Authentication optional, authorization optional, role-based access control, the create, read, update, delete distinction of any competent database engineer has baked in for decades. Not part of MCP at all. The result is ambiguous and untraceable access to data and context. A really bad thing. Tova Dvorin (04:22.367) Right, let me see if I pick up what you’re putting down here. You’re saying that when someone uses an MCP, it’s very difficult to tell who’s actually using it. Adrian Culley (04:29.294) In a nutshell, yes, it’s like the age old problem with databases without party plugins where anybody with God mode administrator access in the database in the past can do a rollback of the database after they’ve done bad things and return it to a previously good state, removing from a digital forensics perspective. I’m people bad things here. All evidence of the malicious activity. A similar but not identical flaw exists in non-secured MCP. Tova Dvorin (04:33.395) Right. Tova Dvorin (04:59.635) Interesting. And you know, just going back real quick to some of the things we’ve discussed before with threat groups, this is such a boon for them because they’re always trying to hide their identities, create fake identities, remove traces of the evidence anyway. So I I think I think we have a larger story here, but we’ll get to it next time. For now, let let’s get back to our list of issues. And the next one is the multi-server problem, which is what exactly? Is that one client connected to several servers at once or a different setup? Adrian Culley (05:25.592) So a modern AI client is typically connected to a dozen MCP servers simultaneously. Calendar, email, storage, ticketing, chat, CRM, internal tools. The servers don’t talk to each other directly, but the client is shoveling context between them constantly. The NSA flags this as an unverified task propagation, a class of vulnerability that doesn’t have an analog in traditional client server thinking. Tova Dvorin (05:54.614) So you’re saying that not only do we not know who’s using MCPs, we also don’t know exactly where the activity paths are. Am I right about that? Adrian Culley (06:02.434) Correct Tova unless we’re taking additional actions. Tova Dvorin (06:05.779) Okay, so that sounds a lot like the WhatsApp case the advisory is citing. Tell us a little more about that. Adrian Culley (06:10.286) So this is the canonical example. Invariant Labs demonstrated it last year. A Claude-style chat connected to two MCP servers. One legitimate WhatsApp integration the user had trusted. One new server being evaluated. The new server’s tool descriptions manipulated the client’s reasoning and the client ended up exposing WhatsApp message history through the legitimate server. Tova Dvorin (06:34.227) And no exploit code. Adrian Culley (06:36.034) No exploit code exactly Tova no CVE, just maliciously written natural language metadata coercing the client into an action it had permission to take. And the chilling detail, the malicious server presented benign tool descriptions at install time. Malicious instructions only appeared on its second use. Install time review was useless. Tova Dvorin (07:03.517) Right, and this where we get to a different issue, which is poor approval workflows. Let’s explain a little bit more about what that means in practice. Adrian Culley (07:10.926) again you bang on the money Tova the exact wording a change in capability or data access for an MCP server that is already trusted or connected often can be made without approval. You approve it once, behavior changes silently. Next time you use it it’s a different server in everything but name. Tova Dvorin (07:32.991) The classic bait and switch. So the threat model is not did we vet the MCP server we installed? It’s are we continuously verifying that the server still does what we actually vetted? Adrian Culley (07:42.986) Exactly, the protocol gives you no built-in way to do that verification. Approval is one shot, behaviour change is silent, the defender has to instrument it themselves. Tova Dvorin (07:56.876) So let’s move on to our next example, which is the GitHub MCP, because it shows a different shape of the same problem. Adrian Culley (08:03.586) When you connect the GitHub MCP server to your AI client, you grant OAuth scopes covering read and write access across all your repositories, public and private, not per repo, blanker access. Researchers show the compromised tool could read from a private repo and publish the contents to a public one. The user authorized the action technically. They had no idea what they were authorizing. The scope problem isn’t unique to MCP. OAuth scopes have been criticised for years. sorry, my bad, I’ve read your… Stop! Tova Dvorin (08:40.821) Okay, it’s fine. No, I was going to make a different analogy there, but it’s interesting. they had no idea what they were authorizing. it’s it’s like someone accessing your photos, your private photos and posting them on Facebook for you. And that’s a huge problem, particularly when it comes to code and all the vulnerabilities that may be in that code. But Adrian, I think the scope problem isn’t unique to MCP. I know we’ve had OAuth scope issues for years now. Adrian Culley (09:05.39) True, but MCP makes it sharper because the agent is autonomously deciding which scoped operations to invoke. In traditional OAuth, a human clicks something and the application takes one specific action. In MCP, the LLM selects tool invocations based on a prompt, and a maliciously crafted prompt or a poisoned upstream output can push the agent forward operations the user would never have manually performed. Tova Dvorin (09:33.855) And that brings us to serialization and context injection. Adrian Culley (09:38.809) This one should worry application security teams most. MCP transmits structured objects without enforcing any strict schemas. The NSA compares this to OWASP-A8 from 2017, insecure deserialization, but with a twist. Serialized content can include natural language instructions the LLM may interpret as commands, even though they were meant as passive data. Prompt injection at the protocol level. Not theoretical, HiddenLayers research demonstrates unsanitized tool parameters running arbitrary commands through legitimate interfaces. Tova Dvorin (10:15.723) Sneaky sneaky, but not as sneaky as token and session security concerns that are raised here. Adrian Culley (10:21.496) So the NSA quoting the spec not editorializing, sorry, the NSA quoting the spec not editorializing, I can’t say that, I have to practice. The NSA quoting the spec not editorializing, authorization is optional. Where is it used? It’s OAuth 2.1 bearer tokens, but the protocol specifies no token lifecycle management. No refresh, no revocation, no reuse control at the protocol level. The core spec mandates none of it. Combine that with it. Tova Dvorin (11:01.065) Idempotency. Adrian Culley (11:02.648) Try again Adrian, combine that with idempotency not being enforced either and you have a protocol where session hijacking and replay are entirely possible against complaint, so compliant. I’m gonna start that all again. Combine that with idempotency not being enforced either and you have a protocol where session hijacking and replay are entirely possible against compliant implementations. Tova Dvorin (11:29.707) So in a normal 2026 MCP configuration, that means an attacker can read your entire SharePoint, post to your team Slack, and create issues in JIRA. That is not a small attack and a certainly not a small level of access. Let’s compress the rest of the categories, that’s misconfiguration, inconsistent behavior, audit logs, and denial of service into some simple talking points. What’s in there that a CISO hasn’t already heard about yet? Adrian Culley (11:56.399) Two things are worth pulling out first, Tova. Number one, inconsistent behaviour. The same prompt in slightly different context can lead to different tooling vacations. The non-determinism of the LLM is itself an attack surface. A malicious actor who can precondition the agent’s context can steer the agent towards unsafe outcomes that static configuration review would never have flagged. Tova Dvorin (12:22.111) That’s a class of vulnerability that traditional InfoSec doesn’t have a playbook for. What’s the second? Adrian Culley (12:28.202) audit logging. The advisory says many implementations either omit logging entirely or capture only minimal operational metadata. In an environment where the agent is making thousands of tool invocations across multiple servers with chained outputs feeding into chained inputs, the absence of comprehensive logging means you can’t do instant response. I’ll say that again, you can’t do instant response. The operational reality is that an enterprise running unlocked MCP is running blind. Tova Dvorin (13:00.465) And with scissors, because the picture so far is broken access control, optional authentication, malleable serialization, poor session hygiene, silent behavior change, non deterministic execution, and there’s no logging to detect any of this. So it’s running blind with scissors, possibly drunk. That is a comprehensive description of a system that you should not be running unmonitored, period, full stop. But that brings us to the question of this episode. Adrian, what do you actually do about it? Adrian Culley (13:26.798) And you’re quite right Tova, don’t run blind with scissors. Absolutely don’t run blind with scissors drunk. And that’s the whole point of the MSA memo here. This is what industry are currently doing unwittingly. The recommendation section is where the document earns its keep. 12 pages of design pattern and operational guidance. And it’s really quite good. Most of it’s achievable with standard infrastructure controls. They don’t require waiting for the protocol to mature. Tova Dvorin (13:31.635) Okay. Adrian Culley (13:54.26) start with inventory because that’s where most enterprises haven’t even begun. Tova Dvorin (13:59.306) Right. The ab the advisory recommends maintaining a clear inventory of every deployed MCP agent and tool. And now it sounds basic, but try answering it within your own organization. I bet you you can’t. Adrian Culley (14:09.816) And that’s the point, how many MCP servers are connected to AI clients in your enterprise right now? Which were authorized, which were brought in by individual users, which were stood up for a proof of concept and forgotten about. Most enterprises cannot answer this today. The advisory recommends network scanning, MCP scanner, Rampart, Cyber MCP, ProximityTreat. Treat it the same way as if you treat shadow SaaS discovery. Tova Dvorin (14:37.131) And once you know what’s there, the next question is what boundaries are you setting? Adrian Culley (14:41.08) designed for boundaries exactly Tova. That’s the section heading. MCP components live in a different trust zone and different trust zones and shouldn’t be assumed as to be peers. Tools handling public data should be segregated from tools touching sensitive data. The advisory recommends aligning tools and models with data classification zones. And when processing private data, prefer a local MCP. server over a third party hosted one. We’re effectively talking about in the context of the NSA memo, not zero trust, but nuanced trust for MCP. We can’t have zero trust if it won’t work. Nuanced trust and the NSA memo is a guide to how to implement this. Tova Dvorin (15:30.557) Nuanced trust. I like it. You know, Adrian, we should explore in a later episode of why zero trust won’t work for MCP. But listeners, you’ll have to hold on for that for next time. In the meantime, it seems like based on all these, the egress filtering recommendation is the one that I would flag for any C SO listening. I don’t know about you. Adrian Culley (15:48.591) That’s the single highest leverage control in the document Tova. Use a filtering outgoing proxy. They named Squid and Tiny Proxy. SafeBridge customers are very familiar with Squid. Or your enterprise DLP with explicit allow lists for the destination’s MCP servers that are reachable. Most exfiltration scenarios depend on the malicious server reaching back out. If your egress is properly filtered, the WhatsApp style attack becomes much harder. This is a control you already have in your stack. Tova Dvorin (16:22.549) Parameter validation and sandboxing, these are developer facing recommendations, but they matter for anyone selecting MCP servers too. And then there’s also message signing. Adrian Culley (16:32.15) Validation goes beyond input validation. It’s about validating the execution context. A maliciously crafted context parameter in an MCP message can trigger unintended file IO even when the visible inputs look fine. The sandboxing piece treats every MCP tool execution as high risk, isolated context with set comp, app armor, cell Linux or Windows app containers. least privilege access to the systems and networks. Tova Dvorin (17:03.039) And message signing is the longer term protocol fix. Adrian Culley (17:05.984) It is. MCP currently relies on TLS for transport security only. The advisory recommends extending MCP messages with cryptographic signatures inside the JSON payload with expiration timestamps and replay protection. They reference OWASP ASVSV7. In the meantime, organizations deploying MCP for server-sensitive workloads should be writing signing wrappers themselves. Tova Dvorin (17:32.555) So let me zoom out a little and ask the meta question. You know, we spent a lot of time in this show on adversarial exposure validation, on CTEM, on and on the validation pillar of CTEM specifically, as we should. Now the NSA has just published a list of risks in an emerging protocol that most enterprises will only discover via being attacked. I think I know the answer to this, but where do you think this puts MCP in the entire conversation about validation? Adrian Culley (17:58.479) Squarely in scope, Tova. I’d argue MCP is the most important new validation surface to emerge in the last 18 months, if not in the last 10 years. AEV continuously runs real attack techniques against your live controls to see what fires and what doesn’t. The traditional surface has been endpoints, networks, identity, cloud workloads. MCP is the new surface. Hence this unusual and exceptional NSA memo. Tova Dvorin (18:29.875) Right, and moreover, the threat classes here are testable. Adrian Culley (18:33.688) Tool poisoning, cross server context exfiltration, indirect prompt injection through poisoned outputs, blanket scope OAuth abuse, token replay. They map clearly to the kind of technique chains the hackers playbook is built around. The defenders question is the same one we always ask. If an adversary executed this technique, would our controls catch it? Would our team respond? Would they respond fast enough? Tova Dvorin (19:00.073) Now, for a CISO who doesn’t yet have MCP threat content in their validation program, this is a lot. So what’s the immediate path forward to begin building this? Adrian Culley (19:09.262) Three things Tova. First, do the inventory. Map every MCP server connected to every AI client in your environment. You can’t validate what you can’t see. Not new wisdom. Visibility is key. Second, apply the controls in the NSA advisory that are immediately actionable. Egress filtering, sandboxing, audit logging, hooked into your scene. Existing controls applied to a new surface. Tova Dvorin (19:38.271) That sounds reasonable. What’s your third suggestion? Adrian Culley (19:41.623) Start asking your validation vendor what their coverage is for MCP class attack techniques. If you’re a safe breach customer, that conversation is straightforward. Running technique execution against your real controls extends to the surface naturally. And our content team is building MCP specific playbook entries for the threat classes the advisory enumerated. Also, I must mention to everybody Anthropic have published on their official website just this week. in response to the NSA memo, clawed security skills package that we’ve embraced in SafeBridge and you should all be embracing. can find it with a simple Google or a simple query at the Anthrobic website. However, the principle holds regardless of platform. If you can’t exercise these techniques against your environment, you don’t know whether your controls hold. Tova Dvorin (20:35.625) Right, that’s the load bearing question here. It’s not do we have controls. Of course we have controls. We always have controls. What matters is whether those controls are working against what’s actually being deployed against this attack surface. And it’s a bit of a wild rush right now. Adrian Culley (20:48.706) That’s the question Tova and the NSA has just given every CISO permission to ask it. Adrian Culley (20:58.028) The advisory is the kind of document procurement team cite and board committees ask about. If your AI strategy involves agentic systems, and at this point most enterprise AI strategies do, who doesn’t, then MCP is your environment, whether you’ve inventor, can’t say these words. MCP is your environment, whether you’ve inventorized it or not. Tova Dvorin (21:18.259) Yeah. Tova Dvorin (21:24.691) I Adrian, what do you predict is going to happen over the next three to five months? Things are moving very quickly, as you and I are both aware. Adrian Culley (21:31.983) two things Tover and thank you for that kind question. The publicly disclosed enterprise breach attributed to MCP exploitation. We’ve had research demos from invariant labs and hidden layer. We’ve had the MCP inspector RCE, CVE 2025, 49596 fixed inversion 014.1. What we haven’t had is a named enterprise victim whose breach narrative starts with the attacker compromising MCP server connected to our AI environment. That is going to come soon. Tova Dvorin (22:04.009) Okay, and then besides for obviously the regulatory side, which you and I have talked about at length, w what is the second thing that you’re watching? Adrian Culley (22:11.438) So I’m watching two things Tova in my daily scanning. Protocol first, whether the MCP working group moves on the protocol level fixes, mandatory authorization, token lifecycle, signed messages, schema enforcement. If the next major revision addresses these, the protocol matures. If it doesn’t, we’re heading for a slow motion repeat of the early 2000s web protocol security curve. where the patches came after the breaches rather than before. Tova Dvorin (22:43.253) And don’t forget about the regulatory piece. Adrian Culley (22:45.762) Thank you, Tova. So the European Union AI Act and NIS 2 both have hooks. If MCP is being used to process personal data or operate critical functions, the existing regulatory expectations around security by design apply. And the protocol spec says it’s optional, will not be acceptable defense in a regulated investigation. expect the EDPB to start asking about MCP environments in GDPR assessments within the next 12 months and these two enforcement bodies before this year is out. Tova Dvorin (23:22.655) Well, the NSA has handed enterprises a roadmap, and the question now is whether they pick it up before they need it. Adrian, thank you as always for providing us with so much useful, down to earth and relevant information about all of these changes happening in this space. Adrian Culley (23:35.606) Always a pleasure Tova and to our listeners, the full cybersecurity information sheet is publicly available from the NSA, published this weekend, just gone, May 2026, 17 pages and every word is worth your reading. Tova Dvorin (23:52.661) But until next time, listeners, stay safe, stay safe with Safe Breach. Adrian Culley (23:58.127) I think that’s an