OWASP now maintains three different Top 10 lists for the AI stack, and if you build agents you are about to be asked which one you're following. That's not a rhetorical question. The lists sit at three different layers, and the newest — the OWASP MCP Top 10, still in beta — is the one most agent teams have never read, because it covers the part of the stack they think of as plumbing.

Here is the distinction worth memorizing. The Top 10 for LLM Applications is about what an attacker can make a model say — prompt injection, insecure output handling, the things that live inside one model call. The Top 10 for Agentic Applications is one layer up: what an agent given autonomy can be made to do. And the MCP Top 10 is narrower and newer than both — it's scoped to a single protocol, the Model Context Protocol that agents use to discover and call tools. It's the first OWASP list organized around one wire format instead of a model or an app. The unifying claim of the whole document is one sentence: every MCP server you connect is a trust boundary, and most teams are wiring up a dozen of them as if they were npm install.

The boring half of the list is the dangerous half#

Read the ten items and the first thing you notice is how little of it is about AI:

Five of those — MCP01, MCP02, MCP04, MCP07, MCP09 — are bugs OWASP could have written in 2010. Hard-coded long-lived tokens, scopes that quietly widen, tampered dependencies, missing auth, rogue servers nobody registered. MCP didn't invent a single one of them. What it did was re-expose them through a channel that executes them with no human between the tool description and the action.

That's the non-obvious part, and the field data backs it up. Censys counted more than 21,000 internet-reachable MCP servers by May 2026, roughly 40% of them with no authentication at all, and Trend Micro's sweep of ~19,000 servers found hundreds with zero auth and zero encryption. The most common MCP vulnerability is not some exotic injection — it's a server on the open internet that never asked who you were. Teams skip MCP07 for the same reason they skip it everywhere: the demo worked without it.

MCP didn't create new vulnerabilities. It removed the human who used to sit between "here is a tool" and "the tool just ran."

The genuinely new risks are the ones the model reads as trusted#

The MCP-native items are MCP03, MCP06, and MCP10 — the ones where the tool's own metadata is the attack surface. In MCP, a server advertises each tool with a name, a description, and an input schema, and the host model treats all of it as trusted context. So a hidden instruction inside a tool description — text the user never sees — is a prompt the model will follow. That's tool poisoning, and because the metadata is mutable, a server can pass review with a benign description and swap in a malicious one later. Invariant Labs demonstrated the rug pull against a WhatsApp MCP server in 2025; it's the same family as the lethal-trifecta exfiltration pattern, just delivered through tool metadata instead of retrieved content.

These aren't theoretical. The CVEs have landed: CVE-2025-6514, an RCE in mcp-remote (437,000+ downloads) that a malicious server triggers through a crafted OAuth redirect, scored CVSS 9.6; the MCP Inspector RCE (CVE-2025-49596) and Cursor's CurXecute / MCPoison pair (CVE-2025-54135 / 54136) round out a year in which the Vulnerable MCP Project now tracks dozens of distinct issues.

Why the risk compounds instead of adding up#

The single most useful number in the literature is not from a vendor — it's from an academic red-team paper, "Breaking the Protocol" (arXiv:2601.17549). (Worth flagging, because a lot of blogs have misattributed this figure to Palo Alto's Unit 42, whose MCP write-up is qualitative and contains no such number.) The finding: with five servers connected to one agent, a single compromised server reaches a 78.3% attack success rate, with a 72.4% cascade to the others. The paper estimates MCP architecture amplifies attack success by 23–41% over non-MCP approaches.

Cascade is the word that should worry you. The reason a compromise spreads is structural: in MCP, every connected server runs inside the agent's shared permission context. So one poisoned tool's blast radius isn't its own scopes — it's the union of every scope the agent holds. This is the confused deputy at fleet scale, and it's why "add one more server, it's just a tool" is the most expensive sentence in agent engineering. Each server you add doesn't add risk linearly; it widens the door for every other server already in the room.

What to actually do#

The mitigations split cleanly along the same seam as the risks. For the AppSec half, you already own the playbook — you've just been deferring it: OAuth 2.1 with short-lived, audience-bound tokens (and never pass a token through to a downstream service), least-privilege scopes that can't widen silently, dependency provenance for MCP04, and an authorization posture that actually rejects tokens minted for someone else. The NSA's May 2026 guidance and the OWASP MCP Security Cheat Sheet converge on the same defense-in-depth stack; Equixly mapped the NSA controls onto each MCP item with a concrete test for each.

The MCP-native defense is the one that's new, and it's cheap: pin and hash. Fingerprint every tool definition — name, description, full input schema — the moment you approve a server, and re-diff it on every reconnect. A rug pull changes the bytes; a hash catches it before the model ever reads the new instructions. Wrap each server in a sandbox with default-deny egress so a command injection (MCP05) can't reach the internet, log every invocation to an immutable trail (MCP08), and keep an allowlist keyed on server identity plus version hash, not name — because a name-only allowlist is exactly what a typosquatted server is counting on.

None of this is glamorous. That's the whole lesson of the MCP Top 10: the protocol that made tools trivially composable also made every old web-security failure trivially composable, and it took the human reviewer out of the loop right when the stakes went up. OWASP wrote it down. The question is whether you read it before your fifth server does.