What is MCP, and why is it a security problem?

What it is

The Model Context Protocol is an open standard for connecting AI assistants to tools and data. Anthropic published it in November 2024 and it has since been adopted across the industry, which is why it matters far beyond any one vendor.

The problem it solves is real and unglamorous. Before it, every combination of assistant and system needed its own integration. MCP replaces that with one protocol: a server exposes capabilities, a client consumes them, and anything speaking the protocol can talk to anything else.

The three parts

A server offers three kinds of thing. Tools are functions the model can call. Resources are data it can read. Prompts are templates a user can invoke. Tools are where nearly all of the security interest lies, because a tool is the point at which the model stops producing text and something happens.

1One approval per serverGranted once, on a summary a person reads

2The shared contextDescriptions from every server land in the same window

3A low-trust server beside a high-trust oneCross-server shadowing needs only a shared context

4A standing grantConfigured once, and it runs whenever the assistant runs

1. 1One approval per server Granted once, on a summary a person reads
2. 2The shared context Descriptions from every server land in the same window
3. 3A low-trust server beside a high-trust one Cross-server shadowing needs only a shared context
4. 4A standing grant Configured once, and it runs whenever the assistant runs

The security property nobody designed on purpose

Here is the part that matters, and it is not a bug in any implementation.

A tool is advertised to the model with a name, a description and a schema. The description is written by whoever wrote the server, it is read by the model, and it is never shown to the person who installed it. The model treats it as guidance about how and when to use the tool, which is exactly what it is for.

So the text that steers the model and the text that a human approves are two different things, and nothing in the protocol requires them to agree.

What is approved, and what is received

This is prompt injection with the payload delivered through the integration layer rather than through retrieved content. Everything in the prompt injection guide applies, and the delivery mechanism makes it worse in three specific ways.

Why a description can steer a model at all

It is worth being precise about the mechanism, because the usual objection is that a model should simply ignore instructions that arrive in the wrong place.

A tool description is not metadata to a language model. It arrives in the context as text, in the same window as the system prompt, the conversation and every tool result, with nothing structurally marking which parts carry authority. The model is being asked to decide when a tool is appropriate, and the description is the only material it has for that decision. Reading it carefully is the correct behaviour, not a failure of one.

That is why "use a better model" does not resolve this. A model that follows instructions more reliably follows whichever instruction it concludes is authoritative, and the attack consists of making the wrong text look authoritative. Capability and obedience improve together.

It is also why the defence has to be architectural. There is no wording of a system prompt that reliably tells a model to trust one string in its context and not another, when both arrived through channels the developer configured deliberately.

Three failure modes worth naming

Tool poisoning. Instructions are embedded in a tool description. The model reads them as part of deciding how to act. A malicious server sharing an agent context with a legitimate one can, in published demonstrations, cause data from the legitimate one to be read and exfiltrated. The user makes no mistake and there is no network-level exploit to detect.

Rug pulls. A server behaves correctly at installation, is approved, and then changes its tool definitions afterwards. MCP servers can update definitions without notifying the client, so the approval a person gave applies to text that no longer exists. This is the failure mode that makes "we reviewed it before installing" an insufficient control.

Cross-server shadowing. Tools from different servers share one context. A description on one server can influence how the model uses a tool on another, including one the user trusts more. The trust boundary a person imagines is per-server. The boundary the model actually experiences is the whole context.

The scale of it

MCP adoption ran considerably ahead of MCP security.

In April 2026 OX Security disclosed a systemic architectural flaw with an estimated 200,000 vulnerable instances, across a supply chain covering more than 150 million package downloads. The Cloud Security Alliance published a research note on the same theme. Neither describes a single vendor's mistake; both describe a pattern.

The 2026 specification update introduced incremental scope consent, which lets a client request the minimum access needed for a given operation rather than everything a server offers up front. That is a genuine improvement and it addresses the breadth of what is granted. It does not address the integrity of what is described, which is the harder half.

Why this is a supply chain problem

An MCP server is a package. It is installed from a registry, it runs with the user's privileges, and it is frequently maintained by one person.

The same questions you already ask about dependencies

Question	Why it bites harder here
Who publishes it, and is the name what you think	Tool squatting works on names, and a plausible name is most of the review most people perform
What version are you pinned to	Definitions can change server-side, so a pinned package does not pin the behaviour
What does it actually reach	A server runs with the privileges of the process that launched it, which is usually the user’s own
What happens when it updates	There is no notification requirement, and no diff for a person to read
Who else is in the context	Isolation is per-process, not per-trust-boundary. Other servers can influence yours

The uncomfortable part is that a reviewer reading the repository is reviewing code, while the thing that steers the model is a string. Both matter, and only one of them is habitually reviewed.

An MCP server is also, in most deployments, launched automatically. Nobody starts it deliberately each morning. It is configured once, it runs whenever the assistant runs, and it keeps whatever access it was given for as long as the configuration survives. That is a standing grant rather than a session, and standing grants are what turn a single successful injection into a durable foothold.

What actually reduces the exposure

Assume a tool description can be hostile, because you cannot verify that it is not. The question is what the agent is holding when it acts on one.

Local servers and remote servers behave very differently

The protocol supports more than one transport, and the choice changes the threat model more than most deployments realise.

A local server typically runs as a subprocess on the user's own machine, communicating over standard input and output. It inherits the privileges of whatever launched it. That is convenient and it is also the whole risk: a local server is a program running as the user, with whatever reach the user has, started by an assistant rather than by the person.

A remote server is reached over HTTP. It does not run on the user's machine, so it cannot read the filesystem, but it is now a third party holding whatever the assistant sends it, and authentication becomes a real question rather than an implicit one. The specification provides for OAuth here, and measurement work published in 2026 examining authentication in real-world remote servers found the practice considerably behind the specification.

Neither transport is safer in the abstract. Local trades third-party exposure for privilege. Remote trades privilege for third-party exposure. What matters is deciding which trade you have made, because organisations frequently install both kinds and reason about only one.

What to ask before allowing one

Four questions, asked before installation rather than after an incident, and none of which requires reading the source.

What is this server permitted to reach, in credentials rather than in description? Not "it reads files" but which files, as which identity. A server described as read-only that runs as the user can read everything the user can.

What happens when it updates? If the answer is that definitions are fetched at connect time and nobody is notified, then the review you are doing now has a shelf life measured in one session.

What else is in this context? List the other servers the assistant will have loaded at the same time. If a low-trust server sits beside a high-trust one, the boundary you are relying on does not exist.

What would appear in a log? If a poisoned description caused an exfiltration tomorrow, what artefact would show it. If the answer is the assistant's replies only, then tool calls are invisible and the incident is undetectable rather than merely undetected.

Those four answers describe the exposure. None of them is about the model, and none of them changes when the model is upgraded.

Where MCP genuinely helps security

It would be unbalanced to leave it there, because the protocol also improves on what it replaced.

Before MCP, each integration was bespoke, credentials were scattered across implementations, and there was no consistent place to apply a policy. A single protocol gives one place to enforce scope, one shape of audit log, and one thing to review rather than a dozen. The 2026 incremental consent work is only possible because there is a protocol to put it in.

The honest summary is that MCP centralises a problem that was previously diffuse. Centralised problems are more visible, more tractable and more dangerous while unaddressed, in that order.

Where to go next

The prompt injection guide covers the underlying mechanism, including why filtering cannot be the control you depend on, and the free pattern library catalogues the injection patterns with the defence beside each attack.

The AI agent guide is the other half of this: MCP is how an agent reaches things, and what it reaches is what decides the cost of it being wrong.