OWASP Top 10 for LLMs Applied to MCP Deployments

MCP is turning into the default wiring for connecting large language models to enterprise tools, and that shift is quietly rewriting what the OWASP Top 10 for LLMs actually means in practice. The old framework assumed a closed app with a handful of hardcoded functions. MCP breaks that assumption completely: an agent now discovers tools at runtime from any server it can reach, and every one of those servers is a fresh trust boundary the app never had to negotiate before. That single structural change, discovery instead of hardcoding, is why risks that used to be theoretical or narrow are now wide open and, in several documented cases, already exploited.

The government has started saying so out loud. On May 20, 2026, the NSA published "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," warning that adoption of MCP has outrun the safeguards built to secure it. The agency's finding was blunt: the current MCP protocol spec falls short on key security and privacy protections, and the gaps show up more clearly as real-world use accelerates, including high-stakes tasks like querying electronic health records. MCP servers on the open web are being misconfigured in ways that expose users of AI apps to attacks that don't require much sophistication to pull off. Rapid enterprise adoption of MCP-connected tooling has only sped up rollout timelines, which makes these gaps more consequential, not less.

Two OWASP efforts matter here, and they're easy to conflate. The OWASP Top 10 for LLM Applications, 2025 edition (archived as of the 2026 version released August 4, 2026) was built for standalone LLM apps. The OWASP MCP Top 10, running MCP01:2025 through MCP10:2025, is the first security framework built specifically for MCP, currently in Phase 3, Beta Release and Pilot Testing, under project lead Vandana Verma Sehgal. This piece runs the argument between them: each LLM Top 10 category takes on an amplified, sometimes mutated, form once the LLM is wired up through MCP. What follows maps LLM01 through LLM04 to their concrete MCP expression, in order, with the controls that actually address them.

What changed in the OWASP LLM Top 10 for 2025 and why those changes point toward agentic risk

The full 2025 list runs: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, LLM10 Unbounded Consumption.

Three categories are new or substantially reworked. System Prompt Leakage (LLM07) and Vector and Embedding Weaknesses (LLM08) are new entries entirely. Unbounded Consumption (LLM10) isn't new so much as renamed and widened, an evolution of the old 2023 "Model Denial of Service" category. Two categories disappeared as standalone items: Insecure Plugin Design and Model Theft. Their concerns didn't vanish, they got absorbed, Insecure Plugin Design into LLM06 Excessive Agency, Model Theft into LLM03 Supply Chain. Both of the absorbing categories, notably, have direct and ugly expressions in MCP deployments. Misinformation (LLM09) also picked up what used to be a separate "Overreliance" category.

The most telling move, though, is where Sensitive Information Disclosure landed. It jumped from sixth place to second. Rankings like that don't move on committee taste, they move because real incidents forced the issue. Every category that rose, split, or expanded in this revision cycle is one that gets switched on hardest by agentic, tool-connected deployments, which is exactly the deployment pattern MCP was built to enable. Compounding the exposure: 53% of companies building AI agents aren't fine-tuning their models at all. Whatever vulnerability sits in the base model rides straight through into every MCP-connected agent that company ships.

LLM01 in MCP: how tool description fields became the primary prompt injection surface

Prompt injection has held the top spot for two editions running, and in MCP it splits into two forms worth keeping separate in your head.

The first is indirect injection through tool results. An attacker plants instructions inside external data an MCP tool pulls in, a web page, a document, an email, a pull request title, and the agent reads that data as legitimate task context, then executes whatever's hidden inside it. In April 2026, researcher Aonan Guan of Wyze Labs, working with collaborators from Johns Hopkins University, hijacked Claude Code, Gemini CLI, and GitHub Copilot this exact way, by slipping malicious instructions into GitHub PR titles. The agents went on to exfiltrate GitHub Actions secrets and post them back out through PR comments, issue comments, and git commits. No outside infrastructure was needed to pull it off. Anthropic, Google, and Microsoft each paid modest bug bounties, but none published a public advisory or assigned a formal vulnerability identifier.

