The instruction your second AI agent follows may not have come from its user. Syed Anas Mohiuddin, an independent security researcher, demonstrated a chain in which text planted in content one agent reads travels onward as a routine delegated task, and the receiving agent runs it because it trusts whoever sent it. Five organisations have separately confirmed and fixed server-side request forgery (SSRF) bugs he reported in their MCP servers. Nobody has shown that chain used in a real attack. Mohiuddin calls the broader pattern “protocol pivoting”, a label another researcher rejects on the record. Underneath it is indirect prompt injection crossing a delegation boundary.

What MCP is, and where the trust sits

MCP, the Model Context Protocol, is the open standard that lets AI assistants call tools and read data, described in its own documentation as a USB-C port for AI applications. A2A, Google’s Agent-to-Agent protocol, is a separate standard for agents handing work to other agents. Mohiuddin’s demonstration depends on both, and on the trust each side extends to the other: a tool call arriving at an MCP server carries the authority of the agent that made it, including an agent that has just read something hostile.

How an instruction travels from one agent to the next

The chain has four steps. An attacker plants text in content an MCP tool returns. The text is shaped like an A2A task instruction. The orchestrating agent passes it to a subagent as ordinary delegation. The subagent trusts its orchestrator and executes it, and if it holds an MCP server with an SSRF bug, “the request now originates inside the trust boundary, with the subagent’s network position and permissions,” as Mohiuddin describes it.

Nothing in that chain is broken; every component behaves as designed. Rapid7’s Douglas McKee calls that what makes it hard to catch: “Each protocol was built assuming it lived on its own, so each one checks its own front door while nobody watches the hallway in between.” The pattern does not require SSRF: any tool that gives an attacker an outbound request or a privileged action will do, and SSRF is the consistent bug class Mohiuddin found in shipped code.

What five organisations fixed, and what is still unconfirmed

Five security teams independently reviewed an SSRF finding from him, confirmed it and shipped a fix: Google, JPMorgan Chase, Weaviate, DINUM (the French interministerial digital directorate behind data.gouv.fr) and the Tangerang City government in Indonesia. Public records verify four: Google’s CVE, Weaviate’s merged pull request of 7 September 2026, DINUM’s hardening merge of 4 September 2026 crediting him, and Tangerang’s High severity advisory of 3 September 2026. The JPMorgan finding is single-researcher: he rates it medium, no credential travelled alongside the forged request, and the acknowledgment page sits behind a sign-in.

The two CVE-backed issues are different bugs, and their scores sit on different scales. Google’s CVE-2026-14540 is SSRF, 8.0 High under CVSS 4.0, fixed by resolving the address at connect time, applying IP allow and block lists and rejecting an unsafe base URL at startup. Rapid7’s CVE-2026-97228 is GraphQL query injection in Bulk Export MCP 0.2.5 through 0.6.1, 2.7 Low under CVSS 3.1, fixed in 0.6.2 by parameterising the identifier. Rapid7’s record notes that the injected query runs inside the operator’s authenticated scope and cannot cross a tenant or account boundary, so a malicious operator gains nothing, while a compromised or careless upstream client is a real concern.

The five US federal findings are different again. He filed them as private security advisories on 2 September 2026 covering servers at the Department of Veterans Affairs, the Centers for Medicare & Medicaid Services, regulations.gov, USASpending and the CDC. All five are unconfirmed: in triage, unfixed, with no code detail published, and not acknowledgements. Two more sit at the same level: an unmerged pull request adding opt-in binding to a Japan Digital Agency MCP server, and a public GitHub issue about Microsoft’s playwright-mcp accepting any agent-supplied URL.

There is no evidence of exploitation in this record. The CISA enrichment for Google’s CVE records exploitation as “none”, Rapid7’s record shows an EPSS score of 0%, and neither issue is in CISA’s known exploited vulnerabilities catalogue. This is proof-of-concept work plus coordinated disclosure, and the acknowledged bugs are fixed.

“Protocol pivoting” or indirect prompt injection?

Mohiuddin defines his term as “a multi-step attack in which an adversary gains initial access through one protocol, exploits trust assumptions between protocols, and escalates to capabilities only accessible via a different protocol”. The writeup is a self-published preprint first posted on 24 May 2026, not peer reviewed, with no independent replication found. He is an independent researcher with no institutional affiliation.

Markus Vervier, a researcher at X41 D-Sec, does not accept that the cross-protocol element earns a new class. “For me this is indirect prompt injection,” he told Ars Technica, adding that the malicious prompt arriving from a different protocol is “not strictly required for such attacks to work. It is, of course, unexpected and hard to mitigate in general.”

McKee is blunter about the bugs underneath: “The bugs underneath are old friends like injection and SSRF, and the fixes haven’t changed in 20 years.”

The instruction-passing chain is real and the fixed bugs are verified. Whether it is a new class is a single-researcher claim and actively disputed, so treat “protocol pivoting” as one researcher’s label for a pattern, not an established category.

MCP’s own documentation already covered this class

The mitigations were published before the bugs. The security best practices page in the MCP documentation, in its 25 November 2025 version, already carried an SSRF section naming cloud metadata endpoints, DNS rebinding and redirect chains, and prescribing what Google later shipped: block private and link-local ranges, validate each redirect hop, and route egress through a proxy. The documentation site serves version-labelled pages, so that date is a version label rather than an archival capture. SEP-990 on enterprise identity provider controls and SEP-1024 on local server install consent both date from mid-2025 and are Final. Guidance existed and adoption lagged.

What to ask your security team

Ask about authorisation between agents, not only patching.

  • Do our MCP servers and clients block private, link-local and cloud metadata addresses and re-validate each redirect hop? (MCP Security Best Practices)
  • Is authorisation checked at each hop, with tokens audience-validated so one service cannot pass its token through to another? (Understanding Authorization in MCP)
  • Are tool scopes least-privilege, and can enterprise administrators control which MCP servers are usable inside the organisation? (SEP-990)
  • Do local servers run isolated, with their own credentials, filesystem limits and egress control, and does a one-click install show the exact command and ask for consent? (Local Server Security, SEP-1024)
  • Would anyone on the team treat input from an LLM as trusted because it came from inside the system? McKee’s rule is the one to repeat: “anything passed from an LLM to your tool should be treated like input from a stranger on the Internet, because in a prompt injection scenario that’s exactly what it is.”