Prompt Injection in MCP Is a Trust Problem Between Agents

The most trusted process inside an AI agent deployment is another AI agent. That is the whole attack surface, and almost nobody checks it.

Ars Technica reported that five organizations have disclosed variants of the same problem since May. Each one involves a narrow worker agent, the kind built for translation or data analysis, being fed instructions that it passes onward as an ordinary delegated task.

The receiving agent runs them. It has no reason not to. In MCP, short for Model Context Protocol, servers hold a credential for each agent and agents are built to trust their internal peers, so an instruction the model itself would have refused gets executed by the plumbing instead.

The guardrail sat in the model, and the attack never touched the model

Mohiuddin calls the technique protocol pivoting. Initial access arrives over one protocol, the attacker exploits trust assumptions between protocols, and the escalation lands in capabilities that only a different protocol can reach, such as Google’s Agent-to-Agent delegation standard. The wider pattern is still MCP prompt injection with an extra hop bolted on, which is why the fixes look like ordinary injection fixes rather than anything a model vendor has to ship.

Google’s fix shows what the gap actually was. Its database toolbox initialised an HTTP client with no redirect policy and no validation of the target IP address, so a crafted path parameter could send the toolbox to an internal endpoint on the attacker’s behalf. The patch applies an allow-list of IP ranges and rejects an unsafe base URL at startup.

That is a server-side request forgery guard, and it is what a real fix looks like. CVE-2026-97228, the flaw in Rapid7’s own network, scored 2.7 and was patched last month. Google’s scored 8. The scoring gap is not about how clever the attack is. It is about whether the server was built to check where it sends traffic.

Zero trust was the answer, and agent deployments skipped it

The technique worked across five organizations with nothing in common except MCP, which is the definition of a structural problem rather than five coincidences. Zero trust exists because any node in a network may already be compromised, and the design response is to require authorization before a sensitive transaction rather than after it.

Agent deployments inverted that. They assumed every internal agent is friendly, because agents are new and the fast path was to let them delegate freely. Markus Vervier of X41 D-Sec told Ars the better name is still indirect prompt injection, and that the cross-protocol behaviour is not strictly required for the attack to work.

Treat every agent handoff the way you treat a stranger’s input

Douglas McKee, who runs vulnerability intelligence at Rapid7, put the operational version of it plainly. Anything passed from a model to a tool should be handled like input from a stranger on the internet, because in an injection that is exactly what it is.

Mohiuddin’s own write-up lists the disclosure timeline and each fix. Read it as a checklist of what to verify, not as a list of vendors to avoid.

Three questions for your agent estate. Does every MCP server in your network validate the destination before it forwards a request. Which of your agents can delegate to another agent with no authorization check at the hop. And when an internal agent hands work onward, can you reconstruct who authorised it after the fact.

The pattern to watch is the scoring, not the count of disclosures. A 2.7 and an 8 for the same class of bug tells you severity here is a property of the server’s implementation, not of the attack. Until MCP servers ship redirect policies and allow-lists by default, expect the higher number to keep appearing.

Related reading. One leading dash was enough to hand over a Kubernetes cluster, and Google shipped an agent runtime for a million idle sandboxes.