Agent Name Collision Attacks in Multi-Agent Systems

2.1 Identity layers

• A collision becomes vulnerable when a host uses a peer-controlled display name to select a local execution target and silently resolves ambiguity between distinct admitted peers.Selection may depend on registration or list order, normalization, or broker binding state.Source: §1 · p. 1, §2.1 · p. 2

1 Introduction

• Six client-style integrations dispatched requests to B’s client or endpoint, while the brokered target produced one name-derived route collision with delivery dependent on broker configuration.The study evaluates seven implementations across six organizations and does not estimate deployment prevalence.Source: §1 · pp. 1–2
• The proposed fail-closed design routes by stable identity bound to enrollment origin while keeping names as presentation metadata.The paper also distinguishes protocol semantics, implementation behavior, and deployment admission as separate responsibilities.Source: §1 · p. 2

2.2 Attacker capabilities and necessary conditions

• The threat requires shared admission, B’s control of its name, collision precedence, name-derived selection, and a trust difference between A and B.The model assumes an attacker inside the admission boundary, not an unauthenticated Internet attacker.Source: §2.2 · p. 3

2.3 Security outcomes

• Wrong-peer message diversion follows directly from client-side dispatch; credential or tool transfer and later model decisions depend on what happens after routing.The paper separates diversion, authority transfer, and model-mediated decisions as distinct outcomes.Source: §2.3 · pp. 3–4

3.1 Inclusion criteria

• Seven implementations across six maintainer organizations met six inclusion criteria requiring distinguishable peers, unsafe name selection, non-failing duplicate handling, and a production path to a selected target.A code-search hit or dictionary assignment alone was insufficient.Source: §3.1 · p. 4

3.2 Controlled experiments

• Client-style tests gave trusted A and lower-trust B the same name, invoked the selected agent or tool, and recorded which client or endpoint received the request.Controls varied by target; the first-party sample test isolated name-to-route behavior from model selection, and its duplicate-rejection control stopped dispatch.Source: §3.2 · p. 4

3.3 Tests for stronger consequences

• Stronger-consequence tests separately checked credential and tool transfer, privileged action without a new decision, and whether B-controlled output reached a model with a host-only tool.Scripted models made dataflow deterministic but did not measure production-model exploit reliability.Source: §3.3 · p. 5

3.4 Evidence integrity and safety

• The evidence bundle, pinned sources, reproducer patches, and authority tests passed SHA-256 manifest checks on 9 September 2026.Runtime traffic used recording doubles and study-controlled loopback peers; no third-party deployment or production data was contacted.Source: §3.4 · p. 5

4.1 Protocol boundary

• A2A specifies a required human-readable AgentCard.name but neither a stable agent identifier nor name uniqueness or host routing semantics.The omission permits vulnerable mappings but does not require them.Source: §4.1 · p. 5

4.2 Affected paths

• Six client-style paths selected B’s bound client or endpoint instead of A’s, while Solace collapsed both peers onto one broker address.The Solace publication reached the shared route; queue access, ACLs, and binding state determine interception, consumer status, or denial.Source: §4.2 · pp. 5–6, Table 1 · p. 6

4.3 Four implementation forms

• The implementations reached the same identity-binding failure through duplicate tree lookup, name-derived tool identifiers, client-map replacement, and broker naming.The relevant security property is the binding from admitted identity to final execution target, not the choice of data structure.Source: §4.3 · p. 6

4.4 Google ADK reachability boundary

• Google ADK tests establish unsafe duplicate resolution and wrong-client dispatch, but the study did not show a low-privilege agent creating or refreshing the required deployed registry record.The result is a vulnerable routing primitive with conditional attacker reachability, not an end-to-end remote-exploit demonstration.Source: §4.4 · pp. 6–7

5.1 What follows from wrong-peer dispatch

• B can receive A-selected prompts, documents, task metadata, caller context, or conversation state and return a response, creating confidentiality and integrity failures across authorization boundaries.Whether B can enter the routing domain and whether diverted data crosses a meaningful trust boundary remain deployment-specific.Source: §5.1 · p. 7

5.2 Credentials and delegated context

