The MCP Threat Model: Where Trust Actually Breaks Down
MCP did not ship a bug that can be patched. It made a design trade — tool selection mediated by natural language — and the security properties follow from the trade.
What MCP actually changed
The Model Context Protocol, introduced in November 2024, became the standard way to connect language model agents to external tools and data. Adoption was fast: by early 2026 more than 18,000 servers were listed on public directories, and every major agent platform read the protocol natively.
The security picture caught up shortly afterwards, and it caught up hard. Between January and February 2026 researchers filed more than thirty CVEs against MCP servers, clients and supporting infrastructure. In June 2026 a US Department of Defense cybersecurity information sheet on MCP security design was published. The Cloud Security Alliance issued best-practice guidance. Peer -reviewed threat taxonomies followed.
That is an unusual amount of institutional attention for a two-year-old protocol, and it is worth understanding why — because the answer is not "the implementations were sloppy". It is architectural.
The mechanism at the root of it
In a conventional integration, which function gets called is decided by code. A developer writes the call, a compiler or interpreter executes it, and the set of reachable behaviours is fixed at build time.
In MCP, tool selection and invocation are mediated by free-form natural language descriptions, interpreted at inference time by a model. The agent reads a description of what each tool does and decides which to call.
That single design choice is what generates the threat model. It follows that anyone who controls text the model reads can influence which tools get called and with what arguments — without touching application code, without exploiting a memory-safety bug, without any traditional vulnerability at all.
Text is now a control channel. A tool description, an uploaded document, an API response, a code comment, a filename — anything the model reads can carry instructions. Traditional application security controls assume data and control are separate. Here they are not.
Three protocol-level weaknesses
Security analysis of the specification has identified three flaws that sit in the protocol design rather than in any particular implementation.
Absent capability attestation
Nothing in the protocol lets a client verify that a server's declared capabilities match what it actually does. A server advertising itself as a read-only weather lookup may, on invocation, do something else entirely. The description is a claim, and the protocol provides no mechanism to check it.
The practical consequence: installing an MCP server is equivalent to running untrusted code with whatever access you grant the agent. That is worth restating, because the installation experience — a line in a config file — is far lighter than the trust decision being made.
Unauthenticated sampling
The sampling capability lets a server ask the client to run a model completion. Where this is not properly authenticated and constrained, a server gains the ability to drive model inference on the client's account, and to shape the content of those completions. Published analysis has documented attack vectors specifically through this path.
Implicit trust propagation
Once content enters the agent's context, its origin stops mattering. A string returned by a low-trust server sits alongside your source code and your instructions in the same window, with no marking to distinguish them. The model has no reliable way to weigh "this came from a tool I do not trust" against "this came from the user".
Why the attack surface is bigger than the sum of the parts
One quantitative finding is worth flagging: comparative analysis has measured MCP-based integrations amplifying attack success rates by roughly 23–41% relative to equivalent non-MCP integrations.
The amplification comes from composition. A single tool with a narrow scope is a small target. Fifteen tools, where the output of one becomes context for the next, is a much larger one — because an attacker who can influence any single link can steer everything downstream. The protocol makes composition easy, which is its value, and composition is also what widens the surface.
Four questions to ask of your own setup
Threat models are only useful when they translate into questions about the system in front of you.
| Question | What a bad answer looks like |
|---|---|
| Which servers are connected, and who wrote each? | "I'm not sure, I added a few months ago" |
| What can the agent reach through them? | Production databases, deployment, outbound network, all at once |
| What untrusted text enters the context? | Issue bodies, web pages, third-party API responses, PR descriptions |
| What happens if a tool returns hostile output? | Nothing in particular; it is treated like any other text |
The third question is the one that most often produces an uncomfortable silence. Teams tend to think carefully about which servers they install and not at all about what those servers return.
Why traditional controls do not transfer
Published analysis makes a point worth dwelling on: the attack surfaces here are ones traditional application security controls are insufficient to address. That is a strong claim, and it holds up when you check it control by control.
| Control | Assumes | Why it under-delivers here |
|---|---|---|
| Input validation | Malicious input is syntactically distinguishable | The payload is ordinary grammatical English |
| Least privilege | A caller's identity determines its rights | The agent legitimately holds the rights; the question is who steered it |
| Sandboxing | Containing execution contains the damage | Damage flows through authorised API calls, not code execution |
| Code review | Behaviour is determined by reviewed code | Behaviour is determined at inference time by text nobody reviewed |
| WAF and signature rules | Attacks have recognisable patterns | No stable signature; the payload is natural language |
None of these are useless — least privilege in particular still does real work by shrinking what a compromised session can reach. The point is that each was designed against a threat model where the attacker must get code or malformed data past a boundary. Here the attacker supplies well-formed text through a channel designed to carry text, and the system does exactly what it was built to do with it.
Where the boundary actually is
The useful way to place the trust boundary: everything inside the model's context window is one trust domain. Your instructions, your code, tool descriptions, tool results, fetched web pages — all of it is in the same bucket, and the model cannot reliably partition it.
That framing produces better decisions than trying to reason about individual tools. If everything in the window is equally trusted, then the questions worth asking are about what gets in and what the agent can do once it is there:
- What content can reach the window, and can any of it be attacker-influenced?
- What actions are reachable from the window, and which are irreversible?
- Which actions require a human decision regardless of what the context says?
The rest of this pillar works through those questions in detail. The foundation is this: MCP did not introduce a bug that can be patched. It made a design trade — flexible, model-mediated tool selection — and the security properties follow from the trade. Controls have to be built around it rather than expected from it.
Tool selection driven by natural language means any text the model reads is a potential control channel. Three protocol-level gaps — no capability attestation, weakly authenticated sampling, implicit trust propagation — mean you cannot verify what a server does, and cannot distinguish its output from your own instructions once it lands. Treat the entire context window as a single trust domain and design your controls at its edges.