Does Your CTEM Program Have an AI Blind Spot?

Most enterprise Continuous Threat Exposure Management (CTEM) programs are built around the same model: discover, scope, and prioritize what’s exposed on endpoints, networks, identity, and cloud workloads; validate exploitability; and remediate. While the framework is sound, the scope is increasingly wrong.

Over the last two years, a new layer of infrastructure has been quietly wired into enterprise environments: the Model Context Protocol (MCP). It’s the connective tissue of every agentic AI deployment your organization has shipped, evaluated, or allowed employees to stand up on their own. And the NSA published an advisory about MCP in May 2026 for a reason: the existing security model has not kept up with the protocol’s adoption, and it’s a blind spot attackers are already aware of. The exposure is not US-specific—the same agentic AI deployments are squarely in scope for the EU AI Act’s Article 15 cybersecurity obligations, NIS2, and DORA, all of which now treat AI system integrity as a regulated control.  

The Infrastructure Your Security Program Isn’t Watching

MCP is the application-layer protocol, open-sourced by Anthropic in November 2024, that lets AI agents communicate with external tools and data sources in a standardized way. Think of it as a universal connector for AI—the reason your Copilot can check your calendar, query a database, or post to Slack. It’s the protocol underneath many of the agentic AI products deployed since late 2024: Microsoft Copilot, AutoGen Studio, Harvey AI in the legal sector (which operates as both an MCP client and server), and hundreds of custom internal deployments built by teams who needed AI to do something, not just generate text.

But MCP creates a unique security problem because it inverts the traditional client-server model. In a normal architecture, the client requests, the server responds, and scope is relatively clear.

In MCP, the AI agent is the client, but it’s the MCP server that’s executing actions on its behalf: calling tools, retrieving data, triggering workflows.

An AI agent connected to a dozen MCP servers simultaneously—calendar, email, storage, ticketing, CRM, internal tools, and more—has a blast radius your identity and access management (IAM) policies were never designed to contain.

The NSA’s advisory is unusually direct about what this means: the protocol’s security model is underspecified by design. Authentication and authorization are both optional. Role-based access control is not defined by the protocol at all. Associating a session to an identity, in the NSA’s words, “is not defined by the protocol, but optionally achieved at the discretion of the implementer.”

Most CTEM programs are designed to find and validate exposures across a traditional attack surface—they are almost certainly not taking this new attack surface into account.

The Attacks Are No Longer Theoretical

The advisory doesn’t read like a warning about future risk. It reads like a catalog of techniques that researchers have already demonstrated against production-grade implementations—and that map directly to the kind of attack chains adversarial exposure validation (AEV) is built to test. The same techniques also map cleanly onto MITRE ATLAS, the adversarial machine learning (ML) threat framework purpose-built for AI systems—which means a CTEM program scoped only to MITRE ATT&CK Enterprise will miss them by design. For example:

• The WhatsApp MCP exploit documented by Invariant Labs. A malicious MCP server, introduced into an environment that also hosted a legitimate WhatsApp integration, manipulated the AI client’s reasoning and coerced it into exposing WhatsApp message history through the trusted server. No exploit code. No CVE. Just maliciously crafted tool descriptions written in natural language, manipulating a client that had permission to take the action. The malicious server presented benign behavior at installation—then switched instructions on its second use. The approval was real. But the thing that was approved was no longer the thing that was running.
• The GitHub MCP implementation that Invariant Labs demonstrated was vulnerable to indirect prompt injection via malicious GitHub Issues. A payload embedded in a public repository’s issue coerced the AI agent into reading data from private repositories and writing it into a public pull request—accessible to anyone. The agent had the permissions to take the action, and the user never saw it coming.
• CVE-2025-49596, an RCE vulnerability in MCP Inspector—the reference tool Anthropic itself maintains for testing MCP servers during development—that accepted unverified inputs and allowed arbitrary code execution via crafted messages. If the protocol’s own creator can ship a critical RCE in its reference tooling, the surface is not theoretical for anyone building on top of it. The lesson: the toolchain around MCP is as exposed as the protocol itself.

These aren’t edge cases. They’re a class of attack—tool poisoning, cross-server context exfiltration, indirect prompt injection, token replay, blanket scope abuse—that a traditional CTEM program leveraging traditional security controls and processes was never designed to detect or validate.

