The MCP Security Crisis: 1,800 Servers Without Authentication and What Comes Next
Over 1,800 public MCP servers have been discovered running without authentication enabled. Five real breaches were documented in the MCP ecosystem in 2025 alone. And the official MCP 2026 roadmap lists security as "on the horizon" — not a priority.
This is how industries accumulate catastrophic risk.
The breaches that already happened
Security researcher Iain Harper cataloged five real-world MCP security incidents in his analysis "Tooling Around: Letting Agents Do Stuff is Hard":
Asana MCP implementation — cross-tenant data access. An MCP server connected to Asana exposed data across tenant boundaries.
Anthropic MCP Inspector — unauthenticated remote code execution. The debugging tool shipped without authentication, allowing anyone on the network to execute arbitrary code.
mcp-remote package (437,000+ downloads) — supply chain compromise. A widely-used NPM package for remote MCP connections contained a remote code execution vulnerability.
Compromised "Postmark MCP Server" — a malicious MCP server masquerading as a legitimate email integration secretly BCC'd all outgoing emails to the attacker.
Microsoft 365 Copilot — prompt injection used to exfiltrate data through the agent's tool-calling mechanism.
Every incident falls into one of three categories: authentication gaps, supply chain attacks, or uncontrolled execution environments. These aren't theoretical — they happened.
The normalization of deviance
Harper draws on Johann Rehberger's essay adapting Diane Vaughan's analysis of the Challenger disaster. The pattern is familiar: organizations repeatedly get away with ignoring safety protocols, and that success embeds complacency into culture — until sudden failure occurs at scale.
Simon Willison put it bluntly:
"I think we're due a Challenger disaster with respect to coding agent security... every time I run these agents practically as root, my computer doesn't get wiped. I'm like, 'Oh, it's fine.'"
This is where the MCP ecosystem sits today. Teams are running unauthenticated MCP servers, installing unvetted third-party packages, and giving agents unrestricted access to production systems. It works until it doesn't.
The sandboxing spectrum
Not all isolation is equal. Harper evaluates the major approaches:
| Technology | Isolation Level | Startup Time | Trade-off |
|---|---|---|---|
| Standard containers | Low (shared kernel) | Fast | Easy to deploy, easy to escape |
| gVisor | Medium (user-space kernel) | Fast | 70-80% syscall coverage, some compatibility issues |
| nsjail | Medium-High (namespaces + seccomp) | Fast | Allowlisted syscalls, strong isolation, lightweight |
| Firecracker | High (full VM) | 100-200ms | Gold standard isolation, requires KVM, operationally complex |
Most MCP servers today run in standard containers or with no isolation at all. The 1,800 unauthenticated servers likely have no sandboxing whatsoever.
At MCPWorks, we use nsjail for our Code Execution Sandbox. It combines Linux namespaces for process isolation, cgroups for resource limits, and seccomp with a strict syscall allowlist. Every function execution gets a fresh, isolated environment with no network access by default, no filesystem persistence, and no ability to call dangerous system operations. It's not as heavy as a full Firecracker VM, but it blocks the attack surface that matters for code execution.
What the MCP roadmap says (and doesn't)
The MCP 2026 roadmap has four priority areas: transport scalability, agent communication, governance maturation, and enterprise readiness. Security and authorization appear only in the "on the horizon" section — community interest but not maintainer priority.
Specific security work is happening: SEP-1932 (DPoP) and SEP-1933 (Workload Identity Federation) address authentication. But execution security — what happens after an authenticated client connects and starts calling tools — is absent from the roadmap entirely.
The protocol defines how clients connect to servers. It does not define how servers should execute the code those clients request. That gap is where the breaches happen.
The decision logging gap
Harper identifies another blind spot: most observability tools (LangSmith, Arize, Langfuse) log actions after execution but lack policy context explaining why actions were permitted. Better security requires recording pre-conditions, explicit decisions with policy reasoning, and post-conditions.
The MCP spec says humans "should" deny suspicious tool invocations. But "should" is not "must," and in production systems with thousands of tool calls per hour, no human is reviewing each one. The enforcement layer has to be built into the infrastructure.
What comes next
The industry has two paths:
Path A: Wait for a major incident. A supply chain attack that exfiltrates customer data through a popular MCP server, or a prompt injection that triggers destructive actions across thousands of agent deployments. Then scramble to add security after the fact.
Path B: Build the security infrastructure now. Authentication on every endpoint. Sandboxed execution for every function call. Per-agent access control with deny-takes-precedence semantics. Audit trails that capture not just what happened but why it was allowed.
The MCP protocol is doing important work on transport and governance. But the execution layer — where code actually runs and data actually moves — needs the same level of attention. The 1,800 unauthenticated servers aren't going to secure themselves.
As Elena Cross put it: "The S in MCP stands for security."
There isn't one. That's the point.
MCPWorks is open source.
Self-host free forever, or try MCPWorks Cloud — 14-day Pro trial, no credit card.