A developer opens their AI coding assistant and asks it to pull the latest project documentation. They have connected half a dozen MCP servers over the past few weeks — a filesystem tool, a GitHub integration, a Slack connector, a database bridge. The task executes. The documentation appears. Nothing looks wrong.

What they don’t know is that one of those MCP servers — installed two weeks earlier and approved without close review — contained a tool description with an embedded instruction. Alongside the documentation fetch, the agent silently extracted a set of environment variables and forwarded them through the Slack connector to an external channel. The agent did exactly what it was configured to do. It just wasn’t configured only by the developer.

This is not a hypothetical. In September 2025, the first confirmed malicious MCP server appeared on npm, functioning correctly through fifteen releases before a silent update began routing every processed email to an attacker’s address — passing authentication checks throughout because it used legitimate email infrastructure. The pattern was working before most of the industry knew what to look for.

Agents Don’t Distinguish Descriptions from Instructions

Model Context Protocol (MCP) is the integration standard that connects AI agents to external tools, data sources, and services. Anthropic released it in November 2024. Since then it has reached 97 million monthly SDK downloads and become the default architecture for connecting agents to the outside world across every major AI platform.

The architecture has three main components. The host is the application running the AI model — a code editor, Claude Desktop, an enterprise automation platform. The MCP client runs inside the host and maintains connections to one or more MCP servers. The servers are lightweight programs that expose capabilities to the agent: tools it can call, data it can read, prompts it can use.

When an agent connects to an MCP server, the server sends a list of tool definitions. Each definition includes the tool’s name, what parameters it accepts, and a description of what it does. The agent reads these definitions and uses them — in natural language — to decide whether and when to invoke a tool.

This is where the security model breaks down. In conventional software, what a program is permitted to do is enforced separately from what it says about itself. The description field in an MCP tool definition is not metadata. It is an input the model reads and reasons with, the same way it reads any other text in its context. There is no channel distinction between “this describes what the tool does” and “this is an instruction I should follow.” Whatever is written in that field enters the model’s context with the same weight as a legitimate system instruction.

Agents trust descriptions because they were designed to. The property that makes them useful — the ability to follow natural language instructions — is the same property the attack exploits. This is not a bug that will be patched. It is a consequence of the architecture.

Four Steps That Explain Every Tool Poisoning Attack

While tool poisoning attacks vary in sophistication and entry point, successful attacks follow a consistent technical lifecycle. Understanding each step maps defenses to specific failure points rather than treating tool poisoning as a single, undifferentiated risk.

1. The Connection

A user or administrator connects an MCP server — from an official registry, a third-party repository, or a custom deployment. At connection time, the server transmits its tool definitions to the agent host. The agent ingests them as part of its available context.

No verification happens at this step. The official MCP Registry authenticates namespace ownership — it confirms who published the server — but does not evaluate the content of tool descriptions. There is no equivalent of code signing that would attest that a description accurately represents what the tool does, or that it contains only functional metadata rather than embedded instructions.

2. The Description Enters Context

The agent reads the tool definitions, including the description field of each tool. This is the poisoning point. Any instruction written into that field is now part of what the model is reasoning with when it plans its next action.

The instruction doesn’t need to be conspicuous. It can be embedded in documentation-style prose, appended to otherwise legitimate descriptions, or written in a way that appears to be operational guidance. The model applies its language understanding to everything in context — it doesn’t separate “tool metadata” from “things I should act on.” The description field is unconstrained free text, and the model treats unconstrained free text as instruction.

3. The Agent Acts Using Its Own Credentials

The injected instruction executes. The agent calls a tool, sends data, modifies a resource, or shapes its own output — using the credentials and permissions it legitimately holds. No exploit code runs. No privilege is escalated. The agent does what it was told by the context it was given.

This is what makes attribution difficult. The resulting action appears in logs as a normal agent operation. The credentials are valid. The API calls are structured correctly. The action goes through the right channels. There is no anomaly in the access pattern because the access itself is legitimate — only the instruction that initiated it was not.

4. The Impact Compounds

The blast radius of a poisoned tool depends on what the agent can reach. Agents are typically connected to multiple MCP servers simultaneously, and the context of one server connection is not isolated from another. An instruction injected through one tool can influence how the agent reasons about and uses other tools in the same session. If the agent holds credentials for multiple systems — as agents designed for cross-system automation typically do — the impact of a single poisoned tool can extend across all of them.

A least-privilege deployment bounds this. An agent with narrowly scoped, short-lived tokens per task limits what any single injected instruction can accomplish. An agent provisioned with broad access for convenience does not.

The Entry Point Isn’t Always the Tool Description

The attack pattern above describes what happens when the tool description itself is poisoned. The more complete picture is that adversarial instructions can enter the agent’s context through several other paths, and defenders who focus only on installation are covering one of them.

Tool responses carry the same risk. When a tool executes, its output enters the agent’s context just as the description did. If the data source a tool reads is not fully controlled — an inbox, a customer database, a shared document store, a web page — an attacker who can write to that source can embed instructions in the tool’s output. The tool is legitimate. What it returns is not. The tool faithfully surfaces what it found; the model faithfully acts on the instructions embedded in it.

