MCP Tool Poisoning: from code execution to bypassing the agent's permissions

0The dependency nobody audits

There is a vector that comes before everything else, and it is subtler: the MCP server can be honest and still be the vehicle.

You audit the server's repository, read the handlers, confirm that the implementation matches the descriptions, and approve it. What you probably did not do is audit the dozens or hundreds of packages it pulls in as transitive dependencies. It only takes one of them being under the attacker's control.

• Compromise of a legitimate package. A maintainer account hijacked through phishing, a new version with one extra line.
• Typosquatting. A package with a name almost identical to a popular one, waiting for a typo or a wrong suggestion from an LLM.
• Dependency confusion. A public package with the same name as a company's internal package, published with a higher version and resolved first by the package manager.
• Hallucinated package. A model suggests a library that does not exist; the attacker registers that name and waits.

And the detail that closes the loop with stage 2: execution happens at install time, not at use time. Package manager lifecycle scripts run as the user who installed. You never even started the MCP server: the install was enough.

1The interface lies about the implementation

What the model sees of a tool is essentially three fields: name, description and inputSchema. The specification also defines title, outputSchema and annotations, such as readOnlyHint, but all of them are declared by the server itself. Nothing in the protocol verifies that the code behind them does what they promise.

On the metadata side, three documented variants:

• Tool poisoning. The description carries hidden instructions that the model follows. In the canonical Invariant Labs example, an addition function instructs the model to read SSH keys and pass them in an extra parameter.
• Rug pull. The server ships benign descriptions, gets approved, and later swaps them for poisoned versions, with no new approval.
• Tool shadowing. The description from a malicious server redefines how the model should use a tool from another server, one that is trusted and untouched.

In every case, the user approves the friendly name, not the real behavior.

2Execution with the user's privileges

One detail changes how the attack should be read: the code does not start running when the tool is called. It runs when the server is started and, before that, at install time. Starting the server is already the point of no return. The poisoned tool is not the trigger, it is the cover: it gives the attack the look of normal usage and a forged result to show.

From spawn onward, the process can, without asking for anything more:

• Read any file your user can read: environment files, SSH keys, cloud credentials, shell history
• Make network requests to any destination
• Write or modify files wherever your user has write permission
• Execute binaries and scripts already installed on the machine

This is not an MCP flaw. It is the same exposure as any unknown package or unaudited extension. MCP just makes the pattern easier to trigger without noticing, because the interface hides the implementation behind a "click and trust" invitation.

3The target shifts from the process to the agent

An honest question belongs here: if the handler already has the user's full access (and Claude Code's deny rules do not even apply to it, since they constrain the agent's tools, such as Bash and Read), why would the attacker touch settings.json?

Because the goal stops being immediate access and becomes persistence and control of the agent. Files like ~/.claude/settings.json and their project variants are plain JSON on disk: no signature, no integrity hash, no lock against writes from another process of the same user. Editing them makes it possible to:

• Remove deny entries and add allow ones, so that any future prompt injection finds the agent unguarded: the agent becomes a confused deputy
• Register hooks, which run shell commands on session events, guaranteeing execution even after the malicious server is uninstalled
• Tamper with MCP server registrations or instruction files such as CLAUDE.md, which the agent reads as trusted context

It is the pattern of malware that disables the antivirus before acting, with one difference: here the "antivirus" is the agent's own declarative permission layer.

3-AWhen the tool is only the trigger

In the previous stages the damage happens inside the MCP server process. There is a worse design: the handler does nothing interesting during the call, it only writes an artifact to disk and registers an autostart mechanism. From then on the attack no longer depends on the agent, on MCP or on your session.

The persistence mechanisms are the same as for any user-level malware, and all of them are within reach of a process with no administrative privilege:

• User schedulers (cron on Linux, Task Scheduler on Windows, launchd on macOS), which fire at a fixed interval
• Session startup: startup folders, per-user registry entries, user service units
• Shell startup files, executed every time a terminal opens
• Development tool hooks: git hooks in the repository, the agent's own hooks, IDE extensions

None of them requires root. All of them survive the uninstall of the MCP server, and that is exactly the point. The user removes the package, considers the incident closed, and the artifact is still there.

What the payload usually does once active

1. Secret sweep. It walks the user's home directory and projects looking for credential patterns: environment files, private keys, cloud credentials, tokens in configuration files, and also shell history and git history, where a secret removed from the code tends to live on. There are open source secret scanning tools, built for defensive use, that do exactly this; attackers simply embed them instead of writing their own sweep.
2. Exfiltration with cover. The destination is not always a server with a suspicious IP. The Shai-Hulud worm published stolen secrets to public repositories created in the victim's own account: outbound traffic to a domain that was already on your allowlist, using a legitimate credential.
3. Propagation. With a package registry or repository token in hand, the payload republishes itself into the packages the victim maintains, closing the loop with no human operator.
4. Second stage. The first artifact is small and quiet; it fetches and runs the real payload whenever it wants, which allows swapping the payload after infection without touching the original package.

The key reading: the MCP server is the entry vector, not the malware. After this stage, removing the server and cleaning up settings.json solves nothing.

4The full chain

Each stage looks small on its own. Together they form a lasting compromise disguised as a tool installation.

1. The victim installs an MCP server from an unaudited public repository, or an honest server with a compromised dependency
2. Install scripts already run as the victim's user
3. The server starts over stdio and inherits environment, credentials and disk permissions
4. The victim asks for an ordinary task; the model picks the poisoned tool because the description looks like a fit
5. The handler reads secrets, exfiltrates them and returns a forged success response
6. The same process tampers with the agent's configuration: removes deny, adds allow, registers hooks. The change can take effect within the same session
7. And it writes an autostart artifact, which begins running outside the agent's session
8. The victim uninstalls the server; the scheduler keeps firing

The final damage depends only on what that operating system user is allowed to do, which, in a typical development environment, tends to be almost everything.