MCP Security Debt Grows as AI Agent Protocol Adoption Soars

From open standard to default plumbing

When Anthropic open-sourced the Model Context Protocol in November 2024, the pitch was simple. MCP would be an open standard for building secure, two-way connections between AI assistants and the places data actually lives: content repositories, business tools and development environments 4. Developers could expose data through MCP servers or build AI clients that connect to them. Anthropic shipped the specification, SDKs, local server support in Claude Desktop, and pre-built servers for systems like Google Drive, Slack, GitHub, Git, Postgres and Puppeteer 4. The company also noted that its model could quickly build new server implementations, which lowered the barrier to connecting sensitive datasets to AI tools 4.

By most measures, the standard has succeeded. Industry tallies put MCP at more than 97 million monthly SDK downloads and over 10,000 active public servers, with first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and VS Code 2. Few developer standards have spread this fast. The speed of that spread is also the core of the security problem.

The numbers behind the debt

Independent scans keep finding exploitable flaws in a large share of public MCP servers, with estimates ranging from 30% to 82% 2. Only 8.5% of servers reportedly use OAuth 2. An offensive-security assessment covering 2025 into February 2026 found 43% of tested servers vulnerable to command injection 2. A separate analysis of 2,614 implementations found 82% used file operations prone to path traversal 2. Several major CVEs, including CVE-2025-6514, CVE-2025-49596 and CVE-2025-54136, are said to have affected hundreds of thousands of developer environments 2.

These figures come from different firms using different methods, and the wide 30–82% range shows they shouldn't be read as one precise measurement. They all point the same way, though.

The incident record supports them. In October 2025, researchers disclosed a command-injection flaw in the Figma/Framelink MCP integration 1. Unsanitised user input reached shell commands, which could allow remote code execution and potential access to design data or infrastructure 1. The root cause was ordinary: untrusted input passed to Node's child_process.exec 1. A supply-chain issue involving Smithery's MCP hosting followed in the same period 1. Authzed draws a blunt conclusion from this run of breaches: developers wired powerful systems together without applying established security controls, and the AI-native world turns out to follow the same rules as traditional software 1.

Bugs, or design?

The sources diverge on one important question: whether MCP's problems are mostly implementation sloppiness or something deeper.

The breach timeline mostly describes classic bugs, such as missing input sanitisation and weak supply-chain hygiene 1. Those can be fixed one server at a time. Security researchers have also named a set of attack classes specific to agentic tooling. These include tool poisoning, "rug pulls" in which a tool silently redefines itself, tool shadowing, cross-server attacks, confused-deputy and OAuth weaknesses, and prompt-injection "toxic agent flows" 2. Simon Willison's "lethal trifecta" framing and an OWASP MCP Top 10 have tried to catalogue them 2.

Academic work goes further. A recent arXiv paper describes itself as the first rigorous security analysis of the MCP specification 3. It identifies three protocol-level weaknesses:

• No capability attestation: servers can claim arbitrary permissions.
• Unauthenticated bidirectional sampling: servers can inject prompts back toward the model.
• Implicit trust propagation: in multi-server setups, trust spreads without checks 3.

The authors argue these weaknesses are architectural rather than implementation-specific, so they need fixes at the protocol level 3. Their proposed extension, AttestMCP, adds capability attestation and message authentication. They report it cut attack success rates from 52.8% to 12.4%, with a median overhead of 8.3 milliseconds per message, while staying backward-compatible 3.

Reading the situation

Both diagnoses are probably right, and that is the uncomfortable part. Much of the measured exposure comes from ordinary engineering failures that have no special connection to AI. A protocol designed for easy connection, and promoted with AI-generated server code, invites exactly those shortcuts 4.

The architectural critique adds a further point. Even well-written servers sit inside a trust model that can't verify what a server claims to do or where a sampled message came from 3. Patching individual CVEs won't close that gap.

MCP's adoption and its security posture are now moving in opposite directions. Each new client integration widens the attack surface faster than audits can shrink it. Protocol-level measures like attestation are cheap by the researchers' own figures 3. Making authentication and capability checks a default part of the standard, rather than an add-on, looks like the clearest path to paying down this debt. Until that happens, organisations deploying MCP should treat every server as untrusted code with access to their data.