Tools can change after you’ve trusted them. When an agent connects to an MCP server, it reads the tool definitions at that moment. If the server later updates those definitions — or changes the underlying behavior of a tool — the agent has no mechanism to surface that change to the user. The approval decision was made at installation. Nothing re-examines what changed after that. The September 2025 npm incident followed precisely this sequence: many versions of correct behavior, then one that wasn’t, with no re-verification trigger between them.

Multiple servers create compounding exposure. MCP does not isolate context between server connections. In a multi-server deployment, a malicious server can register tools that overlap in name or apparent function with legitimate ones, influencing which tool the agent calls. Instructions injected through one server’s tools can influence the agent’s behavior when it uses other servers’ tools later in the same session.

The Protocol Was Designed This Way

This is not an implementation failure. The MCP specification explicitly states that it “does not enforce security at the protocol level,” delegating all security responsibility to each implementer. When the NSA published a dedicated security advisory on MCP in May 2026, it compared the protocol to early web standards — “flexible and underspecified, with security left as an afterthought for implementers.”

Authentication is the clearest illustration. It was not part of the original specification. It was added a year later, in November 2025, and only for remote servers. Local servers still inherit whatever OS-level permissions the host application carries. There is no protocol-level mechanism for re-verifying a tool after installation, no native sandboxing of tool descriptions, and no attestation that a server’s behavior matches what its descriptions claim.

OWASP’s benchmark data on MCP security reflects where this leaves real deployments: tool poisoning attacks succeed at a rate of 84% when auto-approval is enabled. Auto-approval is the default in most agentic deployments, because requiring human sign-off on every tool call defeats the purpose of automation. The 84% figure is not a measure of attacker sophistication. It is a measure of how the architecture performs when no additional controls are layered on top of it.

A January 2026 analysis of 847 attack scenarios across five MCP server implementations found that MCP amplifies attack success rates by 23 to 41 percent compared to equivalent non-MCP integrations. The amplification comes from the architecture itself: collecting tools from multiple servers into a shared context and routing the model’s decisions through natural language creates compounding exposure that doesn’t exist when each tool is integrated independently.

What You Can Actually Control

The protocol’s gaps don’t make MCP unusable. They make it a system where security requires deliberate construction rather than inherited guarantees.

Read tool definitions before connecting. The description field is the primary attack surface, and it is visible before installation. Reviewing what each tool says it does — the full description, not just the name — is the first control point. Instructions dressed as documentation are detectable by a human who is looking for them. Most people don’t look because they assume the description is metadata rather than something that will influence agent behavior.

Require human approval before irreversible actions. Automating routine operations is the point of agentic systems. Automating actions that send data externally, write to production systems, or modify credentials removes the last checkpoint where an anomalous instruction can be caught before it executes. The goal is not human approval for every tool call — it is human approval for actions whose consequences cannot be undone.

Treat tool responses as untrusted input. Any data a tool returns enters the agent’s context. If the data source is not fully under your control, the response should be treated with the same caution as any external input to an application. The injection risk doesn’t end at the tool definition.

Pin versions and track definition changes. A tool that looked safe at installation may not look the same today. Locking to specific server versions and reviewing definition changes before applying updates closes the gap the rug-pull pattern depends on. A change to a tool description should be reviewed the same way a code change would be.

Scope credentials narrowly. Agents should hold credentials only for the tools needed for a specific task, with tokens that expire when the task is complete. The OAuth 2.1 standard formalized for MCP in late 2025 supports resource-bound tokens that limit reuse across servers. The blast radius of any injected instruction is proportional to what the agent’s credentials can reach.

Consider a security gateway for production deployments. A growing category of tooling — MCP gateways and guardrail proxies — sits between the agent and MCP servers, enforcing input validation, intent-level authorization, and anomaly detection on tool calls before they execute. The NSA advisory specifically endorses this architectural pattern for deployments where agents operate on sensitive data or take consequential actions.

The Only Durable Defense Is Understanding the Trust Model

Tool poisoning has no user-visible symptom. The agent completes its task. Logs show valid operations with valid credentials. Nothing fails. If the injected instruction was designed to be subtle — forwarding data in the background, shaping outputs incrementally — the compromise may not surface until the impact is well established.

The underlying reason this attack class is difficult to defend against at runtime is the same reason LLMs are useful at design time: they follow natural language instructions from context. Distinguishing legitimate instructions from malicious ones embedded in tool metadata requires understanding that the attack class exists, reviewing the specific text that enters the agent’s context, and building controls at the layers the protocol leaves unaddressed.

The ecosystem is building toward better answers. OWASP published an MCP Top 10. Thirty-eight named attack categories have been documented in academic research. The NSA issued guidance. But 97 million monthly SDK downloads means the deployments are ahead of the defenses — the same position the web was in before it developed the security practices that now underpin it. The question for organizations deploying agents today is whether their controls are ahead of that curve, or waiting for it.

Sources

  1. NSA Artificial Intelligence Security Center, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, May 2026
  2. OWASP, OWASP MCP Top 10, 2025
  3. Maloyan & Namiot, Breaking the Protocol: Security Analysis of MCP Implementations, arxiv:2601.17549, January 2026
  4. MCP-38 Threat Taxonomy, arxiv:2603.18063, March 2026
  5. Invariant Labs, MCP Security Notification: Tool Poisoning Attacks, 2025
  6. Tenable Research, CVE-2025-49596: Remote Code Execution in MCP Inspector, 2025
  7. The Hacker News, First Malicious MCP Server Found on npm, September 2025