• 0 A-specific credential transfers were demonstrated in the tested client bindings, and the observed UiPath bearer was shared host authentication rather than A-specific.The tested BeeAI handoff clone rebuilt the selected agent without its original HTTP parameters, while the tested AutoDev path exposed no per-agent credential setting[6, 5].Source: §5.2 · p. 7
• Solace forwards the entire a2aUserConfig to a name-derived route, but delegated identity or tokens reach B only if present and B can consume that route.Exclusive and non-exclusive queue modes change delivery behavior[19].Source: §5.2 · p. 7

5.3 Tools and execution

• No tested target transferred an A-owned tool or deterministically executed a privileged action solely because of a collision; UiPath and BeeAI exposed two later model-mediated dataflows instead.B-controlled output became model input where a host-only tool was available and a scripted model chose it; production model reliability was not measured.Source: §5.3 · p. 7

5.4 Severity

• Impact ranges from high-impact disclosure or response substitution to correctness or availability, depending on trust, attached authority, and downstream sinks.Severity should be assessed for the concrete deployment path rather than the abstract presence of a duplicate name.Source: §5.4 · p. 8

6.1 Reference-code propagation

• At least 6 first-party A2A sample paths stored connection objects under card.name and later dispatched by that key[2].A bounded search found 100 indexed matches across 83 public repositories, but those counts measure propagation, not independent implementations or live deployments.Source: §6.1 · p. 8

6.2 Negative controls

• Seven reviewed paths that avoided wrong-peer substitution prevented duplicate display names from silently selecting another transport.The negative-control designs are summarized in Table 3.Source: §6.2 · p. 8, Table 3 · p. 9
• Suffixing can prevent silent replacement but create unstable aliases; a stable authenticated identifier is preferable, and A2A compatibility does not require wrong-peer dispatch.The inspected alternatives support practical implementation-level remediation.Source: §6.2 · p. 9

7 Protocol, Implementation, and Deployment Responsibility

• At the pinned revision, A2A requires a human-readable card name but provides no stable agent identifier or collision semantics, leaving the identity rule across registration, refresh, selection, and dispatch unspecified[1].The name collision is not a wire-protocol attack, and the protocol does not require hosts to route by AgentCard.name.Source: §7 · p. 9
• Affected frameworks own the unsafe resolver that discards endpoint or registry distinctions and dispatches through fail-open ambiguity, while deployments control who can enter the routing domain.The responsibility table is framed around which layer controls each condition.Source: §7 · p. 9, Table 4 · p. 9
• The issue is a protocol-enabled implementation vulnerability class whose reachability and impact depend on deployment, not a universal protocol vulnerability or merely deployer misconfiguration.Framework code can replace a stable distinction with remote text, while some implementations do not make that replacement.Source: §7 · pp. 9–10

• Duplicate rejection stopped dispatch before either peer received the request, while one-variable controls restored dispatch to A.The durable fix is to preserve identity rather than manage winner order.Source: §8 · p. 10
• Route by an operator- or registry-controlled identifier bound to the configured endpoint, authenticated subject, workload identity, or expected signing key.Do not rekey the object after retrieving its Agent Card; a stable but self-asserted identifier can still be stolen.Source: §8 · p. 10
• Keep names presentational: resolve workflow edges, tool registries, authorization, and broker topics through the stable identity.Figure 2 places the enrollment identity on the authority path and display names outside it.Source: §8 · p. 10, Figure 2 · p. 11
• Reject exact and normalization-equivalent duplicate aliases; never select a peer by insertion or list order.If a trusted caller can disambiguate by stable ID, a name-only API may return all candidates.Source: §8 · p. 10
• Attach credentials and delegated scopes only after identity resolution, and carry the stable principal into broker topics, queues, and consumers.Test identical and normalization-equivalent names across distinct origins; fail registration clearly or preserve stable-ID dispatch regardless of order.Source: §8 · p. 10

