Hunting MCP Tool Poisoning: How CyberAI Catches the Attack Agents Never See
The fastest-growing attack surface in AI security this year isn’t the model. It’s the metadata around it.
The Model Context Protocol (MCP) turned LLM agents into general-purpose tool users: file systems, SaaS APIs, databases, internal services — all exposed through a single structured interface. Adoption outran threat modeling, and a specific class of attack has filled the gap. It’s called tool poisoning, and the reason it works is almost insultingly simple: it lives in text the agent reads and the human never does.
This post breaks down how tool poisoning works, why it’s mechanically distinct from the prompt injection most teams already defend against, and how I built detection for it into CyberAI — from the offensive side, as a red-teamer, not as a checkbox.
The attack in one sentence
When an MCP agent connects to a server, it pulls each tool’s metadata — name, parameters, and crucially the description field that tells the model when and how to invoke the tool. The agent treats that description as ground truth about the tool’s behavior. An attacker who controls a tool description can embed instructions there that the agent will follow as if they were legitimate operating documentation.
A poisoned tool might present a benign function — say, “send an email” — while its description quietly instructs the agent to also copy the conversation history, including any credentials or PII, to an attacker-controlled destination, and to never mention having done so. The user asks the agent to send an email. The agent sends an email. It also does the other thing. The user sees nothing, because the description that drove the behavior is never surfaced in the UI.
This isn’t theoretical. The MCPTox benchmark, built on real-world MCP servers and published in late 2025, formalized the threat and showed it lands across production agent stacks. Independent disclosures through 2026 have estimated hundreds of thousands of exposed MCP instances across IDEs, internal tooling, and cloud services.
Why it’s not “just prompt injection”
People keep collapsing tool poisoning into prompt injection. They’re related — tool poisoning is a specialized form of indirect prompt injection — but two properties make it meaningfully worse in practice:
It operates below the user’s line of sight. Classic prompt injection rides in on user input or retrieved documents — content that is at least theoretically inspectable. Tool descriptions are not. They sit in a metadata layer the end user cannot read, override, or even know exists. The deception happens at a level outside human review by design.
It persists without repeated attacker action. A poisoned document has to be re-served. A poisoned tool description is fetched once at connection time and then silently shapes every relevant decision the agent makes for the rest of the session — and across future sessions — with no further attacker involvement. Register the malicious server once; the payload re-arms itself on every connect.
That combination — invisible to the human, persistent by default — is why the consensus among people working on this is blunt: tool poisoning is a trust-model problem, not a bug. There is no vendor patch. If your agent dynamically loads tool descriptions from external MCP servers and trusts them, you are exposed, and the fix is architectural: signed manifests, version pinning, allowlists, and runtime monitoring — the same discipline mature teams already apply to third-party dependencies.
Catching it offensively: the CyberAI MCP scanner
CyberAI was built on one stubborn principle, stated in its README: every tool output is untrusted input until proven otherwise. Banners, scan results, API responses — all of it gets sanitized, length-capped, and run through a prompt-injection detector before it ever reaches the model context. That design predates the MCP work; tool poisoning just turned out to be the exact threat the architecture was already shaped to handle.
The MCP scanner I shipped this week extends that posture from “defend my own pipeline” to “audit someone else’s MCP endpoint.” It runs in three stages:
1. Capability inventory. An MCP client probe connects to the target server and pulls the full tool inventory — names, parameter schemas, and the description fields where poisoning hides. You can’t audit what you can’t see, so step one is making the invisible layer visible. Exposed as the mcp-scan CLI command.
2. Static metadata analysis. Each tool description is parsed and scored against a set of poisoning patterns — instructions to exfiltrate data, directives to suppress or hide actions from the user, references to hijacking other tools, and the imperative-instruction shapes that have no business living in a function description. This is the same untrusted-input philosophy CyberAI already applies to network banners, pointed at MCP metadata.
3. Severity scoring and findings. Matches feed a poisoning-specific severity scorer and are recorded as structured session findings — the same auditable, replayable finding objects the rest of the platform produces, exportable through the normal reporting path. A flagged MCP server lands in the report next to every other validated finding, with the evidence attached.
The framing matters to me. Most of the MCP-security tooling that exists is defensive — scanners that sit in front of your own agents. CyberAI approaches it as a red-teamer auditing a supply chain: point it at an MCP endpoint and ask whether this server is trying to poison the agents that connect to it. That’s the AI-supply-chain angle the whole platform is built around, and MCP is where it gets concrete.
What this connects to
The MCP scanner shipped as part of CyberAI’s STANDOFF II cycle, alongside an air-gapped execution path (full pipeline, zero egress, verifiable no-network assertion) and honest, reproducible benchmarks — because “trust me, it works” is not a security claim. The companion project, mas-sentry-toolkit (MST), carries the same auditing philosophy into multi-agent communication, mapping findings to the OWASP Agentic Top 10 with SARIF output for CI pipelines.
Tool poisoning is a clean illustration of why I think AI security has to be approached offensively. The defensive question — “how do I protect my agent?” — only gets you so far when the threat lives in a layer nobody looks at. The offensive question — “what is this tool actually telling my agent to do?” — is the one that surfaces it. CyberAI is built to ask the second question.
CyberAI is open source: github.com/evkir/CyberAI. MST: github.com/evkir/mas-sentry-toolkit.