How Prompt Injection Widens When MCP Tools Touch Live Systems

MCP connects AI models to live, writable external systems: file systems, code repositories, APIs, databases, communication platforms, IDEs. The data flow is straightforward and, in retrospect, alarming. User input travels to the AI model, which has weak input validation by design; from there to an MCP client, which frequently has none; and from there to MCP servers and whatever external systems those servers can reach.

The foundational misunderstanding most teams carry into MCP deployments is that tool descriptions are documentation. They are not. They are executable context, loaded into the model's reasoning on every tool invocation, and the model cannot distinguish an instruction authored by its legitimate owner from one inserted into tool metadata by a third party. It processes both. It acts on both.

Trust in MCP is granted at the server level and inherited by every tool that server exposes. There is no per-tool permission boundary in the base protocol. Approving a server means approving everything on it, and everything that server can reach. That is a design choice, not an oversight, and it compounds every other problem in this stack.

IDC projects active AI agents in enterprise environments to grow from tens of millions today to billions by 2030. Vulnerability research on deployed MCP servers found that more than one in three had at least one exploitable vulnerability, a base rate higher than most enterprise software categories at equivalent deployment scale. The attack surface is expanding faster than the governance is maturing.

How Tool Descriptions Become the Attack Surface Before a Single Tool Is Called

When an agent connects to an MCP server, it issues a tools/list command. The server returns names and descriptions. Those descriptions load directly into the model's context window, and any malicious content embedded there is processed as a legitimate instruction before any tool is actually invoked. The attack precedes the action.

This is the tool-poisoning attack class, sometimes called "line jumping." A malicious MCP server embeds hidden instructions inside a tool description, and the model reads them as authoritative context because it has no mechanism for classification.

The "rug pull" variant defeats the approval workflow most clients rely on. A server ships a benign tool description at install time; the user approves it; on a subsequent connection, the description mutates. The client, which only prompted on first approval, never re-alerts. The MCP specification's June 2025 revision added tools/list_changed notifications to enable detection of these mutations, but enforcement is client-side and inconsistent across implementations. The notification exists. Acting on it is optional.

MCPoison and CurXecute, formally documented as CVE-2025-54136 and CVE-2025-54135 respectively, defined this attack class with reproducible exploitation paths. These are not thought experiments; they are catalogued vulnerabilities with working proofs of concept. The practical implication is direct: changes to tool metadata must receive the same scrutiny as changes to a system prompt or a production deployment configuration. Currently, almost none do.

Why Indirect Injection Is Harder to Catch Than Direct Injection and How It Travels Through MCP

Direct prompt injection arrives in the user's own input. Indirect injection lives in external content the model retrieves and processes on the user's behalf. The user never sees the malicious instruction. The attacker never needs to interact with the system directly.

Every MCP tool call returns text that gets appended to the model's context window, which makes every MCP server a push channel for indirect injection. The range of content types that can carry payloads in a typical MCP-connected environment is not small: GitHub issues and pull request comments, SharePoint files, Confluence pages, PDF attachments, email threads, Slack messages, support tickets, database records, CRM entries, scraped web content. If the agent can read it, it can be weaponized.

Invariant Labs demonstrated this with a GitHub indirect injection incident. A malicious issue in a public repository, when read by a Claude Desktop user asking the agent to review recent issues, contained hidden instructions that redirected the agent's behavior. The user's legitimate session became the delivery mechanism. The attacker needed only to write a GitHub issue, which is not a high bar.

EchoLeak, documented as CVE-2025-32711 with a critical CVSS rating, illustrated the same pattern at enterprise scale in a Microsoft 365 Copilot architecture. A single crafted email, requiring no user interaction, coerced Copilot into accessing internal files and transmitting content to an attacker-controlled server. The cascade moved through chat logs, OneDrive files, SharePoint content, and Teams messages. Zero clicks. That is the published, documented endpoint of indirect injection in an MCP-adjacent architecture: autonomous data exfiltration at scale from a single email.

How Injection Payloads Cross From One Server's Scope Into Another's Privileged Tools

Multi-server architectures are the normal production configuration. An agent connects to several MCP servers simultaneously and can invoke tools across all of them within a single session. The agent maintains no verified chain of custody for instructions; it cannot confirm that a directive to invoke a high-privilege tool originated from its authorized owner rather than from injected content on a compromised, lower-privilege server.

A poisoned low-privilege server can therefore instruct the agent to invoke tools on a legitimate high-privilege server that the attacker cannot directly reach. The agent serves as the bridge. The attacker never touches the privileged system.

Palo Alto Networks Unit42 identified three vectors this enables: resource theft through abuse of MCP sampling to drain AI compute allocations for unauthorized workloads; conversation hijacking through persistent instructions injected across turns; and covert tool invocation, including hidden file system operations executed without user awareness.

The Supabase Cursor incident in June 2025 demonstrated the worst-case profile of this attack surface: privileged access granted at the server level, untrusted input processed as part of a routine workflow, and an external communication channel available to any third party. Academic testing of live MCP servers found attack success rates that remained high even against agents with nominal guardrails, refusal rates in the low single digits in some configurations. Obfuscation compounds this further: payloads can encode intent in Base64, distribute instructions across multiple conversation turns, or exploit image-URL patterns where a markdown image tag causes the client to issue an HTTP fetch that exfiltrates data in the URL parameter. The delivery mechanism variety is not diminishing.

Where the Vulnerability Lives in the MCP Infrastructure Itself, Not Just in Agent Behavior

It would be convenient if the problem were localized to agent behavior, because behavior is something you can constrain with guardrails and system prompts. The infrastructure vulnerabilities are less accommodating.

