The MCP to A2A kill chain is one poisoned tool description, a rogue agent registered in the A2A fabric, routing hijacked, data out, and access that survives deleting the server you blamed. That piece is about the chain.
This one is about why nobody found it earlier. The chain is a symptom. The cause is a habit in how we threat-model protocol stacks, and it will produce the next one of these too.
The same trust model, one layer up
MCP’s trust model: tool descriptions are attacker-influenceable content that the agent processes as trusted instruction.
A2A’s trust model: Agent Cards are attacker-influenceable content that the orchestrator processes as trusted input.
Structurally identical. What differs is leverage. MCP gives an agent tools, so one compromised server controls one tool. A2A gives an agent peers, so one compromised participant can sit in the path of everything the fleet routes.
The security community did not look at the composition immediately, and the reason is procedural rather than technical. MCP security analysis evaluates MCP. A2A security analysis evaluates A2A. Neither evaluates the handoff, so the handoff is where an attack can live in plain sight for a year while both layers are being actively researched.
What the taxonomy has and has not caught up on
Two things changed since I first wrote this argument in May 2026.
The vulnerability classes are now named. The OWASP Top 10 for Agentic Applications, announced in December 2025, covers this ground explicitly. ASI10, Rogue Agents, is the closer fit for registering a fake peer with a cloned schema; ASI07, Insecure Inter-Agent Communication, covers the unauthenticated and spoofed messaging that lets that fake peer intercept privileged coordination traffic once it’s in. Between the two, that’s stages two and three, written down as named classes.
The protocol grew the primitive it was missing. A2A v1.0, released in April 2026 under Linux Foundation governance, defines cryptographically signed Agent Cards using JWS (specification section 8.4), alongside multi-tenancy support. There are production SDKs across Python, JavaScript, Java, Go and .NET, with Rust following, and general availability inside Microsoft Copilot Studio, Azure AI Foundry and Amazon Bedrock AgentCore. More than 150 organizations are behind the standard. When I first drafted this, “hash the Agent Card and compare it on every fetch” was a control you had to build yourself. Now the signing is in the spec.
The honest 2026 version of the story is not “nobody has thought about this.” It is narrower: a named vulnerability class and a standardized signature primitive do not close a gap that lives between two layers, because the gap is in the analysis, not in either layer’s feature set.
Three specifics support that.
A signature proves a card came from the key that signed it and was not altered in transit. It does not tell the orchestrator that this peer deserves the task, which is the actual decision being made. A rogue agent that registers with its own valid key and a description one word better than the incumbent’s presents a perfectly verifiable card.
The spec defines signing and verification, and defines no revocation mechanism. There is no revocation list, no status endpoint, no defined path for invalidating a card you no longer trust. The persistence stage of the chain survives the new primitive intact: once a rogue peer is a citizen of your registry, the standard gives you no protocol-level way to evict it.
Signing answers who sent the card. The routing layer is deciding something else entirely: whether this peer should get the work. That question has no primitive yet, and neither does undoing a decision you regret.A primitive in a specification is not a default in a deployment. Signing is available across the SDK ecosystem; whether your orchestrator verifies signatures, and what it does when verification fails, is a configuration question. Available and enforced are different states, and the gap between them is where most of the real exposure sits.
The coverage matrix
Current as of July 2026:
| Attack stage | Snyk Agent Scan | Cisco AI Defense |
|---|
| 1 · MCP tool description poisoning | Yes, static and session scanning, description pinning | Yes, MCP scanning plus runtime request/response protection |
| 2 · Rogue agent registration | Not documented for A2A registration | Partial, rogue and deceptive agent behavior detection |
| 3 · Routing hijack via shadowing | Not documented | Not documented for A2A task routing |
| 4 · Second-hop injection in task payload | Not documented | Partial, intent hijacking detection |
| 5 · Persistence after server removal | Not documented | Not documented |
Two corrections worth stating out loud.
First, mcp-scan and snyk-agent-scan are not two tools. Invariant Labs, the ETH Zurich spin-off behind mcp-scan, was acquired by Snyk in June 2025, and mcp-scan is now Snyk Agent Scan, Apache 2.0, at v0.4.13 as of April 2026, covering fifteen-plus risk categories across MCP servers, agent skills and harnesses. Listing them as separate columns overstated how much independent coverage exists.
Second, describing Cisco AI Defense as static only was out of date. The February 2026 release added an MCP Catalog for inventory across public and private registries, plus in-path controls that inspect MCP traffic and flag poisoned tools. The March 2026 release added agent identity and access controls, and pre-deployment red-teaming for prompt injection and jailbreaks. Whether either release’s detection reaches as far as stage-four intent hijacking specifically is not something Cisco’s own press materials confirm, which is why that cell says partial rather than yes.
The matrix is a reading of documented capability, not a bake-off. I have not run these products against my lab chain end to end, vendor capability in this space changes on a quarterly cadence, and “not documented” means I could not find the claim rather than that the product certainly fails. What survives is the shape: coverage is real and improving at the MCP layer, and thin to absent at the layer where agents route work to each other.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#e8f4fd", "primaryBorderColor": "#3182ce", "fontSize": "14px", "fontFamily": "system-ui, -apple-system, sans-serif"}}}%%
flowchart TB
subgraph MCPL["MCP layer · analyzed, scanned, tooled"]
M1["Tool descriptions"] --> M2["Agent"]
end
subgraph A2AL["A2A layer · specified, signed, largely unwatched"]
A1["Agent Cards"] --> A2["Orchestrator routing"]
end
M2 -->|"the boundary
nobody's threat model owns"| A1
GAP["Where the chain lives:
MCP is the entry point,
A2A is the leverage,
neither analysis crosses over"]
M2 -.-> GAP
A1 -.-> GAP
classDef ok fill:#e8f4fd,stroke:#3182ce,color:#1a202c,stroke-width:1.5px
classDef threat fill:#0f172a,stroke:#0f172a,color:#fff,stroke-width:1.5px
class M1,M2,A1,A2 ok
class GAP threat
Weekly practitioner-level analysis of AI security — attack labs, incident breakdowns, and defense patterns for teams actually building these systems. One email per week, no fluff.
Subscribe — it's free One finding that is genuinely model-dependent
Most of this chain is protocol-level, which is why it does not care which model you run. Stage one works because a tool description is text the agent treats as instruction, and that is true of every cooperative agent. Stage two works because A2A discovery is open by design.
Stage four behaves differently. When the rogue agent sends a task to a legitimate peer with a secondary instruction embedded in the task payload, whether that instruction gets followed varies by model family. In lab runs across three families the larger, stronger instruction-followers were the ones that complied. Smaller models more often ignored it.
This is a lab observation across a small number of configurations, not a benchmark. I have not published per-model numbers, so read it as a direction rather than a result. The direction is the uncomfortable part: this is the same pattern seen in RAG semantic injection, where a well-written policy document is more persuasive to a more capable model. Upgrading the model in your fleet is not a security improvement at this stage of the chain, and may be the opposite.
The attestation gap
The protocol-level fix for the routing decision is attestation: not proof that a card was signed by whoever signed it, but a verifiable claim about what a peer is entitled to do.
Maloyan and Namiot, arXiv 2601.17549, is “Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents.” This is an MCP paper, correcting an earlier miscitation that presented it as an A2A Agent Card design. What it identifies is closely related: absence of capability attestation, so servers can claim arbitrary permissions; bidirectional sampling without origin authentication; and implicit trust propagation across multi-server configurations. It proposes MCPSec, a backward-compatible extension adding capability attestation and message authentication, and reports reduced attack success rates.
The primitive missing at the MCP layer, a verifiable claim about entitlement rather than identity, is the same primitive missing at the A2A layer. Two research communities identified the same absence at two layers, and the composition of those two absences is the kill chain.
What actually helps today
Three controls, with honest coverage.
Verify Agent Card signatures, and decide what a failure means. The spec supports it now. Turn it on, and specify the behavior when verification fails or a key is unknown. A verification path that logs and proceeds is decoration. This raises the cost of stage two without addressing the entitlement question underneath it.
Treat A2A registration as a privileged operation. Open discovery is the feature and also the exposure. An approval step for new peers entering a production registry costs agility and buys the load-bearing part of the chain. Detect near-collisions rather than duplicates, since an attacker registers something one edit away from the real name.
Baseline routing and alert on change. Learn which agent normally handles which task type, alert when that shifts. This catches stage three, the hijack itself, and misses stages two and four. It is also the only one of the three that would tell you something is wrong today, in a fleet already compromised.
Plan for the absence of revocation. If you lose trust in a peer, the protocol does not help you. That is a manual runbook to write before you need it.
What this means for your threat model
The generalizable finding is not about MCP or A2A. It is this: every time you stack a new trust layer on an existing one without re-modeling the boundary, you create this same gap.
Container escape research spent years with threat models that evaluated the container runtime and threat models that evaluated the host kernel, while the interesting attacks lived in the boundary between them. Nobody was wrong about their layer. The composition was simply nobody’s job.
The shape is not new. What is new is the cycle time: container escape took years to become common knowledge, and the agent protocol stack rebuilt the same gap inside eighteen months.Agent protocols are running the same play with a shorter cycle time. MCP gets scrutiny, A2A gets a specification and signatures, and the interaction between them gets a name in a taxonomy but no coverage in a tool. When ACP or the next discovery layer stacks on top of A2A, the same gap opens one level up.
The cross-protocol boundary is an explicit agenda item in threat modeling work on agent deployments, and the questions are:
- For each pair of adjacent trust layers, what does the upper layer accept from the lower one without re-validation?
- Which decisions does the upper layer make based on content the lower layer can influence?
- If the lower layer is compromised and then cleaned, what state persists in the upper layer? Is there a revocation path, and has anyone tested it?
- Which of your tools have visibility across the boundary rather than at one side of it?
Most threat models answer none of these, not because the teams are careless but because the document is organized by component and the attack is organized by sequence.
The protocol-level fix is coming. Signed cards were the first instalment and they arrived faster than expected. Attestation and revocation are not here yet, and until they are, the boundary is yours to defend.
The chain is Lab 08 in aminrj-labs/mcp-attack-labs. Full sequence in a local lab, no authentication bypass, no CVE.
References
- Agent2Agent (A2A) Protocol Specification v1.0, Linux Foundation, released April 2026; signed Agent Cards via JWS in section 8.4; no revocation mechanism defined
- A2A Protocol Surpasses 150 Organizations, Linux Foundation, April 2026
- OWASP Top 10 for Agentic Applications (ASI01–ASI10), OWASP GenAI Security Project, announced December 2025. ASI07 Insecure Inter-Agent Communication and ASI10 Rogue Agents cover stages two and three of the chain
- Maloyan and Namiot, “Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents”, January 2026, proposing MCPSec capability attestation
- Snyk Agent Scan (formerly Invariant Labs mcp-scan; Invariant acquired by Snyk June 2025), Apache 2.0, v0.4.13 April 2026
- Cisco AI Defense; agentic expansion announced February 2026 and March 2026
- The coverage matrix reflects documented vendor capability as of July 2026, not head-to-head testing.
