The model context protocol has a security problem nobody wants to talk about

Automation Engineering · By Caleb Sakala · March 25, 2026

Somewhere in the last six months, the model context protocol went from an interesting Anthropic side project to the connective tissue of every AI agent stack. The MCP registry hit 6,400 servers in February 2026. OpenAI, Google, and Microsoft all shipped native support. If you're building anything with AI agents right now, someone on your team has probably already added an MCP server or two.

Here's the problem: nine major security breaches in ten months. Not theoretical vulnerabilities published in academic papers. Real incidents, real data exposed, real CVEs filed. And the developer community keeps treating MCP adoption like plugging in a USB cable.

That comparison comes from Anthropic's own marketing, by the way. MCP is "like USB-C for AI." A useful analogy, right up until you remember that USB devices have been a primary attack vector for over a decade.

Nine model context protocol breaches in ten months

The first major incident hit in April 2025, barely five months after Anthropic released the protocol. Invariant Labs demonstrated that a malicious MCP server could exfiltrate a user's entire WhatsApp history by disguising data theft as outbound messages. The attack combined "tool poisoning" (hiding malicious instructions in a tool's description metadata) with a legitimate WhatsApp MCP server. The user never saw anything unusual.

A month later, GitHub's official MCP server got hit. Someone posted a malicious issue to a public repository, and the prompt injection was enough to extract private repository contents through the MCP connection. The root cause was painfully simple: broad Personal Access Token scopes combined with zero content sanitization in the LLM context. Private repos, internal project details, financial data, all accessible because the MCP server trusted whatever the model fed it.

Those two incidents alone should have slowed adoption. They didn't.

In July 2025, CVE-2025-6514 dropped on mcp-remote, an OAuth proxy component used by Cloudflare, Hugging Face, and Auth0 among others. The bug allowed OS-level command injection through malicious authorization endpoints. The package had over 437,000 downloads. Anyone running it was handing attackers a shell on their machine.

The rest of the year was just as bad. Asana's MCP server leaked data across organizations because cross-tenant isolation failed at the access control layer. Anthropic's own filesystem MCP server had sandbox escape vulnerabilities (CVE-2025-53109, CVE-2025-53110) that exposed the entire host filesystem. A fake Postmark MCP package on npm silently BCC'd copies of every email to an attacker-controlled server. And in October, Smithery's MCP hosting platform got breached through a path-traversal bug that exposed Docker credentials and a Fly.io API token controlling over 3,000 applications.

That's not a list of edge cases. That's a pattern.

Why the model context protocol security model breaks down

It would be comforting to blame individual developers for writing bad MCP servers. Some of these bugs were, in fact, basic. The Figma MCP server vulnerability (CVE-2025-53967) came from unsanitized user input passed directly to shell commands, which is Security 101 stuff. But the bigger issue is architectural, and it's the same class of problem that plagued browser extensions and OAuth integrations for years before those platforms matured.

MCP gives AI models the ability to call external tools. The model decides which tools to call, with what parameters, based on context that includes user input and tool descriptions. Every part of that chain is attackable. Tool descriptions can contain hidden instructions that override the model's behavior. User prompts can be crafted (or injected via external content like emails or GitHub issues) to trick the model into calling tools it shouldn't. And once a tool executes, the specification provides no standard mechanism for verifying that the operation matches what the user actually intended.

Traditional API security assumes a human or a deterministic program is making requests. MCP breaks that assumption. The caller is a language model making probabilistic decisions based on context that attackers can influence. That's a fundamentally different threat model, and most MCP server authors are building as though the old assumptions still hold.

The specification's security page acknowledges these risks. It recommends consent flows, scoped permissions, and human-in-the-loop patterns. But recommendations aren't enforcement. The protocol itself has no built-in authentication between client and server, no mandatory permission scoping, and no audit logging requirement. Everything is left to implementation. And implementations, as ten months of breaches prove, get it wrong.

What to do if you're already running MCP servers