The second form is tool poisoning, and it's the one that's genuinely native to MCP. The tool description field, the plain-text help text that tells an agent what a tool does, is unsanitized. A malicious or compromised server can bury arbitrary instructions inside that text, and the agent follows them without the user ever knowing. Invariant Labs demonstrated this in April 2025 with a calculator server: the tool description carried hidden exfiltration instructions, and when a developer simply called the add function, Cursor's underlying model quietly read the developer's SSH private key and Cursor's own MCP configuration file, then shipped both off to a remote endpoint. The visible output was a normal-looking result. Nothing about the interaction looked wrong.

That's the part that separates tool poisoning from older prompt injection patterns. The attack leaves no trace, the attacker gets the data, and the victim sees completely normal behavior. The MCPTox benchmark quantified how often this works: across 45 live MCP servers and 20 LLMs, the average tool-poisoning success rate came in at 36.5%, with one model hit at a rate of 72.8%. OWASP has since classified this as MCP03:2025, with a DREAD score of 46.5 out of 50, rated Critical.

Underneath "tool poisoning" sit a few named sub-techniques worth knowing by name: rug pulls, where a trusted tool gets a malicious update after it's already been approved; schema poisoning, corruption of the interface definitions themselves; and tool shadowing, where fake or duplicate tools get introduced alongside real ones. Two CVEs put this category on the map concretely: MCPoison (CVE-2025-54136) and CurXecute (CVE-2025-54135), both exploiting the same unsanitized description field through different mechanisms. And the exposure isn't confined to one product. Disclosures between mid-2025 and June 2026 show Cursor, Claude Code, Gemini CLI, and GitHub Copilot auto-executing project-defined MCP servers with developer-level OS privileges.

Controls that actually help:

• Treat every tool description as untrusted input, and sanitize or validate it before the agent ever reads it.
• Enforce an allow-list of approved tool descriptions at the gateway layer, so a server-side edit triggers review instead of silent acceptance.
• Require a human to sign off before the agent takes any sensitive or irreversible action.
• Log what the agent read and what it did afterward. An attack that leaves no trace in the output has to be caught in the log, or not at all.

LLM02 in MCP: why sensitive data leakage scales with the number of tools an agent can reach

Sensitive Information Disclosure's jump from sixth to second wasn't a ranking fluke, it tracked real incidents. In a standalone LLM app, what can leak is bounded by what's in the training data or the prompt. In an MCP deployment, every single tool the agent can call is a fresh disclosure channel, and the more tools an agent has access to, the wider that channel gets.

Three distinct leakage paths show up here. Tool result exfiltration is the most direct: injection from LLM01 tricks the agent into calling a tool and routing its output somewhere an attacker controls, exactly what happened in the Invariant Labs SSH key demo above. Credential exposure via over-permissioned servers is the second: MCP servers can carry API keys, OAuth tokens, or database credentials in their configuration, and if that server gets compromised or its tool description gets poisoned, those credentials are now in play. The third is cross-tool context leakage, where an agent working across multiple MCP servers carries sensitive context from one server's response into another server's request, a boundary violation that simply doesn't exist in single-tool apps because there's only one tool to leak across.

Worth re-reading the Invariant Labs case through this lens: the SSH private key and MCP config file that got exfiltrated weren't anything the developer typed in. They were ambient credentials sitting on the machine, reachable only because the agent ran with developer-level OS privileges. That's a disclosure risk that has nothing to do with what the user asked and everything to do with what the agent was allowed to touch.

System prompt leakage, covered as LLM07 elsewhere in the full framework, sits close to this risk without being identical to it: business logic, API endpoints, and access secrets baked into system prompts become exposed the moment an agent surfaces them through a tool call.

Controls worth putting in place:

• Apply role-based access control before data reaches the model, not as a filter afterward.
• Redact sensitive patterns, tokens, keys, PII, from tool results before the agent ever processes them.
• Scope each MCP server's credentials to the bare minimum the task needs, and avoid ambient system-wide credentials entirely.
• Put data loss prevention checks on outbound tool calls, so a request routing sensitive content to an external endpoint gets flagged or blocked before it leaves.

LLM03 in MCP: the supply chain attack surface that grows every time a team adds a server

