Tool Poisoning: The MCP Attack Surface Nobody Reviews

Abhijit

Aug 10, 2026•9 min read

Tool Poisoning: The MCP Attack Surface Nobody Reviews

Agents read tool metadata that humans never look at. Peer-reviewed threat modelling puts that metadata at the centre of the most impactful client-side attacks on AI agents.

Verified as of 12 August 2026. Attack success rates cited below come from named academic benchmarks under specific conditions. They are measurements of those experiments, not universal properties of the systems involved.

The premise

When you connect an AI agent to a tool over the Model Context Protocol, the agent reads that tool's metadata - its name, its description, its parameter documentation - and uses it to decide when and how to call it.

That metadata is untrusted input. It is also almost never reviewed, because it is not written for humans and does not appear in any interface a human looks at.

This is tool poisoning, and threat modelling published in the peer-reviewed Journal of Cybersecurity and Privacy identifies it as the most prevalent and impactful client-side vulnerability in MCP implementations. The analysis applied STRIDE and DREAD across six components - MCP host, MCP client, the LLM itself, MCP server, external data stores, and the authorization server - and the metadata path is where it concentrates.

Why capable models are more exposed

The most counterintuitive finding in the literature is worth stating plainly.

A benchmark evaluating tool poisoning across 20 LLM agent configurations reported an attack success rate of 72.8% against o1-mini, and found that more capable models were often more susceptible. The mechanism is straightforward once stated: the attack works by embedding instructions in metadata, and a model that follows instructions well follows malicious ones well.

Capability and susceptibility are correlated here, not inversely related. Upgrading the model is not a mitigation.

A separate meta-analysis synthesising 78 studies published between 2021 and 2026 reports that attack success rates against state-of-the-art defences exceed 85% when adaptive attack strategies are used. Static defences perform considerably better in evaluation than against an adversary who adjusts.

Three protocol-level weaknesses

Preprint analysis of the MCP specification identifies problems that sit in the protocol design rather than in any one implementation:

1. No capability attestation. A server can claim arbitrary permissions. Nothing in the protocol requires it to prove entitlement to what it asks for.

2. Bidirectional sampling without origin authentication. This enables server-side prompt injection, because the client cannot reliably establish where a given instruction originated.

3. Implicit trust propagation across multiple servers. In a multi-server configuration, trust extended to one server effectively extends to others. The blast radius of a single compromised server is larger than an architecture diagram suggests.

These are structural. No amount of careful implementation on the client side fully compensates for a protocol that does not carry attestation.

What defenders are actually seeing

Microsoft's security team published analysis in June 2026 mapping observed attacks against enterprise agents to two categories in the agentic security taxonomy: tool misuse and agentic supply chain vulnerabilities. They note the underlying techniques were first disclosed by Invariant Labs in April 2025 and have since been observed against a growing range of production enterprise agents.

That is the pattern worth internalising: this moved from disclosure to in-the-wild exploitation across roughly a year, against real deployments.

Prompt injection more broadly sits at number one in the OWASP Top 10 for LLM Applications.

The unglamorous risk is bigger

An important counterweight, and one that security writing tends to underplay in favour of the more dramatic scenario.

For most teams standing up agents, the likeliest sources of actual harm are operational rather than adversarial:

No audit trail. You cannot reconstruct what the agent did or why.
No access differentiation. Every tool call runs with the same permissions regardless of sensitivity.
Borrowed agent identity. The agent acts as a service account with broad rights, so every action is attributed to the same principal and authorisation is coarse.

A sophisticated tool-poisoning attack is a real threat. An agent with unlogged access to a production database via a shared service account is a more probable incident, and it does not require an adversary at all.

Controls that limit blast radius

Ordered by how much protection they deliver per unit of effort:

1. Pin and review tool definitions. Treat a tool's metadata as code. Version it, diff it, review changes. A tool description that changes silently between sessions is the core of the attack.

2. Give each tool its own identity and least-privilege scope. Distinct credentials per tool, minimum necessary permissions. This converts total compromise into bounded compromise.

3. Log every tool invocation with arguments and outcome. Before an incident, this is compliance overhead. During one, it is the only thing that tells you what happened.

4. Require human approval for destructive or irreversible actions. Deletes, payments, external sends, permission changes. The approval gate is what stops an injected instruction from completing.

5. Isolate multi-server configurations. Given implicit trust propagation, do not co-locate a high-trust server with one that reads untrusted external content in the same agent context.

6. Treat all tool output as untrusted. Output returning to the model is another injection vector. Validate it rather than passing it straight back into context.

7. Do not rely on the model to defend itself. Given >85% adaptive attack success against state-of-the-art defences, model-level guardrails are one layer, not the layer.

Bottom line

MCP solved a genuine integration problem and did so well enough to become the default connective layer for agentic AI. What it does not carry is capability attestation, origin authentication, or trust isolation - and the ecosystem is deploying it faster than it is building those controls externally.

The metadata your agent reads is input. Review it like input.