OWASP now maintains a Top 10 dedicated to Model Context Protocol — its first list scoped to a single agent protocol rather than to LLM applications generally. It’s in beta, the categories run MCP01 through MCP10, and it covers the failures that actually show up in MCP deployments: token mismanagement, tool poisoning, shadow servers, context oversharing.
A protocol getting its own OWASP list is a milestone, and not a flattering one. You don’t get a dedicated Top 10 because your ecosystem is doing well. You get one because enough things broke in enough similar ways that the pattern needed a name.
I’d argue the list is the second most useful thing to come out of this. The first is the census work underneath it.
The uncomfortable number
Internet-wide scanning of MCP deployments has been running through 2026, and the results are consistent across independent efforts even where the exact figures differ. Censys found on the order of twelve thousand MCP services reachable from the public internet, with roughly 40% requiring no authentication at all. Among the servers that do authenticate, the majority lean on static API keys — one long-lived credential, no expiry, no per-operation scope — with only a small minority using OAuth with short-lived tokens.
Separately, researchers filed dozens of CVEs against MCP servers, clients, and tooling in the first months of 2026. The striking thing about that batch is how boring it is: path traversal, command injection, the kind of findings that would have been unremarkable in a 2005 web-app assessment. These are not exotic attacks on a novel protocol. They’re the oldest bugs in the profession, showing up in a new tier of infrastructure that got deployed faster than it got reviewed.
Treat the specific percentages as directional — different scans use different definitions of “MCP service” and the population is moving weekly. The shape of the finding is what matters, and every scan agrees on the shape: a large fraction of MCP infrastructure is running with authentication that a security review would have rejected on any other tier of your stack.
Why this happened, structurally
It’s tempting to file this under carelessness. It isn’t, mostly. Three structural things produced it.
MCP servers got built by application teams, not platform teams. The whole appeal of the protocol is that wiring a tool to an agent is a small amount of code. That’s a genuine win, and it also means the thing got stood up by someone whose job was the integration, not the exposure. The first MCP server in most organizations was a prototype that nobody re-classified when it started carrying real traffic.
“Internal” did the usual amount of damage. An MCP server on the corporate network, reachable by an agent that only staff can talk to, feels internal. It isn’t — the agent is a component an attacker can influence through prompt injection, which is the whole argument for treating the model’s output as a request, never an authorization. An MCP server trusting “our” agent is trusting whatever text reached that agent last.
Nobody owned the inventory. This is the agent sprawl problem wearing a security hat. You cannot audit a fleet you cannot enumerate, and the median organization’s MCP fleet grew from one to a dozen without ever passing through a system of record.
The audit, in the order I’d run it
The OWASP list is a good taxonomy and a bad starting point, because it presumes you know what you’re running. Do the census first.
1. Enumerate. Find every MCP server your organization operates — including the ones running on a laptop, in a team’s own cloud account, and inside a container someone shipped six months ago. Scan your own address space the way an outside researcher would; if an external scan finds servers your inventory doesn’t have, that gap is the finding.
2. Classify by exposure. For each one: is it reachable from the internet? From the whole corporate network? What identity does it require, and what does that identity get? A server with no auth on a public IP is an incident you haven’t been paged about yet, and it goes to the front of the queue ahead of everything else on this list.
3. Kill the static keys. A long-lived API key shared by every caller gives you no attribution and no revocation short of rotating everyone. Short-lived, scoped tokens derived from the originating principal are the fix, and they’re the single highest-leverage change on this page.
4. Inventory the tools, not just the servers. Tool poisoning and context oversharing are OWASP categories precisely because the dangerous surface is one level below the server. What can each tool actually do? Which of them can write, delete, deploy, or spend? Any tool with a shell in it deserves a specific, written justification.
5. Then read the Top 10. With an inventory and an exposure map in hand, the list becomes a checklist you can execute against real systems instead of a document you agree with and file.
The honest framing
None of this is novel security work, and that’s the point I’d want a platform team to take away. There is no MCP-specific exploit class here that demands new expertise. The fixes are authentication, scoped credentials, least privilege, input validation, and inventory — the same five things that fix most of everything, applied to a tier of infrastructure that skipped the review because it looked like glue code.
The reason it needs saying out loud is that the exposure curve and the governance curve are running at very different speeds. MCP’s specification and its stewardship matured a great deal this year. The median deployment did not. OWASP writing the list is evidence the industry noticed. Whether your organization is on the right side of those numbers is a question you can answer this week, with a scan and an afternoon.
Count first. The list will still be there.
Related: No anonymous inference endpoints · The OWASP Agentic Top 10 for platform teams · Agent sprawl
Comments