Anthropic's Model Context Protocol (MCP) turned one year old in November 2025, and adoption has outpaced the security tooling built to cover it. By mid-2025, researchers at Invariant Labs, Trail of Bits, and independent bug hunters had disclosed prompt-injection chains, tool-poisoning attacks, and credential-leaking "rug pull" MCP servers affecting widely used integrations, including a documented GitHub MCP server vulnerability that let a malicious issue exfiltrate private repository data. Legacy supply chain vendors, including Aqua Security, have started bolting MCP scanning onto existing container and cloud posture products, but MCP servers are not containers: they are long-lived, tool-calling processes that read untrusted content and execute actions with a developer's or agent's full credentials. This piece breaks down what MCP security actually requires, where the incumbent tooling falls short, and how Safeguard closes the gap for teams shipping AI agents into production.
What Is MCP Security, Exactly?
MCP security is the practice of controlling what an AI agent's Model Context Protocol servers can access, execute, and return, because MCP was designed for functionality first and access control second. The protocol, released by Anthropic in November 2024, standardizes how large language models connect to external tools, files, and APIs through a client-server architecture. That standardization is exactly why it's risky: a single compromised or malicious MCP server can hand an LLM agent live access to a filesystem, a Slack workspace, a production database, or a cloud account, and the agent will happily use it because nothing in the base protocol distinguishes trusted instructions from attacker-supplied content. Security researchers have already cataloged four recurring failure classes: tool poisoning (malicious instructions hidden in tool descriptions), rug pulls (a server changes behavior after approval), shadowing (a rogue server impersonates a trusted one), and indirect prompt injection via tool outputs. Each of these bypasses traditional SAST, container scanning, and network firewalls entirely, because the attack payload is natural language, not a binary or a package.
Why Doesn't Traditional Supply Chain Security Cover MCP?
Traditional supply chain security tools don't cover MCP because they were built to score CVEs in dependency trees, not to evaluate what a tool description tells an LLM to do at runtime. Aqua Security's platform, like most CSPM/CNAPP suites built for the container and Kubernetes era, is strong at image scanning, workload runtime protection, and cloud misconfiguration detection. Those capabilities matter for the infrastructure an MCP server runs on, but they say nothing about whether the server's get_weather tool actually contains a hidden instruction telling the model to also read ~/.ssh/id_rsa and post it to an external URL, a real technique documented in multiple 2025 MCP tool-poisoning proofs of concept. A March 2025 Invariant Labs analysis of public MCP servers found that a meaningful share exposed tool descriptions with embedded instructions never shown to the end user, and Trail of Bits' April 2025 research demonstrated that MCP's line-level diffing in registries can be trivially evaded by encoding malicious instructions in ways that pass human review but not model interpretation. None of that surfaces in a container CVE scan, an IaC policy check, or a cloud entitlement graph, which is precisely the blind spot generalist supply chain platforms carry into the MCP era.
How Many Organizations Are Actually Deploying MCP Servers Right Now?
A large and fast-growing share of engineering organizations already have MCP servers running somewhere, often without security or platform teams knowing about it. Anthropic, OpenAI, Google DeepMind, and Microsoft all shipped native MCP support into their agent frameworks between March and June 2025, and public MCP registries such as Smithery and the official MCP registry listed several thousand community-published servers by the second half of 2025, up from a few hundred at the protocol's November 2024 launch. Internally, most of this growth is shadow IT: individual engineers connect Claude Desktop, Cursor, or Windsurf to a self-hosted MCP server for GitHub, Postgres, or internal ticketing systems in an afternoon, with no code review, no inventory entry, and no scoped credentials. That mirrors the exact pattern that produced the npm and PyPI typosquatting epidemics of 2021-2023, except the blast radius is larger, because an MCP server doesn't just execute code, it directs an autonomous agent's next actions across every other tool it's connected to.
What Actually Happened in the Documented MCP Attacks?
The documented MCP attacks so far have consistently exploited trust between the model and the tool layer rather than a memory-safety bug in the protocol implementation. In April 2025, researchers disclosed a proof-of-concept against a popular GitHub MCP server showing that a public issue containing hidden instructions could cause a connected agent, when later asked to "check open issues," to read and leak contents from the user's private repositories, because the agent trusted issue text as much as it trusted the user's own prompt. Separately, security teams demonstrated "tool shadowing," where a second, malicious MCP server registers a tool with the same name as a legitimate one and silently intercepts calls meant for it, and "rug pull" scenarios where a server behaves safely during a security review and then ships a behavior change in a later version that the client never re-approves. None of these required a traditional exploit chain, a stack overflow, or a dependency confusion attack. They required only that the MCP client trusted server-supplied text as authoritative, which is the default behavior of essentially every MCP implementation shipped in 2025.
Is MCP Security Just Prompt Injection With a New Name?
MCP security overlaps heavily with prompt injection but is a distinct and broader problem, because MCP also introduces classic supply chain and identity risks on top of the model-manipulation layer. Prompt injection covers getting a model to do something it shouldn't via crafted text; MCP security also has to cover which servers are allowed to run at all, whether a server's package or container image has been tampered with post-publication, whether the credentials an MCP server holds are scoped to least privilege, and whether server-to-server communication in multi-agent setups can be audited. OWASP's LLM Top 10 and its 2025 supplementary guidance on agentic and MCP risks now treat "excessive agency" and "supply chain vulnerabilities" as separate top-level categories from prompt injection specifically because fixing injection alone (through better system prompts or output filtering) does not fix a malicious npm-published MCP server or an over-privileged OAuth token sitting on a compromised host. Treating MCP security as purely a prompt-engineering problem is the single most common mistake teams make when they first try to secure their agent stack.
How Safeguard Helps
Safeguard closes the gap between generic cloud/container posture tools and the specific runtime behavior of MCP servers. Rather than treating an MCP server like just another container image, Safeguard's platform inventories every MCP server in use across an organization, including the shadow ones engineers spin up locally, and continuously verifies the provenance of the packages and images behind them, flagging unsigned, unpinned, or recently transferred publishers before they reach a developer's machine. Safeguard inspects tool manifests and descriptions for the injection patterns, hidden instructions, and behavioral drift (rug pulls) that static container scanners never look at, and it maps the actual credential scope each MCP server holds against what its declared tools require, surfacing over-privileged servers that would otherwise sit unnoticed with standing access to source repos, databases, or cloud accounts. Where Aqua Security and similar CNAPP vendors extend their existing runtime agents to also watch MCP server processes at the infrastructure layer, Safeguard is built around the MCP trust boundary itself: the tool description, the server's supply chain provenance, and the agent's effective permissions. For security and platform teams standing up MCP in production, that means one place to answer the three questions that actually matter: which MCP servers are running, whether they can be trusted, and what they can actually do if they're not. Teams evaluating MCP security tooling should ask any vendor, Safeguard included, to show a live scan of tool manifests and a real over-privilege finding, not just a policy document.