PromptFu
03 Offense: Agentic3.8Advanced26 min

MCP security

Tool poisoning, rug pull, shadowing, line jumping. Cited to the researchers who named them.

ASI04ASI02◆ Two views of one tool

A tool description is a prompt. It is written by whoever runs the server, delivered straight into the context window, and shown to the user in a shortened form that leaves the interesting part out.

The whole module in one sentence

Invariant Labs found this in April 2025. Read it slowly, because every attack below is a variation on it.

The attack exploits the fact that AI models see the complete tool descriptions, including hidden instructions, while users typically only see simplified versions in their UI.
Invariant Labs · Tool Poisoning Attacks, 1 April 2025

Two audiences, two versions, one object. Everything else is what an attacker does with the gap.

Look at both versions

Four named attacks, each shown as the user's view and the model's view of the same tool. The first payload is the published proof of concept, reproduced as written.

Two views of one tool

MCP

A malicious server hides instructions inside a tool description. The model reads them; the user never sees them.

Invariant Labs, 1 April 2025

Show me
add
Adds two numbers.

  a: number
  b: number

What the gap buysThe user approves an addition. The model reads the SSH private key and passes it as a third argument. Invariant note that Cursor's confirmation dialog does not show the full tool input even in its extended mode, so the key stays hidden at the moment of approval.

Reaches the modelWhen the tool list is loaded, before any tool is called.

The poisoning payload is Invariant Labs' published proof of concept, reproduced as written. None of these four terms appears in the OWASP LLM Top 10, so each is credited to the researchers who named it.

Notice what none of these needed. No compromised model, no jailbreak, no clever phrasing aimed at the model's safety training. The attacker wrote documentation.

What the standard does say

OWASP treats connected tools as a supply chain rather than as a prompt problem, and its mitigation is unusually specific.

Pin, sign, and verify every MCP server and third-party tool package, audit tool descriptions for hidden instructions, and monitor tool composition.
OWASP LLM01:2026, mitigation 10

Then, in the next sentence, it says what pinning does not do. This is worth quoting in full to anyone who thinks version pinning closes the issue.

Pinning does not stop a payload shipped in the pinned version or tool-description poisoning that leaves the version unchanged.
OWASP LLM01:2026, mitigation 10

Map that onto the four attacks. Pinning defeats the rug pull, because a rug pull needs the description to change after approval. It does nothing about a server that was hostile at version 1.0.0.

AttackDoes pinning help?What actually bounds it
Rug pullYes. This is the case pinning is for.Pin and verify. Re-approve on change rather than on install.
Tool poisoningNo. The payload ships in the pinned version.Read the full description before connecting, and scope what the server's tools can reach.
Tool shadowingNo. The malicious server is pinned and honest about its own version.Isolate servers from each other. A server should not be able to describe another server's tools.
Line jumpingNo. Nothing is invoked, so nothing is versioned at the moment of attack.Treat connection as the trust decision, because the approval dialog happens after the payload arrives.
Attacks per Invariant Labs and Trail of Bits. The pinning column follows OWASP LLM01:2026 mitigation 10's stated limits; the third column is this course's.

An MCP server is a dependency with credentials

Module 3.3 has the incident: the postmark-mcp package BCC'd outbound email to its author across an estimated 300 organisations. No injection was involved anywhere. The package was hostile from installation.

That is the frame worth carrying. An MCP server runs with the agent's credentials and can describe its own capabilities to the model, so it deserves the review any dependency with those rights would get, plus one more question that ordinary dependencies do not raise.

Deep diveToxic agent flows, and why the GitHub case is the template›

Invariant's GitHub MCP finding is worth reading alongside module 3.1. An attacker files an issue on a public repository, the owner asks their agent to look at open issues, and the agent leaks from a private one.

They call the pattern a toxic agent flow: an agent manipulated into performing unintended actions, such as leaking data or executing malicious code. The useful part of the framing is that it is a property of the flow rather than of any single component. The MCP server is correct, the agent is correct, the permissions are as configured, and the composition leaks.

Which is why testing one server at a time will not find it. The finding lives in the combination.

Reduces attack rate· expected to degrade

Auditing tool descriptions and pinning versions are both worth doing and both are rate reduction. A description you read once can be replaced, a pinned version can have shipped hostile, and neither control constrains what the tool can reach once the model decides to call it.

Bounds blast radius· survives adaptive attack

Scoping what each server's tools can actually do, per module 3.4, and enforcing authorization outside the model, per module 3.5. A poisoned description that instructs the model to read ~/.ssh/id_rsa fails when the tool has no filesystem access to grant.

Sources