• The attack model starts after B is admitted or compromised; the study did not establish a universal enrollment bypass.Exploitability also depends on registry permissions, discovery topology, configuration ownership, and broker ACLs.Source: §9 · p. 11
• Google ADK tests manually supplied duplicate local names and did not establish that a low-privilege agent can create or refresh the needed cloud registry record.The result is a vulnerable routing primitive with conditional attacker reachability, not an end-to-end remote exploit.Source: §9 · p. 11
• Solace tests stopped short of production-broker delivery; queue mode, bind order, and ACLs determine whether B receives the message.The source and focused test establish publication of caller configuration to the collided route.Source: §9 · p. 11
• Synthetic credentials and harmless action counters did not demonstrate production secrets, business actions, or universal severity.Scripted-model tests show B’s output can reach a later decision point, but do not estimate whether a real model or policy would invoke a privileged tool.Source: §9 · p. 11
• The seven-target corpus was purposive, and the 83-repository snapshot cannot be converted into counts of vulnerable products, exposed installations, or independent codebases.The search contextualized implementations rather than estimating a population rate.Source: §9 · p. 11
• The prior-art review covered public, indexed material available by 9 September 2026; its bounded search does not establish novelty or priority.Private reports, renamed issues, and unindexed content may exist.Source: §9 · p. 11
• Runtime traffic stayed within in-process doubles or study-controlled loopback peers; no third-party endpoint or account was probed.Results concern exact pinned revisions, not present-tense vulnerability status.Source: §9 · p. 12

• A2A issue 1014 identifies non-unique agent_card.name and proposes a persistent identifier, but does not document the complete fail-open resolver path to deterministic wrong-peer dispatch [11].Source: §10 · p. 12
• LevelBlue’s Agent-in-the-Middle experiment uses model-mediated capability steering, whereas this study tests deterministic identity rebinding after admission [22].The paper says the collision can be tested without model choice.Source: §10 · p. 12
• Palo Alto Networks discusses Agent Card shadowing and impersonation; this paper narrows its contribution to collisions reaching authority-bearing resolvers and wrong routes [17].Source: §10 · p. 12
• The paper aligns the weakness with CWE-706’s resolution to a resource outside the intended control sphere, applied here to remote presentation metadata displacing an enrolled principal [14].Source: §10 · p. 12
• The bounded search found no earlier public description of the complete chain, while ruling out broad novelty claims about malicious cards, impersonation, name collisions, or task capture.Source: §10 · p. 12

11 Conclusion

• The vulnerability arises when a host discards stable admission distinctions, promotes remote presentation names into routing identity, and silently resolves ambiguity to another principal.Seven independently maintained paths reached the failure through agent lookup, tool registration, client maps, or broker naming.Source: §11 · p. 12
• Responsibility spans protocol identity semantics, framework resolver behavior, and deployment control over admission and downstream authority.Safe conforming implementations rule out a universal A2A protocol exploit.Source: §11 · p. 12
• Wrong-peer dispatch was the proven common impact; tested client bindings did not transfer A-specific credentials or A-owned tools.One broker path conditionally forwarded delegated caller context, while two framework paths exposed a separate model-mediated chain.Source: §11 · p. 12
• Preserving origin-bound identity, rejecting ambiguous aliases, and attaching credentials only after resolution removes the measured failure without restricting human-readable names.Source: §11 · p. 12

A Reproducibility Record

• The reproducibility record reports principal executions in Table 5 and describes six client-style test selections of B; broker consumption remained conditional.The study retained pinned revisions, patches, commands, transcripts, and manifests.Source: A Reproducibility Record · p. 13, Table 5 · p. 13

A.1 Evidence integrity

• All four independent manifests passed verification on 9 September 2026, and the deterministic sample test rechecked pinned source hashes.Reported counts come from a structured results file rather than manual re-entry.Source: §A.1 · p. 13

A.2 Reproduction safety

• Resolver behavior can be reproduced with disposable local checkouts, recording clients, or loopback peers using synthetic messages and credentials.Testing deployment admission or broker-consumption edges requires explicit authorization and is outside the artifact.Source: §A.2 · p. 14

Generative AI Usage

• Codex assisted with repository inspection, experiment scripts, evidence normalization, manuscript drafting, and build checks, while the author made substantive decisions and takes responsibility.Codex outputs were not treated as independent evidence or validation.Source: Generative AI Usage · p. 14