Your AI Agent's Backend Is Everyone's Backend

The Model Context Protocol connected AI to your internal tools. It also connected your internal tools to every vulnerability class from the last twenty years of application security, all at once.

Where We Left Off

In the last post, someone built a coding agent on Chipotle's customer support chatbot because the endpoint had no authentication. The blast radius was limited: stolen inference tokens, an inflated AI budget, and a very funny GitHub repository. Nobody accessed internal systems. Nobody exfiltrated data. The chatbot could answer questions and nothing else.

MCP servers are a different category of exposure. When an MCP server is misconfigured or left unauthenticated, the blast radius extends beyond compute theft into tool execution, file system access, database queries, and lateral movement across your infrastructure. The Chipotle problem costs money. The MCP problem costs everything.

What MCP Is and Why It Matters

The Model Context Protocol is an open standard, published by Anthropic, that allows AI agents to connect to external tools and data sources through a consistent interface. Instead of building custom integrations for every service an AI agent needs to access (your file system, your database, your project management tool, your cloud infrastructure), you run an MCP server that exposes those capabilities through a standardized protocol. The AI agent connects to the MCP server and can invoke tools, read resources, and receive context.

The value proposition is obvious. An AI agent connected to your Linear instance can file issues. Connected to your Slack workspace, it can read channels and send messages. Connected to your cloud environment, it can query infrastructure state and execute operations. The productivity gains are real, which is why adoption has been rapid: thousands of MCP servers now exist, maintained by everyone from Anthropic to individual developers publishing packages on npm.

The security problem is equally obvious once you say it out loud. An MCP server is an API that gives an AI agent the ability to execute actions on your systems. Every question you would ask about any other API applies: who can connect, what can they do, how do you know what they did, and what happens when someone connects who should not have.

The Numbers

The state of MCP security in mid-2026 is, to put it charitably, early.

OWASP published an MCP Top 10 in 2025. It is already in its third revision. The ten risk categories read like a greatest hits album of application security: token mismanagement and secret exposure, tool poisoning, command injection, path traversal, insufficient authentication. These are not novel attack techniques. They are the same vulnerability classes that have plagued web applications for two decades, showing up in a new protocol that adopted none of the defenses those decades produced.

The numbers from the research community confirm the pattern. A study of 2,614 MCP implementations found that 82% use file system operations prone to path traversal, 67% use APIs susceptible to code injection, and 34% are vulnerable to command injection. Between 38% and 41% of the 518 officially registered MCP servers offer no authentication at all.

In a 60-day window in early 2026, researchers disclosed over 30 CVEs affecting MCP implementations. One of them, CVE-2025-6514, was a CVSS 9.6 remote code execution vulnerability in the mcp-remote package. That package had been downloaded over 437,000 times before the disclosure. A systemic vulnerability was later found baked into Anthropic's own MCP SDK across Python, TypeScript, Java, and Rust, affecting over 7,000 publicly accessible servers and packages with a combined 150 million downloads.

Censys measured over 21,000 exposed MCP-related instances on the public internet as of January 2026. Some of those instances were clearly intended to be internal. A Flowise instance was found that exposed the entire business logic of an LLM chatbot service, including the underlying prompts and tool configurations. Attackers probing these exposed instances used JSON-RPC patterns to enumerate capabilities, read system files, and attempt to steal session tokens.

The Vulnerability Classes

Six vulnerability classes account for the majority of MCP security issues. None of them require novel exploitation techniques. They require only that an attacker find a server with no security review, which, given the numbers above, takes about as long as you would expect.

Tool poisoning. MCP servers expose tools with descriptions that tell the AI agent what each tool does. Those descriptions are consumed by the model as context. A malicious or compromised MCP server can provide tool descriptions that manipulate the model's behavior: instructing it to exfiltrate data, modify its own tool calls, or behave in ways the user did not intend. The model trusts the tool descriptions because the protocol provides no mechanism to verify them.

Prompt injection through tool responses. When an MCP tool returns results to the agent, those results become part of the model's context. A malicious tool response can embed instructions that alter the agent's behavior for subsequent actions. The agent reads a file, the file contains injected instructions, and the agent follows them because it cannot distinguish between legitimate content and injected prompts.

