The MCP Threat Surface Nobody Is Modeling

The Model Context Protocol has spread faster than almost any enterprise integration standard in recent memory. MCP servers for every conceivable tool — file systems, ticketing, CI, observability, cloud providers, internal databases — have proliferated. They are useful enough that the adoption curve is going to continue.

They are also a threat surface that the security community has not fully mapped. The properties are novel in combination, and most of the threat modeling that exists treats MCP as a generic API wrapper. It is not.

What makes MCP distinct

An MCP server is, minimally, a process that exposes a set of tools to a model over a defined protocol. The model discovers the tools by asking, reads their descriptions, and invokes them with parameters the model chooses. The invocations happen inside an agent session, under whatever authority the session has, against whatever systems the server happens to be connected to.

Three properties together make this a distinct threat surface.

Tool descriptions are prompt-adjacent. The tool name, description, and parameter schema are read by the model and used to decide whether and how to invoke. An MCP server whose descriptions include crafted text can influence the model's behavior without ever being invoked, because the descriptions themselves are part of the prompt context.

The authority model is diffuse. The MCP server inherits authority from whatever it is configured with — API keys, service account credentials, network reachability. The agent session that uses the server inherits that authority transitively. A single compromised MCP server can extend an agent's effective authority across whatever systems the server was connected to.

The distribution model is permissive. MCP servers are installed, in many organizations, with the same casualness as browser extensions. A developer finds a useful server, installs it, and configures it against their credentials. The server runs with those credentials against the systems they have access to. Review of the server code — if any — is usually "I read the README."

Any one of these properties is manageable. The combination is a supply-chain problem with teeth.

The attacks you should expect

Description-layer prompt injection. A server that appears useful and works correctly for its stated purpose, but whose tool descriptions contain carefully crafted instructions that nudge the model toward other behaviors — calling a different tool, exfiltrating context, or deprioritizing a safety check. The model has no way to distinguish between a benign description and a malicious one.

Authority expansion through server chaining. An agent using multiple MCP servers from different sources has an effective authority that is the union of each server's capabilities. A compromised server in a chain can act on state established by a different server, crossing boundaries that neither server individually should have been able to cross.

Silent dependency updates. An MCP server distributed through a package ecosystem can update without meaningful review, changing its behavior, its tool descriptions, or the servers it talks to. The traditional supply-chain controls that apply to libraries apply here as well, but most organizations have not extended them to MCP installations.

What to actually require

A minimum viable posture for MCP:

• Treat every MCP server as a third-party dependency subject to your normal supply-chain review. No installations from sources your dependency policy would not allow.
• Pin versions. Require review of updates. Do not auto-update MCP servers into a running agent environment.
• Audit tool descriptions. Any text the model reads as part of its context is part of the prompt. A description that contains out-of-band instructions is a red flag, not a quirky implementation.
• Constrain authority per server. A server that only needs read access should not be configured with write credentials. A server that only needs to talk to one endpoint should not be configured with broader network access.
• Log tool invocations at the server boundary. Whatever logging the agent framework produces is not sufficient; the server-side log is the evidence you need when an incident happens.

None of this is exotic. It is the third-party-dependency playbook, applied to a new class of dependency that many organizations have not yet recognized as such.

The window

The time to establish MCP hygiene is before the first incident attributable to a compromised server. That incident is coming, for somebody. The teams that have treated MCP as an ordinary supply chain will respond to it as an ordinary supply-chain event. The teams that did not will respond to it as a novel crisis and spend months retrofitting controls that should have been in place from the start.