Delegated, Not Attributed: eleven protocol-level flaws in A2A

On 9 September 2026 a team from Purdue and UT Dallas published A2ABreak, the first systematic security analysis of the Agent2Agent protocol. It reports eleven protocol-level vulnerabilities, distributed across the four stages of the A2A lifecycle: two in discovery, one in initiation, four in task execution, four in interruption.

The method matters as much as the count. The analysis reached 73.3% precision — eleven confirmed findings out of fifteen candidates, F1 84.6%. The comparison point is the interesting number: a zero-shot language-model pass over the same specification produced nine candidates, and every one of them was rejected on verification. Reading a protocol specification for security is not a summarisation task.

The three that change the threat model

Multi-hop identity loss. A2A establishes identity at the transport layer and carries no delegation context token. When agent A delegates to B and B delegates to C, C receives a task with no chain of custody: it cannot establish who the original principal was, or on whose authority the work is being requested. Every hop is a fresh, unattributable request. This is the finding the rest of the paper orbits, and it is the reason a delegation chain in A2A is a sequence of trusted moments rather than a verifiable lineage.

Cross-client context injection. Context identifiers carry no ownership binding. An authenticated client can submit a task referencing a context it did not create — which both reads the accumulated conversational state of that context and poisons what the rightful owner sees next. Authentication is present; authorisation to a specific context is not.

Auth scope amplification. The scope exercised downstream of a delegation can exceed the scope the delegating party granted. Combined with identity loss, the downstream agent has neither the means to check the ceiling nor the means to attribute what happened under it.

The remaining eight are not filler: SSE streams that keep delivering after the authorising credential is revoked, artifact chunks assembled without integrity verification, a TOCTOU window between access check and access use, webhook targets accepted without destination validation, unattested skill claims in the AgentCard, a JWS trust model that authenticates the issuer but attests nothing about the capabilities the card advertises, delegation cycles with no cycle prevention, and interrupted tasks with no timeout.

Why this was predictable

The specification delegates credential management to implementers. That is a legitimate design choice and it is also a complete description of the outcome: a deployment can ship with no authentication at all and remain conformant. The protocol will not object, and nothing in the conformance story asks.

We wrote about the adjacent version of this in July, when A2A v1.0 shipped signed Agent Cards. Signing closed card spoofing and in-transit tampering, and it closed nothing about what the card says — a correctly signed card with adversarial description fields is still a working injection vector at the agent-selection layer. A2ABreak’s first two findings are the same seam seen from the specification side: identity is attested, capability is not.

Where the paper stops

A2ABreak reports the flaws and explicitly leaves mitigation to future work — concrete protocol extensions, formally evaluated, preserving backward compatibility. The authors have disclosed to the A2A maintainers under the Linux Foundation and are awaiting a response.

That is the correct scope for the paper and it is a gap for anyone running A2A this quarter. Protocol extensions are a 2027 conversation at best. The operational question is narrower and answerable now:

Which of these eleven can you detect by watching traffic you are already allowed to watch, without modifying the protocol, the agents, or the spec?

Our answer is eight. Delegation cycles are structural and visible in the delegation graph before they deadlock — that is cycle detection, not inference. Scope amplification is a diff between granted and exercised scope per edge, and needs no knowledge of the downstream implementation. Post-revocation stream leakage is an interval you can time. Cross-client context injection is an ownership violation visible in the topic graph. Unattested skill claims are reachable through a capability challenge plus behavioural baselining: a cloned agent does not reproduce the timing profile of the agent it clones.

Three are not reachable. Multi-hop identity loss, the JWS capability gap and artifact chunk integrity all require a primitive the protocol does not carry — a delegation token, a capability attestation, a per-chunk digest. No observer recovers information that was never on the wire. Saying so plainly is what makes the other eight worth trusting.

The artifact

The full research page carries the eleven findings mapped against the OWASP Agentic Top 10, the probe definition for each of the eight observable ones, and the reason each of the three gaps is a gap. It ships as SARIF 2.1.0 — eleven rules, two taxonomies, A2ABreak identifiers bound as subset and ASI categories as relevant, with the three gaps present in results as notApplicable with a stated reason rather than quietly omitted.

A coverage claim you cannot check is not a coverage claim. That principle is why the gaps are in the file.