The Model Context Protocol standardised how agents discover and call tools, and by 2026 it is the connective tissue of agentic systems: IDEs, desktop assistants, enterprise platforms and orchestration frameworks all speak it. Its design choices created an attack surface that the OWASP MCP Top 10, the Cloud Security Alliance and a long list of CVEs have now mapped. Tool descriptions are plain text that the model reads and the user rarely sees. Local servers run as processes with the developer's privileges. Remote servers use OAuth flows that early clients implemented carelessly. Servers are published to registries and npm with the review discipline of a weekend project, and clients auto-execute configuration found in repositories.
The attack classes
Tool poisoning hides instructions in a tool's description: the model, reading the description to decide how to call the tool, also reads the instruction to send the user's SSH key as a parameter. Rug pulls are the temporal version: a server behaves for fifteen releases and then changes its description or code, as postmark-mcp did when version 1.0.16 began copying every email to the developer. Tool shadowing lets one server redefine how the model uses another server's tools. Prompt injection through tool results is the indirect injection classic delivered over the protocol. Credential mishandling includes tokens passed through the model, confused-deputy patterns and OAuth implementations that accept attacker-controlled URLs. Server exposure is the ordinary web security failure: command injection, path traversal and SSRF in servers that were never meant to face the internet but do. And client vulnerabilities, from mcp-remote's command injection (CVE-2025-6514, CVSS 9.6) to Cursor's auto-execution of project MCP configuration (CVE-2025-54135), turn merely connecting into compromise.
What the record shows
Academic scans in 2025 and 2026 found that roughly one in ten public MCP servers had a mismatch between what their description claimed and what their code did, and that a majority had at least one security finding. Independent scanners of public servers reported command injection in a substantial fraction, and hundreds of thousands of MCP endpoints were exposed to the internet. The Cloud Security Alliance's July 2026 note found that project-defined MCP servers auto-executed with developer privileges across Cursor, Claude Code, Gemini CLI, GitHub Copilot and Amazon Q. Even the signature-based scanners have limits: independent tests found notable false positive rates, so a scan is a lead, not a verdict.
An admission process
Treat an MCP server the way you treat a dependency with network access and credentials, because that is what it is.
- Inventory. Find every server configured in clients across the estate; developers connect them without telling anyone. The telecom case study found 61.
- Source and provenance. Prefer servers published by the vendor of the underlying service, signed and versioned. Community servers need code review, not just a description read.
- Scan. Run MCP-Scan or equivalent on descriptions and pin them so that changes trigger re-review. Review the diff on every update.
- Scope credentials per server. A server gets its own token with the minimum scopes for its tools and nothing else; never reuse a developer's personal token across servers.
- Sandbox local servers. Run them under the same OS-level filesystem and network restrictions as the agent, with egress limited to the service they front. A local server with the developer's full privileges is a remote code execution waiting for a description to change.
- Never auto-execute configuration from repositories. Apply approved server configuration from a signed central source; treat mcp.json in a shared repository as untrusted input.
- Gate tools at runtime. A proxy or policy layer between client and servers that permits specific tools with specific argument patterns, blocks flows from sensitive sources to external sinks, and logs every call turns a static allowlist into a control.
- Keep clients patched and connect only to allowlisted remote servers over TLS.
- Monitor for the symptoms: unexpected recipients, unusual destinations, tools called outside their expected dialogue state, description changes.
Designing servers
If you publish MCP servers, the CRA's vulnerability handling duties and the OWASP MCP guidance set the bar. Validate every input as if it came from the internet. Do not put secrets in descriptions or return them in results. Keep descriptions free of instructions to the model beyond what the tool needs. Sign releases and publish through trusted publishing with short-lived tokens; the LiteLLM compromise showed what a long-lived publishing token in a CI secret store is worth. Provide a security contact and a disclosure policy.
The bigger picture
MCP is not uniquely insecure; it is uniquely convenient, which means it is where the supply chain and the agent meet with the fewest checks. The controls above are ordinary supply chain and endpoint security applied at a new interface. Do them, and the protocol becomes what it should be: a way to give an agent a scoped, observable capability rather than a way to give a stranger's code your credentials.
