One Poisoned MCP Server Can Hijack All the Others

Cross-tool poisoning means your AI agent is only as secure as the worst MCP server you've connected. Here's the risk, and how to shrink it.

You wired six MCP servers into your team’s AI agent last quarter—GitHub, a database tool, a Slack connector, a web fetcher, an internal one, and something a developer found on a marketplace. Productivity went up. Nobody filed a ticket.

Then a security researcher showed you a proof-of-concept: the marketplace server’s tool description contained hidden instructions. When your agent loaded its tool list, those instructions told it to read your .env file and exfiltrate the contents—disguised as a normal outbound call through the Slack connector. The malicious server never touched the data itself. It hijacked a tool you already trusted.

This is cross-tool poisoning, and it’s the attack class quietly defining AI agent security in 2026. The uncomfortable takeaway for anyone buying or approving AI tooling: your agent is only as secure as the least-trustworthy MCP server connected to it.

What Cross-Tool Poisoning Actually Is

The Model Context Protocol (MCP) is how AI agents connect to external tools—GitHub, databases, your own services. Each server advertises its tools with a name, a description, and an input schema. The agent’s LLM reads all of that to decide what to call.

That description field is the attack surface.

Hidden Instructions in Tool Metadata

In a tool poisoning attack, the attacker embeds malicious instructions inside the tool’s metadata—the description or input schema—not the data it returns. Invariant Labs demonstrated this: a tool that looks like a harmless calculator carries a hidden directive instructing the agent to read sensitive files and pass their contents along as a parameter.

The human approving the tool sees “Adds two numbers.” The LLM sees the full description, including the buried <IMPORTANT> block telling it to read ~/.ssh/id_rsa first. Metadata isn’t shown in most agent UIs and is almost never reviewed, which makes this a less detectable form of prompt injection than the usual “ignore previous instructions” text.

How One Server Hijacks Another

Cross-tool poisoning is the dangerous escalation. A poisoned server doesn’t need permissions to your sensitive systems—it borrows them from servers you already trust.

Invariant’s WhatsApp proof-of-concept is the cleanest example: a malicious server’s tool description targeted a separate, legitimate whatsapp-mcp server connected to the same agent. The hidden instruction told the agent to read the user’s message history and send it to an attacker number, disguised as a normal outgoing message. The legitimate WhatsApp server did exactly what it was built to do. The poison came from a different server entirely.

Because every connected server shares the same agent context, a single bad actor can puppet the whole toolset.

The Sampling Vector Makes It Worse

Newer MCP features widen the gap. Palo Alto’s Unit 42 documented attacks through MCP sampling, where a server requests LLM completions back through the client. A malicious server can inject hidden prompts (burning your token budget on invisible output), persist instructions across an entire session, or covertly invoke tools like writeFile—all without the user seeing anything but the answer they asked for.

The root problem is the same in every case: MCP assumes the servers you connect are benign, and validates almost nothing.

Why This Is a Buyer Problem, Not Just a Developer One

It’s tempting to file this under “engineering will handle it.” The blast radius says otherwise.

Your Attack Surface Is Every Connected Server

When you approve an AI agent for your team, you’re not approving one tool. You’re approving the union of every MCP server anyone wires into it—and the permissions of all of them combined. One server reading a poisoned description can act through any other. The security of the system collapses to the security of its weakest connector.

The Supply Chain Nobody Audited

MCP servers spread the way npm packages did: a developer finds one, it works, it stays. Marketplaces accelerate this. Cisco analyzed 31,000 agent skills and found 26% contained at least one vulnerability, and reported attackers publishing over 1,200 malicious skills to a single marketplace to deploy credential stealers. Independent testing in 2026 found popular clients like Cursor highly susceptible to cross-tool poisoning, while a few, such as Claude Desktop, shipped stronger guardrails.

You almost certainly cannot name every MCP server connected to your agents today. That’s the problem in one sentence.

Exfiltration Is a Compliance Event

For a founder or engineering leader, the downside isn’t an abstract “vulnerability.” It’s customer data or source code leaving your environment through a channel you authorized, in a way your logs may record as normal activity. That’s a SOC 2 finding, a breach disclosure, a lost enterprise deal. The cost of one poisoned server dwarfs the convenience it bought.

How to Shrink the MCP Attack Surface

You can’t make MCP safe by inspecting harder—the whole point of the attack is that the dangerous part is hidden. You reduce risk structurally.

Connect Fewer Servers

Every server is a trust decision and a slice of attack surface. The agent that touches your codebase does not need a marketing-analytics connector in the same session. Keep the toolset minimal and purpose-scoped. Fewer servers, smaller blast radius.

Prefer Read-Only, Local, and Open-Source

Three properties dramatically lower the damage a poisoned server can do:

• Read-only. A server that can only read can’t write your files, push commits, or send messages on your behalf. It can’t be the exfiltration channel.
• Local. A server that runs on the developer’s machine against local data never ships your code or secrets to someone else’s cloud.
• Open-source. If the tool descriptions are in a public repo, hidden <IMPORTANT> blocks have nowhere to hide. You—or the community—can read exactly what the agent will be told.

Pin and Review What You Install

Treat MCP servers like dependencies, because they are. Pin versions so a server can’t silently change its tool descriptions after you’ve vetted it. Review the description and input schema, not just the README. Maintain a list of what’s connected, the same way you maintain a dependency manifest.

What Low-Risk MCP Looks Like in Practice

Coograph’s code graph is a deliberate example of the low-risk profile. Its MCP server answers structural questions about your codebase—what calls a function, what a change impacts—by querying a dependency graph built locally. It’s read-only (it returns context, it doesn’t write or send anything), it runs locally against a graph on your machine, and it’s MIT-licensed and open-source, so every tool description it exposes is public and auditable.

That doesn’t make it a security product, and it won’t stop a malicious server you connect alongside it. But it’s the shape of MCP server that minimizes what an attacker can do through it: nothing to write, nothing to exfiltrate, nothing hidden.

The broader principle holds regardless of vendor. When you add an MCP server to an agent that can see your code, ask three questions: Can it only read? Does it run locally? Can I see its source? Every “no” widens the blast radius of the next poisoned description that slips in.

If you’re approving AI agents for your team, start by listing every MCP server they connect to and which of them can write or send data. Then shrink that list. Get started with Coograph for a read-only, local code-context layer, and treat every other connector like the dependency it is.