A2A v1.0 shipped in April 2026, backed by over 150 organizations , and the press cycle called it a milestone. A few months later, researchers formalized the spec into a finite-state machine and found eleven vulnerabilities exploitable by a spec-compliant adversary - no implementation bugs needed. That is the uncomfortable position teams building on A2A now find themselves in: a production-grade standard with structural attack surface baked into the spec.
The question teams are asking is the right one. Not "should we use A2A?" but "what do we have to engineer around to use A2A safely?"
What A2A actually does in a multi-agent system
A2A is the horizontal communication layer between agents: the wire that lets one agent discover another, hand off a task, and subscribe to progress updates - across frameworks, vendors, and organizational boundaries. Where MCP addresses an agent's interaction with its environment (data and tools), A2A targets the harder challenge of enabling communication and coordination among agents themselves.
A2A is designed as a complement to MCP, not a replacement: if MCP is the "wrench" for tool access, A2A is the "mechanics' dialogue."
The core primitives are straightforward. An Agent Card is a publicly accessible JSON document, hosted at a known URL, that details an agent's operational scope, its specific functions, its endpoint, and authentication metadata.
A Task is a concrete unit of work, identified by a unique ID, whose status can be updated over multiple rounds of interaction. A client agent sends a task to a remote agent; the remote agent processes it and streams updates back.
The v1.0 release formalized cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalization (RFC 8785) for domain verification.
The card is signed with a key whose public key is published under the same domain, letting a calling agent verify both the integrity of the metadata and the domain ownership of the server in a single check - which is what made A2A acceptable to enterprises with strict identity controls. Without it, any host could publish an Agent Card claiming any skill set.
That sounds solid. The A2ABreak findings explain why it is not quite enough.
The 11 vulnerabilities that live in the spec, not the code
A2ABreak is a security-analysis framework that reads the A2A v1.0 specification, extracts traceable formal statements, and builds a unified finite-state machine from them - then searches that FSM for protocol-level vulnerabilities and verifies each one adversarially. The findings hold even when every party follows the specification.
The framework uses LLM-assisted extraction to produce a unified model of 37 states and 76 transitions from 929 formalized statements, then systematically reasons over this model to discover vulnerabilities through adversarial verification under a full-compliance assumption.
Three of the eleven findings are most immediately relevant for teams building multi-agent pipelines:
Context injection. Conversation contexts carry no ownership binding or access control, enabling an authenticated adversary to inject tasks into another client's context, access the victim's accumulated state, and poison subsequent interactions.
Credential harvesting via delegation. In multi-hop delegation chains, identity is progressively lost, enabling credential harvesting as a task moves from agent to agent.
Rogue agent capability spoofing. Rogue agents can advertise capabilities nobody attested, because the spec does not mandate verification of claimed skills against a trusted registry.
The A2A protocol only began to receive systematic security attention in 2026 , which means most teams that adopted A2A through the v0.x cycle built their trust models around assumptions the researchers just invalidated.
Beagle in action#eng-agents, 3:07pmWhat governance looks like now - and what it doesn't cover
A2A v1.0 is governed by the Linux Foundation and has been integrated into AWS, Microsoft, and Google cloud platforms; Linux Foundation founding partners include Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.
The v1.0 release is guided by a technical steering committee with representatives from eight major technology companies. That is legitimate institutional weight.
But governance and spec security are different problems. A2A v1.0 is the current stable release and the core data models and protocol bindings are stable - but architects should still expect to engineer application-level workarounds for the gaps the spec leaves open.
Specifically, A2A lacks mechanisms for informing users or obtaining consent before sensitive data is shared between agents. The signed Agent Cards solve identity at the discovery layer; they do not solve authorization at the task layer. An agent can be who it says it is and still request context it was never meant to see.
The practical gap: the spec allows teams to build secure systems. It just does not force them to. The A2ABreak authors reported all findings to the A2A project maintainers under the Linux Foundation and are waiting for their response. Until that response lands, the mitigations are on the team building the system.
What a team actually needs to do before deploying A2A
A2A is ready for production use with the right additions. Here is the short list:
| Layer | Risk from spec gap | Mitigation to build in |
|---|---|---|
| Context IDs | Unauthenticated injection across clients | Per-client ownership tokens, validated server-side before any context read |
| Delegation chains | Credential bleed across hops | Downscoped tokens minted per hop; no bearer credential passthrough |
| Agent Card claims | Unattested capability advertising | Registry attestation or allowlist of verified skills before task dispatch |
| Consent / data scope | No user disclosure before cross-agent data sharing | Explicit consent gate at the orchestrator before any PII-touching task |
A2A v1.0 did ship improved developer experience (simpler UUID-based IDs, protocol versioning per interface) and enterprise-ready features like Agent Card signature verification using JWS and JSON canonicalization
- those are real improvements. The signing solves impersonation at discovery time. It does not solve what happens to context once the task is in flight.
Teams that are already on A2A v0.x face an additional wrinkle.
A2A v1.0 removed the v0.x kind discriminator field - event type is now determined by the JSON member name - and the v0.x final: true boolean is gone too, with the stream closing when a task hits a terminal state instead.
These are breaking changes, not patch-level bumps.
Beagle in action#platform, 10:22amThe honest summary: A2A v1.0 is the right protocol to bet on for multi-agent coordination. As organizations build increasingly sophisticated multi-agent systems, interoperability has become the defining challenge - teams can coordinate agents within a single platform, but connecting those systems across technology stacks and organizational boundaries remains hard. A2A addresses that by combining multiple protocol bindings, version negotiation, and a common semantic model. The institutional backing is real, the spec is stable, and the alternative is reinventing the same wire format yourself.
The catch is that the spec's security posture is advisory where it needs to be mandatory. Teams that treat A2A as "secure by default" because it ships with signed Agent Cards are going to get burned by the things the signature does not cover.
A2A protocol for multi-agent systems: common questions
What is the A2A protocol and how does it differ from MCP?
A2A (Agent2Agent) is an open standard for communication between AI agents - discovery, task delegation, and streaming results across organizational and framework boundaries. MCP handles communication between an agent and its tools or data sources. They are complementary: MCP gives an agent its hands; A2A lets agents coordinate with each other.
Is A2A v1.0 safe to use in production?
A2A v1.0 is stable and institutionally governed, but researchers at Purdue and UT Dallas found 11 protocol-level vulnerabilities exploitable by spec-compliant adversaries - no bugs required. The three highest-risk issues are context injection, credential harvesting through delegation chains, and unattested capability claims. Teams need to build application-layer mitigations; the spec does not mandate them.
Who governs the A2A protocol?
A2A has been donated to the Linux Foundation and integrated into AWS, Microsoft, and Google cloud platforms. Linux Foundation founding partners include Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. The technical steering committee has representatives from eight major technology companies.
What breaks when migrating from A2A v0.x to v1.0?
Three changes are high-impact: the kind discriminator field is gone (event type is now inferred from JSON member name), final: true is removed (streams close on terminal task state), and compound task IDs like tasks/{id} are replaced with simple UUIDs. All three require code changes, not just config updates.
Do I need A2A if my agents only run inside one platform?
No. If your agents all run in the same framework and never cross organizational or system boundaries, A2A adds protocol overhead with no benefit. A2A's value is specifically in heterogeneous, cross-boundary coordination - when one vendor's agent needs to delegate to another vendor's agent and neither side should need to know about the other's internals.