Name collisions cause wrong routing in multi-agent systems
Agent Name Collision Attacks in Multi-Agent Systems
Cryptography and SecurityMultiagent Systems
Summary
Multi-agent systems let devices or programs communicate by referring to each other with names. The authors found that some systems mistakenly treat these names as unique identifiers when they aren’t meant to be. This mistake can cause a message intended for a trusted party to be delivered to an attacker instead, but it does not let the attacker automatically gain permissions or credentials. The problem happens because the system uses human-friendly names for routing instead of stable, origin-based IDs. The authors suggest using stable identities for routing and keeping names only for display.
What this means in practice
- •For system integrators: Avoid using human-readable names for routing in multi-agent systems and switch to stable origin-bound identifiers to prevent wrong-peer message delivery.
- •For network security teams: Detect and mitigate risks from name collisions in multi-agent routing to reduce message interception or denial of service.
Authors
Adithyan Arun Kumar
Abstract
Multi-agent hosts turn remote Agent Cards into local agents, tools, workflow targets, and broker routes. A2A defines the card's name as human-readable metadata, not as a stable identity, and specifies no collision semantics. The security failure begins when a host nevertheless uses that remote name as a local routing identifier. We traced registration through dispatch and ran isolated regression tests at seven pinned open-source revisions. Six client-style integrations selected an attacker-controlled peer's client or loopback endpoint for a request addressed to a trusted peer's name. A seventh, brokered implementation collapsed both peers onto one name-derived route; queue and access-control state determine whether the result is interception or denial. The common result is wrong-peer dispatch, not universal privilege inheritance. Synthetic credential and tool tests found no A-specific credential transfer in the tested client bindings and no direct transfer of A-owned tools. The broker path forwards a caller-configuration object; delegated identity or tokens reach B only if present and B can consume the route. Two other paths expose a later, model-mediated decision rather than direct execution authority. The necessary conditions assign different responsibilities to the protocol, implementations, and deployments. Hosts should route by an origin-bound stable identity, keep names presentational, and reject ambiguous aliases. The evidence establishes a recurring implementation vulnerability class, not a universal A2A protocol exploit or a count of vulnerable deployments.