Endor Labs' analysis of MCP implementations found that the majority use file operations prone to path traversal, many use APIs related to code injection, and a significant portion use APIs susceptible to command injection. These are not edge cases; they are categories distributed across the underlying implementations at a scale that makes them a structural property of the ecosystem rather than isolated lapses.

CVE-2025-6514, an OS command-injection bug in mcp-remote, a widely-downloaded OAuth proxy for connecting local MCP clients to remote servers, allowed malicious servers to send a crafted authorization endpoint and achieve remote code execution. The attack surface extended to the connection layer before any tool was ever called.

Anthropic's own mcp-server-git reference implementation carried chained vulnerabilities: a path validation bypass, an unrestricted gitinit capable of converting an.ssh directory into a git repository, and argument injection in gitdiff. Combined with the Filesystem MCP server, these achieve full remote code execution via malicious.git/config files. These are reference implementations, the ones teams clone as starting points for their own servers. The baseline was compromised before anyone wrote a line of custom code.

CVE-2025-49596 extended the attack surface to the developer toolchain itself. The NSA's advisory flagged remote code execution via crafted messages in MCP-Inspector, the tool used to test MCP servers during development. Teams that locked down production and left development tooling unexamined did not actually contain the problem; they just moved the perimeter somewhere they forgot to look.

The Vulnerable MCP Project, maintained by researchers from SentinelOne, Snyk, Trail of Bits, and CyberArk, tracks a growing catalog of known MCP vulnerabilities across servers, clients, and infrastructure, with a significant share rated critical and new CVE disclosures continuing through mid-2026. A 2026 disclosure exposed a large number of vulnerable MCP instances spanning IDEs, internal tools, and cloud services. The scale is systemic, not incidental.

Why Enterprise Governance Hasn't Caught Up to How MCP Is Actually Being Deployed

Shadow MCP is the 2026 equivalent of Shadow AI: employees connecting unauthorized MCP servers to their AI tools without security review, inventory, or visibility. The approval model most clients use, prompting once at install and never re-prompting on tool metadata changes, means rug-pull attacks are invisible to governance workflows that depend on that prompt. In every organization I've examined, the install-time prompt is the governance workflow. It is also the one mechanism the rug-pull attack bypasses by design.

Privilege is granted at the server level, and every tool on an approved server inherits that access regardless of what individual tools actually need. Every agentic system I've reviewed in production is deployed without per-tool permission scoping, behavioral baselines, or outbound network allowlists. The tools run with whatever access the server was granted, which is often broad because broad access was convenient at setup time, and convenience at setup time becomes exposure at incident time.

The MCP architecture blends instructions with data in a way that makes metadata changes functionally equivalent to system prompt changes in terms of their effect on agent behavior. A change to a tool description redirects the agent as effectively as a change to the system prompt. Metadata changes rarely receive the same change-management scrutiny that system prompt changes receive, and system prompt changes rarely receive enough scrutiny either.

Inter-agent messages in multi-agent pipelines represent an injection surface that every enterprise security team I've spoken with has not yet mapped. Traditional input sanitization is insufficient: malicious intent can be expressed through natural language variations, implicit context, and multi-turn instruction sequences that cannot be comprehensively anticipated and filtered at the boundary.

What a Defensible MCP Deployment Actually Requires Across the Stack

Defense starts with accepting that the validation surface is larger than the user prompt. Every data source the agent touches is a potential injection vector: user prompts, RAG corpora and document stores, tool responses and API payloads, email and document contents before summarization, MCP tool descriptions and metadata on every connection rather than only at install, and inter-agent messages in multi-agent pipelines. Each is a distinct injection pathway and requires a distinct control.

Least-privilege tooling is not optional at this point. Scope permissions to the minimum a given tool actually requires: read-only access where write access is not needed, single-repository access where broad file system access is not needed. The gap between the access a tool has and the access it needs for legitimate use is exactly the gap an attacker operates in, and it is wide.

Human approval as a gate for write and delete operations is the single control that prevents the widest category of serious outcomes. Any action that modifies external state should require a human confirmation step before execution. This is the difference between injection that produces a bad output and injection that deletes a database table, and those two outcomes are not equivalent.

Outbound network allowlists address the exfiltration problem directly. Most agentic systems have no legitimate need to contact arbitrary internet destinations; restricting egress to known required domains eliminates most exfiltration scenarios, including the image-URL exfil pattern, as a side effect of enforcing a policy that should already exist for unrelated reasons.

Rate limiting and behavioral baselining round out the runtime layer. Per-user and per-tool limits on API calls, tokens processed, and data volumes constrain the blast radius when an injection succeeds. Baselines for typical tool call sequences and access times, with alerting on deviation, catch the anomalous activity that injection-driven agent behavior produces before it runs to completion.

Tool metadata must be treated like production code: versioned, reviewed, and monitored for mutation. The rug-pull attack class exists precisely because metadata changes are not treated this way. Some gateway tools can apply outbound allowlists, rate limits, and logging for tool call traffic by sitting between agents and external endpoints, enforcing these controls at the infrastructure layer rather than inside application code.

OWASP's defense-in-depth framing for this problem is correct: no single control solves prompt injection. The right posture combines least-privilege tooling, input and output filtering, human approval gates for high-risk actions, and regular adversarial testing, because each control addresses a different injection pathway and the pathways are numerous.

What defense cannot do is eliminate the root condition. OpenAI acknowledged in late 2025 that prompt injection is unlikely to ever be fully solved, because blending trusted and untrusted inputs in the same context window is an architectural condition, not a patchable bug. Every control described here is about containing the blast radius when injection succeeds. And it will succeed. Building an MCP deployment on the assumption that it won't is precisely how organizations end up in incident reports.