How Prompt Injection Widens When MCP Tools Touch Live Systems

An AI model that only reads and writes text can be tricked into saying something false. An AI agent that reads and acts can be tricked into doing something real: deleting a database, wiring a credential, approving an invoice. That is the entire story of what the Model Context Protocol changed, and it is why prompt injection, a problem security teams had mostly filed under "annoying but contained," now sits closer to the top of the pile marked "actually dangerous." This piece traces where in the MCP pipeline that danger enters, what it does once it reaches a system with write access, and why the tools most companies already have won't see it happen.

MCP's read-to-act shift and prompt injection

MCP is a standard way to connect an AI model to outside tools, files, databases, APIs, cloud command lines, all through one interface, released by Anthropic in November 2024. Once a model can act on what it reads instead of merely describing it, prompt injection turns into a question of who authorized that action, not what the output says.

Before MCP, the worst a poisoned prompt could do was bend the shape of an answer. A language model took in text and handed back text, so a hostile instruction buried in that text could distort a summary or leak a detail it shouldn't have, but it had no hands. It could not call an API on its own, write a row to a database, or run a shell command. Microsoft's June 2026 security guidance draws the line cleanly: injected text against a summarizer biases an output, while injected text against an agent triggers an action. MCP is the thing that gave the model hands in the first place, a universal connector reaching into files, databases, APIs, and cloud CLIs through one standard interface.

The structural flaw sits underneath the feature list. Every scrap of text a large language model sees, the system prompt, the user's message, a retrieved document, a tool description, a tool's output, is in the same context window, and nothing in that window marks which lines came from a developer and which came from a stranger's comment on GitHub, Agent Governance Review found. MCP makes that problem worse by adding two entry points that plain API calls never had: tool descriptions, which the model reads before deciding what to call, and tool outputs, the data that comes back once something runs. It treats both with the same trust it gives a developer's own system prompt. Nothing in the MCP specification requires a client to check, clean, or cryptographically verify a tool description before handing it to the model.

This stopped being a corner case the moment every major platform adopted it. OpenAI, Google, Microsoft, and Salesforce all shipped MCP support within roughly a year of its release, and in December 2025 Anthropic handed the protocol over to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. The protocol belongs to the industry now, not to one vendor's roadmap. The tool-call pipeline has settled into the role REST APIs held a decade ago, ordinary infrastructure everyone builds on, and that means its weaknesses belong to everyone who built on it.

The MCP request lifecycle's four injection entry points

A request moving through MCP crosses four separate trust boundaries, not one, and at every single stage the model is reading external text it has no reliable way to label as safe or hostile.

The first stage runs from user input into the planning step, and it is the most direct route in. An attacker drops a crafted line into that input layer, it feeds straight into the model's planning process, and it can change which tool gets picked and what arguments get handed to it. A message that reads like an ordinary request might carry a buried line telling the agent to go fetch a credentials file instead of doing the task it was asked to do. Nobody checks the model's reasoning before it acts, because the planning step runs as a black box with no human checkpoint reviewing which tool got chosen or why, and MCP itself demands no runtime confirmation that a tool call actually matches what the user wanted.

The second stage is tool description discovery, and this is where tool poisoning lives. Before the model calls anything, it reads the description text the server hands it, and that text is the entire basis on which it decides when and how to use a tool. A server under an attacker's control can bury arbitrary commands inside what reads like ordinary help text, and the model will carry them out exactly as written: a description that claims to "add two numbers" is, at the protocol level, indistinguishable from one that adds two numbers and also quietly attaches the contents of a private SSH key as an extra parameter.

The third stage is content retrieval, the classic indirect injection route. An attacker never has to touch the input stream at all; planting instructions inside content the agent was already scheduled to read, a web page, a PDF, a code comment, a README, a database record, a support ticket, a GitHub issue, does the job just as well. Agent Governance Review documents a 2025 incident where a malicious GitHub issue hijacked an agent wired into a private repository, and the attacker never touched a single tool; the instructions rode in as plain text inside the issue body, content the agent was supposed to process as routine work, and OWASP now cites the case as a standard example of agentic supply-chain risk. An April 2026 case went further still: instructions hidden in pull-request titles, issue bodies, and invisible HTML comments convinced Claude Code, Gemini CLI, and GitHub Copilot to pull GitHub Actions secrets and send them out through PR comments, issue comments, and GitHub API calls respectively.

The fourth stage is tool output re-entry. Once a tool runs, its result does not just sit off to the side as inert data, waiting for the calling code to parse it. It folds back into the same prompt stream the agent reads for instructions, so if a tool result is crafted carefully enough, it can redirect everything the agent does from that point forward. If an attacker controls a data source the agent regularly queries, they need no path to the model itself.