Supply Chain risk climbed from fifth to third in the 2025 edition, and in MCP the surface area is structurally bigger because the agent's tool set isn't fixed at build time. Teams pull servers from registries, community repos, and vendor-managed platforms, and each one of those is a fresh entry point into the supply chain, whether or not anyone thinks of it that way.

Two incidents from 2025 make the risk concrete rather than abstract. In September, an unofficial Postmark MCP server, with roughly 1,643 total downloads, got modified to quietly add a BCC field to its send_email function, copying every outgoing email to an attacker-controlled address. In June (publicly disclosed that October), a path traversal vulnerability in Smithery, a major MCP server hosting platform, exposed builder credentials including Docker configuration and Fly.io API tokens, potentially handing attackers control over more than 3,000 deployed applications.

The deeper problem is that MCP has no native defense against rug pulls. A server operator can change server behavior after users have already built trust in it, and because MCP doesn't cryptographically pin tool descriptions or version them, a server that passed audit at time zero can behave completely differently at time one. That's a supply chain attack running at the semantic layer, not the code layer, which is exactly why traditional dependency scanning misses it.

The numbers on this have moved fast. The first malicious MCP package showed up in September 2025. Between January and February 2026 alone, researchers filed more than 30 CVEs against MCP servers, clients, and tooling, and 43% of them were shell injections. CVE-2025-6514, in mcp-remote, scored a 9.6 on CVSS for OS command injection and hit versions 0.0.5 through 0.1.15 (fixed in 0.1.16). With over 437,000 downloads on the affected package, it represented a confirmed case of remote code execution on a client operating system triggered simply by connecting to an untrusted remote MCP server.

Then, in April 2026, OX Security disclosed a systemic flaw in Anthropic's core MCP STDIO transport: it allows direct configuration-to-command execution without adequate input sanitization. Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI were all affected, over 150 million downloads combined, and more than 10 Critical or High CVEs traced back to one single root cause. Anthropic's response was notable: the behavior is by design, and sanitization is left to the developer. Across 2025, four named CVEs anchor the MCP layer specifically: CVE-2025-6514 (mcp-remote RCE), CVE-2025-49596 (MCP Inspector), CVE-2025-54136 (Cursor), and CVE-2025-54994 (create-mcp-server-stdio).

None of this is confined to hobby projects, either. Security researchers have flagged supply chain risk in servers from named vendors including Smithery and GitHub, alongside the small DIY servers you'd expect. Brand recognition isn't a security signal here.

Controls that address it:

• Keep a registry of every approved MCP server, with its version and a hash of its description at time of approval. Anything not in that registry is an identity the organization can't account for.
• Pin tool descriptions, and flag or block any change between sessions before the agent re-executes against it, the same way CI/CD treats an unsigned dependency.
• Verify sources, prefer signed artifacts, and run dependency scanning on MCP server packages the same way you'd scan any software library.
• Watch runtime behavior for drift after approval. A server that starts doing something different from what it did at audit time is the rug-pull signal, and it shows up in behavior before it shows up anywhere else.

LLM04 in MCP: data and model poisoning risks that arrive through retrieval pipelines and fine-tuned server logic

The 2025 edition widened the old "Training Data Poisoning" category to cover model poisoning too, acknowledging that poisoning can happen at pre-training, at fine-tuning, or at the embedding stage, not just in the original training set.

In an MCP deployment, this risk doesn't stay confined to training pipelines, it extends straight into the retrieval layer. Tool results feed directly into the agent's context window, and that context window is an injection point: adversarial content placed there shapes what the agent believes and, downstream, what it decides to do. Two MCP-specific versions of this are worth naming. Retrieval-layer poisoning happens when an attacker controls a data source an MCP tool queries, a document store, a knowledge base, a web endpoint, and inserts content built to bias the agent's output toward a particular conclusion or action. The second runs through fine-tuned logic sitting on the server side itself, where poisoned training inputs shape how a custom MCP server responds long before any user ever sends a request through it. Both routes share the same underlying weakness: the agent trusts what a tool hands back, and MCP gives no built-in way to verify that the data behind a tool call hasn't been tampered with upstream.