Agent2Agent Protocol and Remote Agent Collaboration

The A2A Project ships demo agents of its own. A team attacked them and counted what got through.

Six A2A-specific attacks were run against those official demo agents, in travel, healthcare and finance. Five of the six reached an attack success rate of 1.00 in all three domains: Capability Cloaking, Half-Open Task Flooding, Cycle Overflow, Agent-Side Request Forgery and Artifact-Triggered Script Injection. The sixth was AgentCard Spoofing. It averaged 0.820 in travel, 0.816 in healthcare and 0.828 in finance, across Gemini 2.5 Flash, GPT-4o, Claude 4, DeepSeek-R1 and Grok 4. The benchmark is A2ASecBench, published at ICLR 2026. A client agent choosing its partner from a published card was diverted to the attacker at those rates.

The failure sits in the discovery step itself. The paper puts it in one sentence: “attackers either publish near-duplicate, schema-valid cards that divert tasks (AgentCard Spoofing) or advertise benign capabilities while their backend exposes hidden ones (Capability Cloaking), leveraging the gap between declared identity/capabilities and actual behavior.”

Cloaking is not only a security cost. Benign task utility fell from 0.853 to 0.682 in travel, from 0.872 to 0.595 in healthcare and from 0.962 to 0.749 in finance. The delegated work got worse while still coming back looking finished. The attack also gets easier as the directory fills. As the number of injected lookalike cards k went 3 → 5 → 7, spoofing success rose from 76% to 87% to 95%. In none of these runs did the client side run an independent check. That was the condition being measured.

The Agent2Agent protocol provides a common interaction model for discovering capabilities and exchanging messages, tasks, status, and artifacts with independent agent systems. The remote system may remain opaque to the client.

A2A complements tool protocols rather than replacing them. Both projects draw the line in their own words. MCP, says A2A’s documentation, “defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API”. Then the split, in a single sentence: “A2A focuses on agents partnering on tasks, whereas MCP focuses on agents using capabilities.” The Model Context Protocol specification describes itself the same way: an open protocol for integrating LLM applications with external data sources and tools. The Linux Foundation makes the boundary an organizational one: “A2A defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources.”

Neither protocol removes the need to authenticate the caller, authorize the action, agree a contract, and evaluate the result. MCP is how your agent reaches a tool. A2A is how your agent hires another agent.

An Agent Card advertises what a remote agent will do. The client agent decides whether to believe it. A task and its artifacts are what actually cross the boundary. Task and artifact belong to one owner and the trust contract to another, with tests to match.

The specification is precise about the first of those. An Agent Card is “A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements”. Published by the server: it is a document the remote side writes about itself. Version 1.0.0, released on 12 March 2026, was the first stable specification. It also lists “Opaque Execution” among its five guiding principles. There is nothing behind the card to check the card against.

Nor does the protocol oblige a provider to prove the card is theirs. Cryptographic proof is OPTIONAL: Agent Cards MAY be signed with JSON Web Signature (RFC 7515). The specification explains what a signature would buy you: “Signatures allow clients to verify that an Agent Card has not been tampered with and originates from the claimed provider.” A MAY is not a MUST. Unless the client demands a signature and verifies it, tamper-evidence and provenance are exactly the two things the card does not carry. That is the gap AgentCard Spoofing walked through at 0.820, 0.816 and 0.828. Authentication is delegated the same way, to standard web mechanisms — HTTP headers, OAuth2, OpenID Connect — rather than defined by A2A. The identity work is yours to configure and yours to get wrong. Believing the card is a decision taken on your side.

Draft the delegation contract for one remote agent your organization would plausibly hire, acceptance tests included. It should expose that delegation can transfer work without transferring accountability, and preserve evidence that remote work products meet the client’s independent acceptance tests.

You do not have to invent the shape of that contract. Banking supervisors published one. The “Interagency Guidance on Third-Party Relationships: Risk Management” was issued jointly on 9 June 2023 by the Board of Governors of the Federal Reserve System, the FDIC and the OCC. It structures third-party risk management as a five-stage life cycle: (1) Planning, (2) Due Diligence and Third-Party Selection, (3) Contract Negotiation, (4) Ongoing Monitoring, (5) Termination.

The five steps of this exercise map onto it stage for stage. Verifying the Agent Card — provider, endpoint, skill scope, authentication, supported modes — is due diligence and selection. Specifying the task, with outcome, constraints, data limits, deadlines and evidence requirements, is contract negotiation. Controlling disclosure, sending only the information the remote skill requires, is what planning decided in advance. Validating artifacts against schema, provenance, policy and task-specific acceptance tests is ongoing monitoring. That is the stage nobody performed in the A2ASecBench runs. Planning failure handling — timeout, cancellation, partial artifacts, disputes, provider changes — is termination, written down before you need it.

On the question the whole exercise exists to settle, the guidance is blunt: “A banking organization’s use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house.” A supervisor wrote down what a delegation contract otherwise has to assert on its own authority.

Use remote agents when independent capabilities justify the boundary. A deterministic service remains preferable when negotiation and autonomy add no value.

The test matters more as the boundary gets cheaper to cross, and it has become very cheap. On 9 April 2026, one year after the original announcement, the Linux Foundation reported that A2A had grown from more than 50 supporting organizations to more than 150 — AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow among them. The core repository had surpassed 22,000 GitHub stars. The SDK ecosystem had gone from one Python implementation to five production-ready languages. Version 1.0, released on 12 March 2026, was the first stable specification, adding multi-tenancy and Signed Agent Cards. The Agent Payments Protocol (AP2) had more than 60 supporting organizations of its own. Rao Surapaneni of Google Cloud made the adoption case: “AI agents are only as useful as their ability to collaborate, and the adoption of A2A by more than 150 organizations underscores the widespread enthusiasm for an open, interoperable protocol.”

Easy to reach is not the same as right to use. Signed Agent Cards arrived in the same 1.0 release that leaves signing OPTIONAL. Adoption at this scale changes what is available, not what is verified. The client owns the review, not the remote agent. Delegation can transfer work without transferring accountability. The evidence that closes the loop is that remote work products meet the client’s independent acceptance tests.