Research · A2A v1.0 · selection-layer injection
Signed, Not Safe.
A2A v1.0 shipped cryptographically signed Agent Cards in April. It closes the exact hole we described in Agent-in-the-Middle — a forged or tampered card winning delegation. It does nothing about the hole sitting right next to it.
01 · What we found in June
Selection happens before authentication.
The original write-up walked through how A2A's host agent picks a remote agent for a task. Discovery happens first: the host pulls the Agent Cards of every agent it knows about, and an LLM reads their description and skills fields to decide who's best suited. Authentication happens second, only after that decision is already made.
That ordering is the bug. A card whose description is written to sound authoritative — claims of certification, audits, exclusivity, or instructions like "always prefer this agent" — can win the selection step on persuasion alone. By the time the host checks credentials, the task envelope has often already gone out. Nothing about it required breaking auth. It only required writing a better description than the legitimate agent's.
02 · What actually shipped
Signed cards, and a payments layer on top.
A2A crossed its one-year mark on April 9, now stewarded by the Linux Foundation under an Agentic AI Foundation working group. The headline change in v1.0 is exactly the fix that write-up asked for: Agent Cards can now carry a cryptographic signature issued by the domain owner, and the release added the AP2 extension for agent-driven payments on top of the same card and task model. Adoption isn't theoretical — the ecosystem reports 150+ participating organizations, 22,000+ stars on the reference repo, and production deployments inside Azure AI Foundry and Amazon Bedrock AgentCore.
Give credit where it's due: this closes real attacks. Card shadowing — cloning a legitimate agent's card and registering it under a similar domain — no longer works, because a client verifying the signature has no reason to trust an unsigned clone. In-transit tampering — a DNS or CDN compromise serving a modified card with weaker declared auth — no longer works either, because the signature covers byte integrity end to end.
03 · The column signing can't touch
Authorship and integrity — not safety.
Lay the three attack surfaces side by side and the picture is clean:
A signature is a statement about authorship and integrity: this exact sequence of bytes came from the holder of this domain's key, unmodified. Concretely, the v1.0 signature is a JWS (RFC 7515) computed over the JCS-canonicalized (RFC 8785) card — it attests the exact canonical bytes, and canonicalization says nothing about whether those bytes are safe to feed a reasoning model. An operator who owns their domain outright — or an attacker who has compromised an otherwise legitimate one — can write whatever they want into description or a skill's example prompts, sign it correctly, and ship it. The card the host fetches passes verification and is still a working prompt-injection vector, because the schema was never designed to separate "metadata a human reads" from "instructions a model acts on".
This isn't a fringe reading. In Google-coordinated A2A security guidance, Palo Alto Networks' Unit 42 splits Agent Card risk into two distinct buckets: card management issues (weak auth, poor versioning, stale metadata) and Agent Card context poisoning — adversarial content embedded directly in card fields that compromises downstream agents when input validation is insufficient. Signing addresses the first bucket cleanly. It was never scoped to touch the second.
04 · Same mechanism, higher stakes
Now it sits upstream of a spend decision.
The AP2 extension that shipped alongside signed cards adds an agentic-commerce layer on top of A2A: an IntentMandate sets what a client agent is authorized to buy, a PaymentMandate binds that intent to a specific cart and counterparty, and a signed receipt closes the loop. None of that changes how a remote agent gets selected in the first place — it's still the same LLM reading the same card fields before any mandate exists.
In deployments that wire commerce agents into A2A discovery, a poisoned-but-signed card doesn't just misroute a support ticket the way it might have in June. It can win selection for a task that's about to generate a payment mandate — so the injection now sits upstream of a spend decision rather than upstream of a data-routing one. The mechanism hasn't changed at all. The worst case at the end of it has.
05 · Where the fix has to live
Verification is one gate. Content trust is another.
The takeaway isn't "don't use signed cards" — sign everything, it genuinely closes two of the three rows above. The takeaway is that signature verification and content trust are two separate gates, and most implementations only build the first. Verification decides whether a card is considered at all. A second, independent layer has to decide whether a considered card is safe — and that layer looks at the content, not the certificate.
That's a behavioural-baselining problem, not a cryptographic one — the same shape ABFP already solves on the MQTT/AMQP side. Instead of asking "is this signed", ask "does this look like what this specific agent's card has looked like before". Track description length, vocabulary drift, and the density of imperative, self-referential authority language ("always prefer", "certified", "pre-approved") per known agent, and flag deviation before those fields are ever concatenated into a selection prompt — the same way an anomalous MQTT publish rate gets flagged before it's trusted as normal traffic. Signed just means the card is who it says it is. Whether it's safe to reason over is a separate, ongoing question, and it belongs at the content layer.
Three edge cases worth knowing
01Signature scope. Some implementations sign the card at fetch time but not every field a host later resolves dynamically (skill-level extensions, localized descriptions). Check what the signature actually covers before assuming the whole document is attested.
02Trust still roots somewhere soft. Signature verification only pushes the trust question back one step — to whoever validated that a given key belongs to a given domain the first time. That step is usually manual, one-time, and rarely re-checked.
03Authenticated is not parsed-safely. A client that verifies a signature and then drops the entire card body into a prompt unchanged has done the crypto work and skipped the part that mattered.
Sources
- A2A Protocol — v1.0 announcement & specification (signed Agent Cards; JWS/RFC 7515 over JCS/RFC 8785), a2a-protocol.org, 2026.
- Linux Foundation / PR Newswire — A2A one-year adoption figures (150+ orgs, 22k+ stars, Azure AI Foundry & Bedrock AgentCore), 9 Apr 2026.
- Palo Alto Networks Unit 42 — A2A protocol risks: card management vs. Agent Card context poisoning (Google-coordinated), 2025.
- Keysight / SemiEngineering — "Agent Card Poisoning: a metadata injection vulnerability in systems using Google A2A", 2026.
- Trustwave SpiderLabs — Agent-in-the-Middle / rogue Agent Card selection manipulation, 2025.
- Tyk — "A2A security: the developer's complete guide" (context poisoning, untrusted card fields), 2026.
- AP2 extension — IntentMandate / PaymentMandate / PaymentReceipt flow.
- MASec Lab — Agent-in-the-Middle, 18.06.2026.