Keysight Research published a working attack against A2A systems in March 2026: a malicious remote agent embeds adversarial instructions inside its own Agent Card metadata, and when the host LLM pulls that card during discovery, it treats the injected text as a trusted instruction. The attack doesn't need to forge anything. It just needs a legitimately signed card with a poisoned description field.
That is the specific gap in A2A v1.0, the production release of Google's Agent2Agent protocol that shipped in early 2026 under Linux Foundation governance. The release added real cryptographic teeth to multi-agent identity. It also has a hard limit that teams building on A2A right now need to understand precisely.
What A2A v1.0 actually changed
A2A started as a protocol for agent-to-agent delegation: one agent discovers another via a JSON file at /.well-known/agent-card.json, hands off a task, and tracks its state through an eight-step lifecycle.
Agents communicate via JSON-RPC 2.0 using an eight-state task lifecycle: submitted, working, input-required, auth-required, completed, failed, canceled, rejected.
The protocol advanced from v0.3.0 in July 2025, which introduced streaming-first transport and enhanced Agent Cards with capability negotiation, to v1.0.0 in January 2026, which marked the transition from experimental to production-ready status, introduced signed Agent Cards for cryptographic verification, and codified the discovery and trust mechanisms identified as gaps in earlier analyses.
The v1.0 release introduces several capabilities aimed at production environments where trust, scale, and operational control are non-negotiable. Heterogeneous environment support enables interoperability across diverse technology stacks through multi-protocol bindings and version negotiation, so enterprises are not tied to a single vendor or platform. Multi-tenancy support allows a single endpoint to securely host many agents.
The headline feature was signed cards. The most important change is Signed Agent Cards. By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack. Signed Agent Cards are effectively the trust model that makes decentralized discovery viable at all.
The mechanics:
the A2A spec defines AgentCardSignature as a JWS (RFC 7515) over the card content, canonicalized with JCS (RFC 8785) so signatures are reproducible across JSON serializers. The official a2a-sdk ships helper utilities for signing and verifying Agent Cards, consolidated under a2a.helpers in v1.0.
The second change is multi-tenancy: a single endpoint can now host multiple agents, letting SaaS providers serve different agents per tenant. The third is multi-protocol bindings: the same logical agent can be exposed over both JSON-RPC and gRPC. The fourth is version negotiation, which gives spec-level guarantees for backward-compatible migration from v0.3 to v1.0.
By April 2026, more than 150 organizations participate, the GitHub repo has passed 22,000 stars, and production deployments exist inside Azure AI Foundry and Amazon Bedrock AgentCore.
The limit that v1.0 didn't solve
Here is the line from the Tyk A2A security guide that matters most: "Treat every field from an external Agent Card as untrusted input. Sanitize strings before they reach an LLM, even after signature verification. Signing only proves the card came from the claimed issuer; it doesn't tell you the issuer was benign."
That is not a bug in the A2A spec. It is a structural property of how signatures work. Signatures verify origin and integrity, not intent.
Modern multi-agent systems built on the A2A protocol enable dynamic discovery and delegation between autonomous agents through structured metadata known as agent cards. These cards describe capabilities, endpoints, and operational details that the host agent uses to plan task delegation. However, when agent cards are injected directly into an LLM's reasoning context without strict boundary enforcement, metadata can be reinterpreted as executable instruction. Keysight Research demonstrates an attack vector termed Agent Card Poisoning, a metadata injection vulnerability in which a malicious remote agent embeds adversarial instructions within its agent card.
A practical example of how this looks in a LangGraph A2A implementation:
by hosting a malicious A2A server with a crafted AgentCard, an attacker can inject arbitrary directives into the description or skills fields, which are then processed by the host's LLM as trusted instructions. The a2a_discover_agent tool in LangGraph-a2a-client returns the full agent_card.model_dump() to the LLM as a ToolMessage. Since LangGraph's default create_react_agent logic appends these messages to the chat history, the LLM consumes the untrusted AgentCard content as part of the context. This allows for prompt injection, where an attacker can override system instructions.
The attack doesn't require network access or credential theft. It only requires that the host's orchestrator is configured to delegate to external agents - which is exactly what A2A is designed to enable.
Prompt injection propagates across agents: a poisoned input or tool result read by one agent can steer the agents it delegates to, so injection defense is an agent-to-agent concern, not only an input-boundary one. This is the cascading property that makes multi-agent systems meaningfully different from single-agent deployments. A single poisoned card, accepted by an orchestrator agent, can propagate downstream to every specialist it tasks.
What the governance layer still can't express
MCP's specification evolution added Elicitation and Sampling but no governance primitives. A2A v1.0.1 added extension infrastructure without governance content.
The research paper "Governance Gaps in Agent Interoperability Protocols" is direct about this: neither A2A nor MCP has a native way to express constraints like "this agent can only read data, never write" or "this delegation chain may not exceed two hops." Those constraints have to be enforced by the application layer or by a gateway sitting in front of A2A traffic.
A2A is delegation-centric: it answers "which agent can handle this task?" Four official example extensions exist - Secure Passport, Timestamp, Traceability, Agent Gateway Protocol - and none addresses governance.
At the observed evolution velocity, the governance gap could narrow significantly within six to twelve months through protocol extensions, particularly via A2A's extension mechanism. But that doesn't help teams shipping today.
The practical checklist for teams running A2A in production right now:
- Never pipe a raw Agent Card to your LLM. Extract fields programmatically. Render them as structured metadata in a separate context boundary from your system prompt.
- Maintain an allowlist of trusted agent origins. Dynamic discovery is useful; unbounded discovery from arbitrary URLs is an attack surface.
- Verify signatures and then sanitize anyway. Signature verification tells you who signed the card. It tells you nothing about what they put in it.
- Treat Agent Card poisoning as an indirect prompt injection variant. Your existing injection defenses - input scanning, output monitoring, action confirmation gates - apply here.
- Log Agent Card fetches as first-class security events. If an agent is suddenly trying to delegate to a new endpoint, that should alert, not silently proceed.
Beagle in action#security-review, 2:07pmA2A Agent Card security: common questions
What do Signed Agent Cards actually verify?
Signed Agent Cards in A2A v1.0 use JWS over a canonicalized JSON representation of the card to prove the card came from the claimed domain owner and hasn't been tampered with in transit. They do not verify that the card's content is safe. A malicious but legitimate issuer can sign a card containing adversarial instructions, and the signature will still pass.
What is Agent Card Poisoning?
Agent Card Poisoning is a prompt injection attack against multi-agent systems. A malicious agent embeds adversarial instructions inside its Agent Card metadata - typically in the description or skills fields. When a host LLM consumes that card during discovery, it can treat the injected text as a trusted instruction and act on it. The attack requires no credential theft or network intrusion.
Does A2A v1.0 fix the prompt injection problem for multi-agent systems?
No. A2A v1.0 adds cryptographic identity verification, which closes the card forgery attack surface. It doesn't address what a validly signed card can contain. Defense against Agent Card Poisoning requires application-layer controls: field sanitization, allowlists of trusted agent origins, and structured rendering of card content outside the LLM's instruction boundary.
How does A2A's trust model compare to MCP's?
MCP is hub-and-spoke: one agent connects to tool servers it explicitly configures. A2A is horizontal: agents discover and delegate to other agents dynamically. That makes A2A's trust surface larger and more open by design. With MCP, you control what tools your agent can reach. With A2A in dynamic discovery mode, your agent can potentially reach any agent that publishes an Agent Card - including malicious ones.
Is there governance support in A2A for things like permission scopes or delegation depth limits?
Not yet in the protocol itself. A2A is delegation-centric - it answers "which agent can handle this task?" but its four official extensions don't address governance. Teams enforcing delegation limits or permission scopes today are doing it in application code or via a gateway product like TrueFoundry's Agent Gateway, which adds per-agent RBAC and loop safeguards on top of standard A2A traffic.