Skipping MCP entirely isn't realistic for most teams building AI agent systems in 2026. The protocol genuinely solves a painful integration problem, and the server registry is too large to walk away from. But treating every MCP server as trusted infrastructure is reckless.

The single highest-impact change is scoping tokens to the absolute minimum. The GitHub breach happened because the Personal Access Token had broad permissions. If that token had been scoped to read-only access on public repos, the damage would have been zero. Every MCP server connection should use the most restrictive credential possible. This sounds obvious, but the default configuration for most MCP servers asks for more permissions than they need, and most developers accept the defaults.

Running MCP servers in isolated environments matters nearly as much. The filesystem and mcp-remote vulnerabilities both escalated because the server ran with the same privileges as the user's development environment. Containerized servers with restricted network access limit blast radius. If a server gets compromised, the attacker gets a container, not your laptop. Chase Agents sandboxes each MCP connection with per-tool permission boundaries, so a compromised tool description can't silently escalate to other tools in the same workflow.

Two other practices are worth the effort even though they feel tedious. Audit tool descriptions on third-party MCP servers before connecting them, because tool poisoning works specifically because nobody reads these after initial setup. A "random fact of the day" tool shouldn't need access to your messaging history. And build logging into the MCP client layer before you need it for incident response. The biggest operational gap in MCP deployments right now is observability: when something breaks, teams can't answer the basic question of which tool was called, with what parameters, and what data came back.

The hosted MCP problem

Managed MCP hosting adds risk that most teams underestimate. Running someone else's code on your behalf is always a trust decision, but MCP hosting concentrates that trust in ways that amplify failure. The Smithery breach proved this concretely: a path-traversal bug in the build system exposed credentials controlling thousands of customer applications. The hosting platform became a single point of compromise for every user who connected to it.

This doesn't mean hosted MCP is always wrong. But the vendor selection question for MCP hosting is a security question, not a convenience question. Before connecting an AI agent to a hosted MCP server, verify that the platform isolates each server's runtime environment, rotates credentials automatically, and provides audit logs your team can access independently. Automation platforms that orchestrate MCP connections natively (Chase Agents runs each server in its own isolated runtime, for instance) tend to handle isolation better than raw hosting providers, simply because sandboxing is already part of the architecture rather than bolted on afterward.

One prediction worth tracking

By the end of 2026, at least one MCP breach will directly cause a publicly reported data leak large enough to trigger regulatory action under GDPR or an equivalent framework. The attack surface is too broad, adoption is too fast, and the security tooling is too immature for this not to happen. The specification maintainers seem to know it. Their 2026 roadmap focuses heavily on authentication, authorization, and auditability improvements. Whether those improvements ship before the next major incident is an open question.

The model context protocol is probably the right idea. A standardized way for AI agents to connect to tools and data sources was always going to be necessary, and MCP's design is reasonable for what it attempts. But "right idea" and "production-ready" are different categories. The protocol needs better security primitives baked into the spec itself, not left as implementation details. Until that happens, every MCP deployment is a bet that your implementation got the security right in ways that GitHub, Anthropic, Asana, Cloudflare, and dozens of others did not.

Treat MCP servers the way you'd treat a third-party API that has root access to your machine. Because right now, that's effectively what they are.

FAQ

Wait, is MCP actually unsafe to use right now?

Not inherently. The protocol design is solid for connecting AI models to tools. The problem is that security controls are entirely optional, and most implementations skip them. Scope permissions tightly, isolate server runtimes, audit tool descriptions, and the risk drops substantially. Install random MCP servers from npm without reviewing them, and you're asking for trouble.

Doesn't the new MCP auth spec fix all this?

The streamable HTTP transport and updated auth framework address some authentication gaps. They don't fix tool poisoning, prompt injection, or supply-chain risks with third-party servers. Auth is necessary but nowhere close to sufficient.

Should teams just wait for the spec to mature before adopting?

Waiting means missing integration benefits that are real and significant. A better approach: adopt MCP now, but treat every server as an untrusted component. Defense in depth, not avoidance.