Write-capable tools: privilege escalation and confused-deputy attacks

If injection reaches a write-capable tool, what it can cost an organization changes. The cost shifts from a leaked document to an agent using its own legitimate credentials to act on systems the attacker could never have touched on their own.

The Cloud Security Alliance's research found that Claude Code, Cursor CLI, Gemini CLI, GitHub Copilot CLI, and Amazon Q all auto-execute project-defined MCP server processes the moment a user accepts a folder trust prompt. Those spawned processes inherited the full developer environment around them, AWS access keys, cloud CLI tokens, SSH agent sockets included, so a successful exploit handed over immediate access to cloud infrastructure without the attacker needing to steal a single additional credential. MCPoison, tracked as CVE-2025-54136, showed that a single committed configuration file could compromise an entire team at once, and across real-world MCP server benchmarks, tool poisoning succeeded an average of 36.5% of the time against major LLM agents, with some popular models like o1-mini and DeepSeek-R1 succeeding in more than three-fifths of attempts.

The confused-deputy problem is the quieter sibling of privilege escalation, and it is harder to catch precisely because nothing looks broken. It occurs when one MCP server, say a third-party data tool, manipulates the agent into using credentials or capabilities that belong to a second MCP server, an internal codebase tool, in a way the second server's owner never agreed to. The agent legitimately holds valid tokens for both servers. An injected instruction sitting in the first server's output simply tells the agent to call a file-write tool over on the second server, and the agent does it, because it holds the token and has no reason built into it to ask whether it should. The official MCP security guidance, as summarized in ITECS's 2026 analysis, names token-passthrough as one of five explicit risk categories alongside confused-deputy attacks, SSRF, session risks, and local-server risks.

Microsoft's own finance workflow analysis gives the clearest picture of what this looks like inside a real enterprise stack. The June 2026 trace follows an attack against a Copilot Studio agent wired into a Dataverse MCP server, an Outlook connector, and a third-party invoice enrichment MCP server. A developer pushed a routine-looking update to the enrichment server. The tool's name and the summary shown to users stayed the same, but buried inside what looked like ordinary formatting guidance sat a block of instructions telling the agent to pull the last thirty unpaid invoices, summarize them, and attach that summary as an extra parameter on the enrichment call, dressed up as a fraud-detection requirement. The enrichment server had already cleared production approval, and the dynamic metadata update model gave description-level changes no separate security review, so the altered instructions went live the moment the update shipped.

Tenet Security's research into the Sentry MCP adds a cleaner, smaller-scale example of the same pattern. It found injectable DSNs across thousands of organizations and measured a high rate of agent execution in testing, and as of the July 2026 protocol revision the issue still had not been fixed: Sentry declined a structural remediation at the time of disclosure and shipped a payload-string filter instead.

Why EDR, output filtering, and detection logic fail against these attacks

Most of the security tooling organizations already run was built to watch processes, files, and network calls, not the inside of a model's reasoning, and that mismatch is the whole reason this attack class keeps getting through.

Endpoint detection and response has no visibility into prompt injection, tool poisoning, or semantic exfiltration, because these attacks operate above the layer EDR instruments: inside the model's context window and the agent's chain of reasoning, where there is no process anomaly, no file system event, and no memory behavior for EDR to flag as malicious. An agent that exfiltrates an SSH key through a poisoned tool description looks, from EDR's vantage point, like a normal process making an authorized network call, because that is what it is doing; the authorization itself was what got hijacked.

Output filtering has the same blind spot from a different angle. Sentry's chosen fix, a payload-string filter, catches known malicious strings sitting in tool outputs, but it does nothing against the same instruction phrased a different way. What the filter cannot intercept is the model's willingness to comply once it reads something that sounds like a legitimate instruction, however it's worded.

And a good share of this risk sits upstream of any runtime detection. If a server's description was poisoned before the agent ever connected to it, no monitor watching runtime behavior can catch the moment the compromise happened, because the attack already ran its course back in the supply chain. CVE-2025-6514, rated 9.6 on the CVSS scale, hit the widely used mcp-remote proxy package across more than 437,000 installed environments, and the compromised package had already spread through that entire installed base long before any behavioral detection had a chance to flag it. OX Security's April 2026 disclosure of a related architectural flaw estimated vulnerable instances spread across a supply chain touching hundreds of millions of package downloads, a scale at which a defense posture built only around runtime monitoring would miss the problem entirely.

The readiness numbers reflect how early this all still is: only a minority of organizations say they feel prepared to secure agentic AI applications. Most of them are currently running agents they cannot properly watch. The protocol gave AI agents hands before the industry built the equivalent of gloves.