Command injection. MCP tools frequently execute system commands based on user input. When input sanitization is absent (which is often, given that many servers are single-developer projects published to npm), an attacker can inject shell commands through tool arguments. The classic pattern: a tool that takes a filename as input and passes it unsanitized to a shell command, allowing ; rm -rf / or its more strategic equivalents.

Path traversal. 82% of MCP implementations interact with the file system. When a tool accepts a file path as input and does not validate that the path stays within the intended directory, an attacker can read or write arbitrary files. The AI agent asks for a file, the tool serves /etc/passwd, and the agent dutifully returns the contents to whoever asked.

Hardcoded credentials. MCP servers frequently need credentials to access the services they expose: database passwords, API keys, OAuth tokens. A significant number of implementations store these credentials in configuration files, environment variables with no access controls, or directly in the source code. When the server is exposed to the internet (and thousands are), those credentials go with it.

Unauthenticated connections. The simplest and most prevalent issue. The MCP server accepts connections from any client without verifying identity. Anyone who can reach the endpoint can invoke any tool the server exposes with the full privileges of the server's configured credentials.

What Organizations Should Do

If your engineering teams are using MCP servers, or if AI agents in your environment are connecting to external tools through any protocol, the security posture requires the same rigor as any other API infrastructure. The controls are familiar.

Inventory what is running. MCP servers are easy to deploy and easy to forget. A developer can install an MCP server from npm, connect it to their IDE, and start using it in minutes. That server may have access to their file system, their git repositories, their cloud credentials, and their database. If your organization does not have visibility into which MCP servers are running, where they are running, and what they have access to, start there.

Authenticate every connection. No MCP server should accept anonymous connections. The protocol supports authentication; use it. At minimum, require token-based auth for every client connection. For servers that access sensitive systems, layer on mutual TLS or OAuth scopes that limit what each client can do.

Apply least privilege to tool permissions. An MCP server that connects to your database does not need to expose a tool that drops tables. Scope each tool to the minimum permissions required for its intended function. If a tool reads files, restrict it to a specific directory. If a tool queries a database, restrict it to read-only access on specific tables. The principle is the same one that has governed IAM policy for years; apply it here.

Validate tool inputs. Every argument passed to an MCP tool should be validated and sanitized before execution. File paths should be canonicalized and checked against an allow list. Command arguments should be parameterized, never interpolated into shell strings. User-provided content should never be passed directly to system calls. This is application security 101, and the fact that it needs to be stated in 2026 for a protocol backed by a major AI lab tells you everything about how fast adoption outpaced security.

Monitor and log. Every tool invocation should be logged with the caller identity, the tool name, the arguments, and the result. Anomalous patterns (a sudden spike in file reads, unexpected tool invocations, access to sensitive paths) should trigger alerts. The logging infrastructure you already have for your APIs works here; the data format is different, but the operational model is the same.

Vet third-party servers. The MCP ecosystem is largely community-maintained. Before connecting an MCP server to your infrastructure, review the source code, check the dependency tree, and evaluate the maintainer's security track record. A compromised MCP server has the same blast radius as a compromised dependency in your supply chain, because that is exactly what it is.

The Pattern

The story of MCP security in 2026 is not a story about a new kind of vulnerability. It is a story about an old kind of vulnerability in a new kind of packaging. Path traversal is not new. Command injection is not new. Hardcoded credentials and unauthenticated endpoints have been on every security checklist for as long as security checklists have existed.

What is new is the velocity of adoption and the breadth of access. MCP servers went from concept to 150 million downloads in under a year. Many of those servers were written by developers solving an immediate productivity problem, not by security engineers building production infrastructure. The incentive structure rewarded speed: get the agent connected, get the tool working, ship it. Security was deferred because the tool worked, and working is what people optimize for.

The parallel to the early days of web APIs is exact. REST endpoints proliferated before API gateways became standard. OAuth emerged because API keys kept leaking. Rate limiting became a requirement after the first few bills arrived. The controls that are standard for web APIs today were all reactions to incidents that are directly analogous to what is happening with MCP right now.

The question for security and GRC teams is whether to wait for the incidents or build the controls now. The OWASP MCP Top 10 exists. The CVEs are documented. The attack patterns are understood. The gap between what the protocol enables and what the ecosystem enforces is wide, visible, and closing slowly.

Close it faster.