Imagine a building where every office door has a name plate, but no locks and no ID checks. Anyone can unscrew the plate reading "Dr. Smith" and screw it onto their own door. Every patient who walks in looking for Dr. Smith ends up in the wrong office. That is the mechanism this paper documents in Google's Agent-to-Agent (A2A) protocol ecosystem: Agent Cards carry human-readable names with zero collision semantics, and hosts treat those names as routing identifiers anyway. The committed claim is narrow and well-scoped: agent name collisions in A2A multi-agent systems constitute a recurring implementation vulnerability class—not a protocol exploit, not a universal privilege-escalation chain. The authors traced registration-through-dispatch paths across seven pinned open-source revisions and found that six client-style integrations routed a request addressed to a trusted peer's name to an attacker-controlled endpoint instead. A seventh, brokered implementation collapsed both peers onto a single name-derived route, with outcome depending on queue and access-control state. What's important is what the paper explicitly rules out. No A2A-specific credential transfer was observed in the tested client bindings. No direct transfer of attacker-owned tools occurred. The broker path forwards a caller-configuration object, but delegated identity or tokens only reach the impersonator if they're present and consumable. Two additional paths expose model-mediated decisions rather than direct execution authority. This is wrong-peer dispatch, not privilege inheritance—a critical distinction that keeps the finding honest. The architectural contribution is a taxonomy of the vulnerability surface: the protocol specifies names as metadata, implementations promote them to routing keys, and deployments fail to enforce origin-bound stable identities. The paper assigns different responsibilities to each layer. The protocol needs collision semantics. Implementations need origin-bound routing. Deployments need alias rejection. Integrity-wise, this is isolated regression testing on pinned revisions of open-source code, not a red-team exercise against production deployments. The authors are careful to state they are not counting vulnerable deployments—they are characterizing a vulnerability class. That honesty is load-bearing: it prevents the finding from being over-generalized into "A2A is broken" while still establishing a concrete, reproducible problem. The milestone question for multi-agent security is whether the A2A spec itself will adopt collision semantics and origin-bound identity as normative requirements—or whether this remains an implementation-level game of whack-a-mole. The paper's fix recommendations (route by origin-bound stable identity, keep names presentational, reject ambiguous aliases) are simple to state and hard to enforce across a fragmented ecosystem of host implementations. The obvious experiment not run: adversarial testing against closed-source or production-grade A2A hosts (Google's own, enterprise integrations). The honest read is access and scope—academic researchers testing pinned open-source revisions is what's feasible; production red-teaming requires vendor cooperation or bug-bounty access. The question is whether the same name-as-routing-key pattern persists in hardened implementations.
