Six of seven A2A integrations misroute on duplicate names

Six of seven tested A2A integrations routed messages meant for a trusted agent to an attacker-controlled endpoint instead, per a paper testing A2A agent name collisions.

Hosts that resolve which agent handles a request by matching the Agent Card's name field inherit the flaw automatically. A2A defines that field as human-readable metadata with no uniqueness guarantee.

A seventh implementation was built around a broker instead of direct peer connections. It failed differently: it merged both agents onto a single route rather than picking the wrong one. The paper is careful about scope. None of the tested bindings let an attacker take over credentials or tool access. The confirmed harm is wrong-peer dispatch: a request reaches an agent the caller didn't intend.

That six of seven implementations got this wrong points to a spec-level gap, not one team's mistake. A2A's Agent Card was written as descriptive metadata. Most hosts wired it up as a routing key anyway, and each one inherited the same hole without a shared fix.

The paper tests seven pinned revisions. It doesn't say whether newer releases or agent SDKs built since carry the same gap.