MCP Servers: Tool Poisoning Is the New Supply Chain Attack

The Model Context Protocol (MCP) has become a standard way to connect AI agents to outside tools and data. That convenience also creates a new attack surface. Invariant Labs has disclosed a class of exploit it calls "Tool Poisoning Attacks." Separately, Snyk's Javier Garza is telling AI security engineers to treat MCP servers and skill registries the way the industry learned, painfully, to treat npm packages. Together, the two point to a security model that has not caught up with how quickly agents are being wired into real systems.

What Invariant Labs found

Invariant Labs describes a critical vulnerability in MCP that allows a malicious server to poison the tools an agent relies on 2. The firm says many prominent platforms are susceptible, including major model providers such as Anthropic and OpenAI, workflow automation services like Zapier, and MCP clients such as Cursor 2.

The researchers report three serious outcomes from their experiments [2]:

• A rogue server can exfiltrate sensitive user data.
• It can hijack the agent's behavior.
• It can override instructions supplied by other, trusted servers connected to the same agent.

The third point is the most alarming. Invariant Labs frames the result as a complete compromise of the agent's functionality, "even with respect to trusted infrastructure" 2.

In plain terms, adding one bad server to an agent's toolkit can contaminate everything else the agent touches. A team might carefully vet its internal servers, then plug in a single third-party integration. According to the research, that one integration could be enough to undermine the rest.

Why this looks like a supply chain problem

Garza's material, presented as part of an AI Security Engineer foundations course, places this risk in a familiar category: the software supply chain. His argument is that supply chain attacks have migrated from package managers like npm to model hubs and skill registries 1.

He singles out two vectors [1]:

Risk	Where it comes from	Garza's countermeasure
Poisoned third-party skill	Skill registries (Tessel is one example he gives)	Read the full text file before installing
Compromised MCP server	MCP registries and GitHub	Scan every server, and re-scan after updates

The advice is notably low-tech. Reading a skill's complete text file before installing it is a manual step 1. Developers rarely did that for npm dependencies, and they are unlikely to enjoy it for agent skills. The guidance on MCP servers asks for more: scan every server, and scan again whenever it updates 1. That second step matters. It implies that a server which passes inspection today could turn hostile in a later version, a pattern long familiar from compromised open-source packages.

Where the two perspectives meet and differ

The two sources come at the problem from different directions.

• Invariant Labs focuses on the protocol layer. It describes a vulnerability class that affects widely used clients and platforms, and it shows what an attacker can achieve once a malicious server is connected 2.
• Garza focuses on the operational layer. He is less concerned with how the exploit works than with how defenders keep poisoned components out in the first place, and how they keep checking them over time 1.

The two framings fit together. Invariant Labs explains why a single bad server is so dangerous. Garza explains how organizations might avoid installing one, and how to catch a previously safe one that changes.

There is also a gap between them. Garza's countermeasures are mostly about vetting and scanning. Invariant Labs' finding that a malicious server can override trusted ones points to a deeper design problem: agents may not adequately isolate one tool source from another 2. Scanning reduces the odds of letting a bad server in. It does not change what happens if one gets through anyway.

What it means for teams building agents

My reading is that MCP security should be treated as a supply chain discipline first and a protocol-hardening effort second. That order reflects what organizations can control today, not what matters most in the long run.

Most teams cannot redesign how Cursor or a major model provider handles tool instructions. They can decide which servers and skills reach their agents, and they can follow Garza's advice:

• Read the full contents of a skill before installing it.
• Scan every MCP server.
• Re-scan whenever a server updates 1.

The npm era showed that registries tend to fill faster than they can be policed. MCP registries and skill hubs seem to be on the same path, with higher stakes. A poisoned package runs code. A poisoned agent tool can steer an autonomous system that already holds credentials and data access 2.

Until client and platform vendors build stronger isolation between tool sources, every new MCP integration should be treated as untrusted code with the power to speak for the agent. On the evidence Invariant Labs presents, that is roughly what it is 2.