MCP Servers Have a Security Problem Baked In

There's a particular kind of security problem that's worse than negligence: the kind that was designed in. Negligence you can patch. Design you have to argue about.

That's where the Model Context Protocol finds itself in the summer of 2026.

Research published in July under the arXiv paper 'Exposed by Design' (arXiv 2608.00150) and reported by forkast.news detected over 21,000 internet-facing MCP server instances currently exposed online. Of the 640 production servers the researchers actually audited, 91.8% lacked OAuth authentication. Six hundred and eighty-seven instances had unrestricted access to whatever was behind them. That's not a tail risk. That's the median outcome.

Trend Micro's independent research, which tracked the same exposure trend widening into cloud infrastructure, found the numbers surge to nearly triple as MCP adoption spread—and found that attackers had gained the ability to seize control of cloud services through exposed servers. When a separate security firm runs its own numbers and comes back with "worse, actually," that's a signal worth paying attention to.

Then there's the architectural finding that lands harder. In May 2026, according to engipulse.com, researchers identified that over 200,000 MCP servers contain a flaw allowing arbitrary command execution. Anthropic, MCP's creator, has reportedly characterized this capability as a feature — the protocol is supposed to let AI agents run commands on the systems they connect to. That's the whole value proposition. The agent needs to do things, not just read things.

Here's what that means in practice: the attack surface isn't a vulnerability in the traditional sense, something introduced by a careless developer on a bad Tuesday. It's the protocol doing exactly what it was built to do, pointed at systems that were never hardened for the assumption that an AI agent—potentially manipulated through prompt injection—would be issuing commands against them. The "feature" frame is defensible as a technical description and catastrophic as a deployment posture.

This is the oldest story in infrastructure security, just wearing new clothes. Redis shipped without authentication by default for years because its designers assumed it would run on trusted internal networks. Exchange Server became a perennial breach vector not because Microsoft couldn't write secure code but because organizations deployed it in configurations that assumed a perimeter that didn't exist. In both cases, the design met the designers' assumptions perfectly. The problem was that real-world deployments blew past those assumptions almost immediately, and the community spent years cleaning up the gap between "this is how it was intended to be used" and "this is how people actually use it."

MCP is running the same play, faster, because AI adoption timelines are compressed relative to every previous infrastructure wave. Wiz's security research puts the remediation options plainly: add authentication, or scope the server's backend credentials so there's nothing sensitive to reach. The fix isn't exotic. The problem is that "add authentication" requires someone to decide authentication is their job, and in the current MCP ecosystem — where developers are moving fast, spinning up agents against production systems, and treating MCP servers as glue code rather than infrastructure — that decision isn't getting made.

The Hacker News discussion that surfaced when this research hit the front page produced the most direct framing of what the community actually needs: lockfiles, audit commands, and signed provenance — the same tooling discipline that npm eventually developed after its own ecosystem security crises. That's the right analogy. npm's early years were a period of explosive adoption followed by a slow, painful reckoning with supply chain integrity. The community eventually built the tooling. But "eventually" took long enough that there were real breaches in between, and the organizations that got caught in the gap don't get a retroactive refund.

The MCP agent security architecture questions this raises go deeper than server configuration. An AI agent operating through MCP isn't just reading data — it's taking actions. Prompt injection attacks, where malicious content in the agent's environment manipulates it into executing unintended commands, become a first-order threat rather than a theoretical one when the agent has unrestricted command execution on the other end of the connection. The attack chain — compromise an MCP server, inject a prompt, execute arbitrary commands, pivot to cloud infrastructure — is not speculative. Trend Micro's research found it operational in the wild.

Cryptorank.io's coverage describes this moment as a "Seoul Inflection Point," which is a fine piece of branding for a conference slide but undersells what's actually being said. What the data describes isn't a moment of inflection so much as a moment of recognition — the gap between design assumptions and deployment reality has been there since MCP servers started shipping. We're just now measuring it carefully enough to see how wide it got.

What the numbers actually tell you

The 21,000 exposed instances is the headline figure, but the 91.8% OAuth gap across those 640 audited production servers is the number that should make enterprise security teams uncomfortable. Production servers. Not developer sandboxes, not test environments — servers that someone decided were ready to face the internet. Nearly all of them unauthenticated.

That's not a training problem or a documentation problem. That's a protocol that shipped without making authentication the obvious default path, deployed by practitioners who reasonably concluded that if authentication were critical, the tooling would have made it harder to skip. Wiz's same research notes that for the code-execution class of exposure specifically, the agent's prompt and invocation logs are the one place anomalous activity tends to surface — which means detection depends on organizations actually monitoring those logs, which requires knowing they should, which requires security awareness that's currently outpaced by adoption speed.

Anthropic built MCP to accelerate what AI agents can do. It has succeeded. The protocol is genuinely useful — the adoption numbers prove that, if nothing else. The security posture of the current deployment landscape is, charitably, early-internet-era. And this is the part that no amount of community tooling will fully resolve: Anthropic controls the protocol design, the reference implementations, and the ecosystem narrative. The community can build npm-style audit tooling. The community can write better deployment guides. The community has been fixing the gaps left by under-secured protocols since the 1990s, and the community has a perfect track record of eventually getting there — usually about eighteen months after the breach that made the news.

There are two problems here: a protocol design problem and a deployment culture problem. History is pretty clear on how "the community will sort out the deployment culture" ends. You're left hoping the protocol design problem gets addressed before enough production systems get compromised to give MCP its own Wikipedia disambiguation page.

---

Mike Sullivan covers the technology industry for BuzzRAG.