Why Zero Trust Doesn’t Close the Gap

Many security leaders assume their zero trust architecture covers this. It doesn’t—not natively, and not for the threat classes the NSA advisory identifies. The practical consequence: an attacker can sit inside an MCP server that has already cleared every access control check your organization has, and quietly redirect what an authorized AI agent does—with no alert fired and no policy violated. 

Zero trust, as defined in NIST SP 800-207, is built around explicit verification: authenticate the identity, validate the device, enforce least privilege per request. Those primitives work well when the adversary is trying to subvert identity, but MCP attacks don’t subvert identity. They subvert meaning.

A malicious server that changes its tool description after approval passes every classical zero trust check. The message arrives from a valid source, correctly signed, and on an expected channel. The authorization is granted. What changes is the behavior of the thing that was authorized—silently, with no protocol-level mechanism to detect it.

The advisory describes this as “trust decay”: trust that was granted at a point in time persisting beyond the moment the thing being trusted changed. Zero trust was architected to continuously verify identity and device posture. It was not designed to continuously verify whether the semantics of an approved tool description are still what they were when you approved it. That’s a different problem—and it requires a different layer of validation.

What Effective Validation Looks Like for MCP Environments

The NSA advisory is, if you read it carefully, an AEV brief in disguise. Every concern it raises is empirically testable. Every technique it documents maps to the kind of attack chain that continuous validation is built to exercise.

Does a detection fire when a tool description silently changes scope after approval? Can context from one MCP server contaminate another connected to the same agent? Does your input validation hold under a crafted, malformed JSON-RPC parameter? Does your SIEM catch anomalous tool invocations in real time—or only after the fact, if at all?

These are not questions you can answer by reviewing policy. The protocol doesn’t carry enough policy to inspect. You can only answer them by exercising the attacks against your live controls to see what fires and what doesn’t.

Where to Start

The NSA’s advisory outlines a practical path forward. Three actions have the most immediate leverage:

• Inventory first. How many MCP servers are connected to AI clients in your environment right now? Which were authorized through change control, which were stood up for a proof of concept, and which were brought in by individual users? Most organizations cannot answer this today. Network scanning tools named in the advisory—MCP Scanner, Rampart, Cyber MCP—exist specifically for this purpose. MCP servers may dynamically change ports between scans, so a point-in-time snapshot isn’t sufficient. Treat this as ongoing shadow SaaS discovery applied to a new layer of infrastructure. An inventory only tells you what’s connected—it doesn’t tell you what’s exploitable; that’s where SafeBreach’s attack surface validation extends the picture, testing whether a discovered MCP server can actually be abused before an attacker finds out for you.  
• Mandate authentication on sensitive deployments. Authorization is optional by specification. It doesn’t have to be optional in your environment. Any MCP server handling sensitive or regulated data should require identity-aware proxy enforcement, mutual transport layer security (TLS), and role-based access control (RBAC) before it stays in production—regardless of what the protocol spec makes mandatory. SafeBreach can validate that these controls actually hold under the same tool-poisoning and trust-decay techniques the NSA documents, rather than trusting that a configuration change works as intended. 
• Instrument every tool invocation. Log parameters, identities, and cryptographic hashes of results. Integrate them into your SIEM and correlate 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—because in MCP environments running blind, you also tend to be running without the forensic record needed to do incident response at all. SafeBreach can simulate these attack chains end-to-end and confirm whether your SIEM and detection stack actually fire—closing the loop between “we log it” and “we’d catch it.” 

The Question Your CTEM Program Should Be Asking

MCP is the most significant new validation surface to emerge in the last decade. The NSA doesn’t publish on emerging integration protocols unless they’ve crossed from “interesting” to “load-bearing in industry.” MCP has clearly met that threshold.

If your AI strategy involves agentic systems—and at this point, most enterprise AI strategies do—then MCP is part of your environment, whether you’ve inventoried it or not. Your CTEM program should be helping identify whether you’ve validated that your controls actually hold against the MCP-style attacks that are already documented, already researched, and—according to the NSA—already in the wild.

If it’s not, your program has a blind spot. But it is identifiable, which means it is also fixable. The SafeBreach CTEM Platform can help. Request a customized demo to see it for yourself.