Source-linked AI summary
A2ABreak: Systematic Security Analysis of the A2A Protocol
Alireza Lotfi, Mirza Masfiqur Rahman, Imtiaz Karim, Elisa Bertino
TL;DR
A2A’s security has not received systematic analysis assessing whether its specification guarantees key security properties under full compliance. A2ABREAK formalizes the specification as finite-state machines and applies adversarial verification, identifying 11 vulnerabilities exploitable by specification-compliant adversaries.
Problem
A2A’s security has not received systematic analysis assessing whether its normative rules guarantee key security properties under full compliance.
Source: §3.1 · p. 4, §8 · p. 11Method
A2ABREAK transforms the natural-language specification into verified finite-state machines and uses adversarial verification under a full-compliance assumption to discover protocol-level vulnerabilities.
Source: §1 · p. 2, §8 · p. 11Results
11 protocol-level vulnerabilities were identified as exploitable under full specification compliance; precision was 73.3% and F1 was 84.6% against expert manual review.
Source: §1 · pp. 2–3Takeaways & Limitations
The findings show that A2A’s specification leaves critical security properties as implementation concerns rather than protocol-level invariants.
Source: §8 · p. 11The analysis does not enumerate all possible vulnerabilities, verify specific agent implementations, or address transport-layer security.
Source: §3.1 · p. 4
Abstract
from arXiv · showhide
The Agent2Agent (A2A) protocol, now governed by the Linux Foundation, is an open standard that enables autonomous AI agents to discover, authenticate with, and delegate tasks to one another across organizational boundaries. Designed to complement the Model Context Protocol (MCP) for tool integration, A2A is rapidly emerging as the horizontal communication layer of the multi-agent ecosystem. Yet the protocol's security has received no systematic analysis. This paper presents A2ABreak, the first rigorous systematic security analysis of the A2A protocol. We introduce a novel framework that utilizes an LLM-assisted extraction of a verified finite-state machine directly from the natural-language specification, producing a unified model of 37 states and 76 transitions from 929 formalized statements, and then systematically reasons over this model to discover protocol-level vulnerabilities through adversarial verification, under a full-compliance assumption. Our analysis uncovers 11 new vulnerabilities, each exploitable by a specification-compliant adversary without requiring any implementation flaw. Among the findings are cross-client context injection through unprotected context identifiers, credential harvesting via multi-hop identity loss in delegation chains, and data exfiltration through rogue agents advertising unattested capability claims. A2ABreak achieves 73.3% precision and 84.6% F1 against independent expert review, while a zero-shot LLM baseline operating over the same specification produces zero confirmed findings, demonstrating that explicit formal grounding is essential for sound protocol security analysis.
1. Introduction
A2A provides horizontal communication between autonomous agents, and A2ABreak analyzes its specification through a formal model to identify protocol-level vulnerabilities exploitable under full compliance.
Motivation
- A2A’s opaque remote execution and predominantly non-mandatory security controls leave a broad attack surface that has not been formally characterized.The specification makes key protective measures SHOULD or MAY recommendations and leaves its sole discovery-time agent-identity verification primitive optional.Source: §1 · p. 1
Challenges
- Existing A2A research had not systematically modeled the protocol lifecycle or enumerated specification-level vulnerabilities, while zero-shot LLM attack traces failed adversarial verification.The paper identifies natural-language ambiguity, ungrounded LLM outputs, and the need for sound verification as challenges; no open-source reference implementation was available for implementation-level analysis.Source: §1 · p. 2
Our Approach
- A2ABreak formalizes the specification into 929 structured statements, constructs a unified finite-state machine, and verifies candidate attacks against it.Its three stages use constrained LLM reasoning, adversarial verification, and human checkpoints to check attack executability and confirm that missing primitives are absent from the specification.Source: §1 · p. 2
Findings
- 73.3% precision and 84.6% F1 against expert review accompanied 11 validated vulnerabilities, versus zero confirmed findings from zero-shot LLM analysis.All 11 were exploitable under full specification compliance without implementation flaws or misconfiguration. Examples include cross-client context injection, credential harvesting across delegation hops, and exfiltration through agents advertising unattested capabilities.Source: §1 · pp. 2–3
Evaluation
- The FSM-construction stage recovered all 11 TCP states and 19 of 20 transitions, with precision 0.76, recall 0.95, and F1 0.84.The validation used the TCP ground-truth benchmark from PSMBench.Source: §1 · p. 3
Formal lifecycle model
- The resulting lifecycle model contains 37 states and 76 transitions, assembled from six stage-specific finite-state machines.The model captures states, transitions, and failure modes defined by the specification.Source: §1 · pp. 2–3
2. Background
A2A supports agent-to-agent delegation,, whereas MCP standardizes agent-to-tool integration,; their complementary roles differ in trust and visibility.
2.1. Agent2Agent Protocol (A2A)
- A2A uses a client–server model over HTTPS for capability-based delegation and supports JSON-RPC 2.0, gRPC, and HTTP+JSON/REST bindings.Its six stages run from AgentCard discovery and hop-by-hop authentication through task initiation, execution, optional repeated interruption, and terminal completion, failure, cancellation, or rejection. The self-asserted AgentCard is the sole trust anchor and signing is optional [9],,.Source: §2.1 · p. 3
2.2. Model Context Protocol (MCP)
- MCP defines runtime-discoverable tools, resources, and prompts to replace bespoke model–tool connectors with a shared integration surface,.Its client–server architecture uses JSON-RPC 2.0 and addresses the N × M integration problem with an N+M architecture,,,.Source: §2.2 · p. 3
2.3. MCP vs. A2A
- MCP governs agent–tool interactions under host control, while A2A connects opaque autonomous peers whose use of delegated data clients cannot verify,.That opacity extends the attack surface to remote agents’ handling of delegated data, accumulated credentials, and returned artifacts.Source: §2.3 · p. 4
3. Overview
A2ABREAK analyzes whether the A2A specification’s normative rules prevent protocol-level attacks by fully compliant adversaries, formalizing vulnerabilities as feasible traces that violate security properties because a primitive is missing. It addresses specification ambiguity and analysis soundness with separated extraction passes, reduced inputs, and constrained generation and verification.
3.1. Scope
- The analysis tests whether A2A’s normative rules suffice to guarantee security, without covering every vulnerability, specific implementations, or transport-layer security.Source: §3.1 · p. 4
3.2. Threat Model
- The adversary is authenticated, computationally bounded, and protocol-compliant, exploiting specification gaps as a client, server, or intermediary in a delegation chain.The adversary cannot break standard cryptographic primitives and acts only through A2A-defined operations.Source: §3.2 · p. 4
3.3. Problem Statement
- A2ABREAK models a vulnerability as a feasible protocol trace that violates a security property because a missing primitive permits it.The trace must use existing FSM transitions and guards satisfiable by a fully compliant party.Source: §3.3 · p. 4
3.4. Challenges
- A2ABREAK addresses ambiguity in natural-language rules, unreliable open-ended model generation, and the need for sound vulnerability analysis.Direct LLM prompting produced nine candidates across two runs, all rejected on manual review; prior cellular-protocol annotation required approximately 2,800 expert hours [14].Source: §3.4 · pp. 4–5
3.5. Our Solution Approaches
- A2ABREAK separates structural definitions from behavioral rules into independent extraction passes, then reconciles their outputs.The separation prevents type definitions from being mistaken for transitions, or transitions for type definitions.Source: §3.5 · p. 5
- Of 929 extracted statements, 283 (30%) carry transition structure and enter FSM construction; focused input slices and extended thinking support bounded decisions.The framework decomposes analysis into narrow steps rather than generating over the full specification at once.Source: §3.5 · p. 5
- A domain-specific constraint language shapes extraction and analysis, while adversarial verification rejects findings that fail checks for trace grounding, compliance, normative permissibility, or primitive absence.Candidates that fail any verification step are discarded with specific falsifying evidence.Source: §3.5 · p. 5
4. Design of A2ABREAK
A2ABreak formalizes the A2A specification, builds a unified finite-state machine, then analyzes it for protocol-level vulnerabilities, with human checkpoints between stages.
4.1. Stage A: Specification Formalization
- Stage A separately extracts structural definitions and RFC 2119 behavioral rules, reconciles and verifies the statements, and sends the verified corpus through a human checkpoint before FSM construction.Structural extraction captures states, constraints, and implicit transitions; behavioral extraction preserves normative strength, while verification checks fields against the specification and flags errors.Source: §4.1 · pp. 5–6
4.2. Stage B: FSM Construction
- Stage B builds six per-stage FSMs, resolves cross-stage transitions, and merges them into a unified graph of 37 states and 76 transitions.It assigns actors to states to identify trust boundaries, then refines the graph to remove duplicates and orphaned states while preserving referential integrity.Source: §4.2 · p. 6
4.3. Stage C: Security Analysis
- Stage C discovers and validates vulnerabilities under full protocol compliance, requiring executable FSM-grounded attack traces and confirmation that the specification lacks the claimed security primitive.Independent discovery passes generate candidates; automated and expert review then confirm exploitability and discard or downgrade unsupported cases.Source: §4.3 · pp. 6–7
5. Evaluation
The evaluation validates A2ABreak’s vulnerability findings and FSM construction, contrasts it with zero-shot analysis, and quantifies FSM refinement, behavioral complexity across protocol stages, and execution cost.
RQ1: Zero-Shot Comparison
- All nine candidates from two zero-shot runs were rejected during adversarial verification, chiefly because normative requirements already prohibited their attack traces.The evaluation suggests that without an explicitly constructed FSM, the model could not reliably distinguish protocol design gaps from behavior already constrained by the specification.Source: §5 · p. 7
RQ2: Correctness Validation
- 73.3% precision and 84.6% F1 were achieved by A2ABreak’s vulnerability analysis after expert review validated 11 of 16 accepted candidates, identified one duplicate, and overturned four.The metrics use 11 true positives out of 15 non-duplicate candidates; the four false positives were preventable by existing normative rules under full compliance.Source: §5 · p. 7
- The FSM pipeline recovered all 11 TCP protocol states and 19 of 20 transitions, achieving 0.760 precision, 0.950 recall, and 0.844 F1-score.It missed one LISTEN →SYN_SENT edge extracted with a variant event label; TCP served as a proxy because no comparable A2A benchmark exists.Source: §5 · p. 7, Table 1 · p. 7
RQ3: Pipeline Refinement
- Only 283 of 929 verified statements carried transition structure, and refinement reduced the raw graph of 38 states and 245 transitions to 37 states and 76 transitions.Per-stage synthesis removed 168 duplicate transitions, deterministic cleanup collapsed 24 duplicate states, and semantic deduplication resolved four naming equivalences while recovering eight transitions. Structural field-presence and OneOf constraints were filtered before FSM synthesis.Source: §5 · pp. 7–8, Figure 3 · p. 8, Figure 4 · p. 8
RQ4: Specification Complexity Concentration
- Authentication has 21 statements but 16 transitions (0.76 per statement), three times Discovery’s ratio of 0.24; Interruption is smallest by every metric yet encodes the re-entry loop in credential accumulation.The stage-level comparison shows that textual volume does not track behavioral complexity.Source: §5 · p. 8, Figure 5 · p. 8
RQ5: Execution Cost
- $40.97 is the one-pass API cost, with Stages A and B accounting for $34.67 and Stage B2 the most expensive step at $11.64.A single Stage C discovery and verification pass costs $6.30; mechanical stages B1, B4, and D1 incur zero cost.Source: §5 · p. 8, Table 2 · p. 8
6. Security Analysis
The section presents eleven specification-compliant vulnerabilities and details three representative attacks involving shared context, multi-hop delegation, and unverified skill claims.
6. Security Analysis
- 11 validated A2A protocol-level vulnerabilities are exploitable under full specification compliance without implementation flaws or misconfiguration.The section discusses three representative findings spanning discovery, initiation, and interruption.Source: §6 · p. 8, Table 3 · p. 10
- Because contextId has no ownership check, any authenticated client knowing a valid ID can receive victim-informed responses and poison future tasks by injecting into the shared context.The attacker can repeatedly inject messages into the context, deepening the poisoning effect over time.Source: §6 · p. 9, Figure 6 · p. 9
- Because identity and delegation provenance vanish across hops, intermediaries can forward opaque authorization requests and harvest or replay credentials beyond their intended scope.Credential providers lack context for informed authorization decisions, while a compromised intermediate agent can retain and replay forwarded credentials.Source: §6 · p. 9, Figure 7 · p. 10
- Self-asserted, unattested skills let a compliant malicious agent attract sensitive delegated tasks, exfiltrate data, and inject fabricated artifacts that corrupt downstream results.Agent Card signing authenticates who published a card, not whether its advertised skills are truthful.Source: §6 · pp. 9–10, Figure 8 · p. 10
7. Related Work
Related work spans agentic AI security and FSM-based protocol security; the paper positions A2ABreak at their intersection.
7.1. Security of Agentic Systems
- MCP studies cover poisoning, exfiltration, architectural flaws, and lifecycle threats,,, while A2A analyses lack formal or specification-level analysis [11], [12],; broader surveys also omit it,.Source: §7.1 · pp. 10–11
7.2. Protocol Analysis and Security Verification
- Prior FSM security work spans state fuzzing and implementation-derived models,,, formal specification verification,,, extraction benchmarks, and runtime enforcement.Source: §7.2 · p. 11
- No prior work had built a formal A2A state machine or used one for specification-driven vulnerability analysis, which this paper addresses.Source: §7.2 · p. 11
8. Conclusion and Future Work
A2ABreak identifies protocol-level design gaps that yield exploitable vulnerabilities even in compliant deployments. The conclusion calls for scalable simulation, analysis of A2A–MCP security boundaries, and protocol-level mitigations.
Conclusion
- A2ABreak found 11 protocol-level vulnerabilities across four lifecycle phases, exploitable by specification-compliant adversaries without implementation flaws.The findings trace to security properties left as implementation concerns rather than protocol-level invariants, including context ownership, delegation provenance, capability attestation, and credential scoping.Source: §8 · p. 11
A2A Simulation Framework
- A dedicated A2A simulation framework could support reproducible lifecycle testing, automated message-flow fuzzing, and controlled evaluation of mitigations.The paper notes that, to its knowledge, no such framework currently exists.Source: §8 · p. 11
Security Gap Analysis between A2A and MCP
- Future work should analyze A2A–MCP integration risks, including trust propagation, MCP prompt injection effects on delegation, and cross-protocol authorization invariants.The combined protocols create a composite attack surface that neither specification addresses in isolation, with cross-layer privilege escalation a concern.Source: §8 · p. 11
Protocol-Level Mitigations
- Future work should design and formally evaluate backward-compatible protocol extensions to mitigate the vulnerabilities A2ABreak identified.Those vulnerabilities trace to missing primitives in the A2A specification.Source: §8 · p. 11
Appendix A. A2A FSM
Figure 9 presents the extracted unified finite-state machine of the A2A protocol.
Appendix A. A2A FSM
- Figure 9 distinguishes state types, inferred states, transition provenance, and normative strength through node shapes, border styles, edge styles, and colors.Double-circles mark initial states, rectangles terminal states, diamonds errors, ellipses interrupted states, and circles active or intermediate states; dashed borders and edges indicate inferred states and transitions, while edge colors encode normative strength or inter-stage transitions.Source: Appendix A · p. 13, Figure 9 · p. 14