MCP Server Sprawl: The New Attack Surface Nobody Inventoried

Anthropic published the Model Context Protocol in November 2024 as an open standard for connecting LLMs to tools and data. By mid-2026 MCP is the default integration layer: Claude Desktop, Cursor, Windsurf, Zed, VS Code's Copilot Chat, and every major agent framework speak it natively. Public directories like Smithery and mcp.so list more than 12,000 community-published servers. That's a healthy ecosystem — and a supply-chain attack surface that looks a lot like npm circa 2018, only shorter-lived and higher-privilege.

What an MCP server actually is

An MCP server is a small process — usually stdio- or SSE-based — that exposes tools, resources and prompts to an MCP client (the model). Tools are functions the model can invoke. Resources are files, database rows, API responses the model can read. A typical developer laptop in 2026 runs a filesystem server, a git server, a Postgres server, a Jira server, a browser-automation server, and three or four experimental ones the developer installed from a tweet.

Each server runs with the *developer's* privileges on the developer's machine. That is the whole security story in one sentence.

The documented failure modes

The research community moved quickly. Between late 2024 and mid-2026 the following classes were demonstrated in the wild or in coordinated disclosure:

• Tool poisoning (Invariant Labs, April 2025). Malicious instructions hidden inside a tool's `description` field — invisible in most clients' UIs, fully visible to the model.
• Rug-pull updates. A server the user approved on install silently changes its tool descriptions on a later version bump.
• Cross-server shadowing. A malicious server redefines the semantics of a trusted server's tool by claiming a similar name.
• Prompt injection via resources. The classic indirect-prompt-injection pattern, now with filesystem and database read access.
• Confused-deputy exfil. A benign-looking `read_file` tool combined with a benign-looking `http_get` tool yields data exfiltration the model happily orchestrates.
• Command-injection in the server itself. Several early community servers shell out to `git`, `psql` or `curl` with insufficient argument escaping.

Why this is worse than npm

npm packages run at build or request time, usually inside CI or a server sandbox. MCP servers run on the developer's laptop, with access to their SSH keys, cloud credentials, source repositories, and — through connected tools — production systems. The blast radius of a compromised MCP server is closer to a compromised IDE extension than a compromised library.

The install pattern makes it worse. Most servers are launched via `npx`, `uvx`, or `docker run` from a config file the developer edited by hand after copy-pasting from a README. There is no lockfile, no signature check, no sandbox by default.

Controls that are shipping

• Signed servers and a curated registry. Anthropic's official MCP registry (GA in Q2 2026) publishes signed manifests and pinned versions. Prefer it over ad-hoc directories.
• Sandboxed execution. Run MCP servers inside containers or `bubblewrap`/`firejail` with explicit filesystem and network scopes. Docker's MCP Toolkit and the `mcp-run` sandbox are the current mainstream options.
• Explicit tool-approval UI. Clients that surface each tool call for approval (Cursor, Zed) beat clients that auto-run (early Claude Desktop settings). Turn approval on.
• Description integrity checks. Warn on any change to a tool's description between sessions. Invariant's `mcp-scan` and Prompt Security's MCP guard both implement this.
• Per-server credentials. Never share your personal cloud credentials across servers. Use short-lived, scoped tokens per MCP process.
• Network egress allow-lists. The MCP server for reading local Postgres has no business talking to the internet.

What CISOs should do this quarter

• Inventory. Ask developers what MCP servers they run. Most will not have a list; helping them build one is the entire first sprint.
• Golden config. Publish a sanctioned MCP config with signed servers, sandboxing, and per-tool approval enabled. Make it the default in your IDE templates.
• CI checks. Scan committed `.mcp/config.json` (or equivalent) for unsigned or unpinned servers, the same way you scan `package.json` for known-vulnerable packages.
• Incident playbook. Assume the first MCP-server incident in your org will look like a developer-laptop compromise. Pre-write the response.

Standards and guidance

• Anthropic MCP Security Best Practices (2025, updated 2026). The baseline; every team using MCP should have read it.
• OWASP LLM Top 10 (2025). LLM03 Supply Chain and LLM06 Excessive Agency both apply directly.
• CISA/NSA guidance on AI system deployment (2024). Extended in a 2026 addendum to cover tool-using agents.
• NIST SP 800-218A. Secure development practices for generative AI, now cited by several US federal buyers as a procurement requirement.

MCP is the best thing that happened to developer productivity in a decade and the worst thing that happened to developer-endpoint attack surface in the same decade. Both are true. Ship the inventory this quarter.