- 원문: arXiv:2609.27624
- 저자: Adithyan Arun Kumar
- 공개일: 2026-09-23
- 분야: Multi-Agent Security, A2A, Identity, Routing
- Tags: AgentNameCollision, A2A, MultiAgent, IdentityBinding, WrongPeerDispatch
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
이 연구는 A2A Agent Card의 사람이 읽는 name을 안정적인 보안 식별자처럼 사용하면, 서로 다른 두 에이전트가 같은 이름을 광고할 때 신뢰된 에이전트 A에게 보낼 요청이 공격자 에이전트 B의 클라이언트·도구·엔드포인트·브로커 경로로 전달될 수 있음을 보입니다. 6개 조직이 관리하는 7개 오픈소스 구현 경로를 고정된 revision에서 조사했고, 클라이언트형 통합 6개에서는 B로의 wrong-peer dispatch를 직접 관찰했으며 브로커형 1개에서는 이름에서 파생된 공유 경로까지 입증했습니다.
핵심 입증 범위는 요청 오배송과 응답 무결성 훼손입니다. 테스트된 클라이언트 바인딩에서 A 전용 자격증명이나 A 소유 도구가 B로 자동 이전된 사례는 0건이었고, 브로커 경로의 최종 소비와 위임 토큰 노출은 배포 설정에 따라 달라집니다. 따라서 이를 모든 A2A 구현의 원격 권한 상승으로 표현하면 과장입니다.
연구 배경
A2A 기반 호스트는 원격 Agent Card를 읽어 로컬 에이전트, 함수 도구, 워크플로 노드, 레지스트리 항목 또는 메시지 브로커 주소로 변환합니다. A2A 명세의 AgentCard.name은 사람이 읽기 위한 필수 메타데이터지만, 고유하거나 지속적인 식별자로 정의되지 않고 이름 충돌 처리 규칙도 없습니다.
안전한 설계는 등록 시 확인한 엔드포인트, 레지스트리 주체, workload identity 또는 서명 키에 안정적인 내부 ID를 묶고 최종 dispatch까지 그 결합을 유지해야 합니다. 연구는 일부 구현이 이 구분을 버리고 원격 피어가 정한 표시 이름으로 로컬 라우팅 객체를 다시 키잉한다는 점에 주목합니다.
공격 모델 / 전제 조건
공격자는 인터넷에서 무인증으로 바로 들어오는 외부인이 아니라 이미 같은 routing domain에 등록됐거나 침해된 낮은 신뢰도의 피어 B입니다. 신뢰 피어 A와 B가 같은 이름을 광고하고, B가 우선순위를 얻은 상태에서 호출자·워크플로·모델이 그 모호한 이름을 선택해야 합니다.
필수 조건은 다섯 가지입니다.
- A와 B가 동일 호스트·레지스트리·도구 집합·워크플로·브로커 namespace에 함께 들어와 있어야 합니다.
- B가 자신의 Agent Card 이름을 정하거나 갱신할 수 있어야 합니다.
- first-match, later replacement, normalization collision 또는 broker binding을 통해 B가 충돌 우선권을 얻어야 합니다.
- 이후 호출 경로가 안정적 ID나 고정 엔드포인트가 아니라 충돌한 이름으로 대상을 골라야 합니다.
- A와 B가 받도록 허용된 데이터나 권한에 차이가 있어야 기밀성·무결성 영향이 발생합니다.
사용자 상호작용은 필수가 아니며 race condition도 필요하지 않습니다. 다만 자동 등록 우회는 입증되지 않았으므로, B가 같은 신뢰 영역에 들어오는 admission·refresh 경로는 배포별로 별도 검증해야 합니다.
비판적 검토 / 아쉬운 점
가장 큰 불확실성은 실제 공격자가 B를 등록하거나 이름을 갱신할 수 있는지입니다. 특히 Google ADK 테스트는 duplicate local name 처리와 B 클라이언트 선택을 입증했지만, 낮은 권한의 피어가 실제 Google Cloud Agent Registry 레코드를 생성·갱신하는 end-to-end 경로는 검증하지 않았습니다. 제품별 admission API, 권한 모델, refresh 정책을 포함한 실배포 테스트가 보완돼야 합니다.
두 번째로 7개 대상은 의도적으로 고른 purposive corpus라 생태계의 취약 비율을 뜻하지 않습니다. 정확한 할당 패턴을 GitHub에서 검색한 83개 저장소도 fork·교육 자료·샘플 파생물을 포함하므로 83개 독립 제품이나 운영 배포로 환산할 수 없습니다. 패키지 사용량과 실제 설정을 층화한 표본이 있어야 prevalence를 말할 수 있습니다.
세 번째로 영향 강도가 구현마다 다릅니다. 클라이언트형 6개는 B 경계까지 요청이 도달했지만, Solace는 충돌한 topic·queue 주소로 publish되는 지점까지만 확인했고 B의 최종 소비는 queue mode, bind order, ACL에 달려 있습니다. UiPath와 BeeAI의 2차 모델·도구 흐름도 B 출력이 새 의사결정 지점에 들어간다는 plumbing만 보여 주며 실제 privileged tool 실행률을 측정하지 않았습니다.
강점은 이러한 한계를 논문이 직접 분리했다는 점입니다. wrong-peer dispatch, credential transfer, authority transfer, secondary execution을 같은 취약점 효과로 뭉치지 않고 각각 별도의 증거를 요구합니다.
핵심 Root Cause
구조적 원인은 표시용 이름과 권한을 갖는 보안 주체를 같은 식별자로 취급한 것입니다. 호스트는 처음에는 A와 B를 엔드포인트·레지스트리 레코드·리소스 ID로 구분할 수 있지만, Agent Card를 읽은 뒤 두 객체를 원격 입력인 card.name 아래 다시 저장하거나 도구 이름·workflow selector·broker route로 변환하면서 그 구분을 잃습니다.
깨진 보안 불변조건은 “호출자가 등록된 주체 A를 선택하면 최종 transport와 권한 부착도 A에 묶여 있어야 한다”입니다. 충돌을 경고만 하고 계속 실행하거나, 삽입 순서·목록 순서·정규화 결과로 승자를 고르면 표시 문자열이 다른 principal의 실행 경로를 선택하게 됩니다. 이는 논문이 연결한 CWE-706, 즉 잘못 해석된 이름 또는 참조 사용과 맞닿아 있습니다.
핵심 공격 원리
신뢰 피어 A가 payments라는 이름으로 등록된 뒤 B도 같은 이름을 광고합니다. 구현이 첫 항목을 고르면 B가 앞에 오도록 등록 순서를 조절하고, map overwrite라면 B를 나중에 등록하며, 함수 도구 이름을 정규화한다면 exact 또는 normalization-equivalent collision을 만듭니다.
호출자는 여전히 payments를 A라고 생각하지만 resolver가 반환하는 것은 B에 묶인 client closure, loopback URL, 함수 도구 또는 name-derived broker route입니다. 공격자는 A의 서명 키나 transport credential을 위조할 필요가 없고, host 내부 이름 해석을 통해 요청·문맥·응답 경로를 가로챕니다.
공격 흐름
- 운영자 또는 레지스트리가 신뢰 피어 A를 안정적인 원점 정보와 함께 등록합니다.
- 공격자 피어 B가 같은 표시 이름 또는 정규화 후 같은 로컬 도구 이름을 가진 Agent Card를 등록·갱신합니다.
- 호스트가 두 원점을
card.name기반 agent tree, map, tool registry, workflow node, topic 또는 queue로 접습니다. - 중복을 거부하지 않고 first-match, last-write-wins, retained tool 또는 공유 broker route로 한쪽을 선택합니다.
- 호출자가 A의 이름을 선택하면 B에 묶인 transport나 경로가 사용됩니다.
- B는 A에게 의도된 prompt, 문서 조각, task metadata, caller context를 받고 응답을 대체할 수 있습니다.
- 자격증명·위임 토큰·호스트 도구 사용은 라우팅 이후 무엇을 붙이는지에 따라 별도 분기됩니다.
성공 조건 / 실패 조건
성공하려면 B가 같은 routing domain에 admitted되고 이름을 제어하며, 충돌에서 이길 수 있고, 실제 호출이 이름 기반 resolver를 지나며, A와 B 사이에 신뢰 차이가 있어야 합니다. 어느 하나라도 빠지면 기밀성·무결성 공격은 성립하지 않거나 단순 correctness·availability 문제로 축소됩니다.
고정 엔드포인트로 직접 전송하거나, 등록 origin에 묶인 stable ID로 dispatch하거나, exact·정규화 동등 alias를 fail-closed로 거부하면 실패합니다. 중복 시 경고만 남기는 것은 실패 조건이 아닙니다. 모호한 graph를 계속 사용할 수 있다면 공격 경로가 유지됩니다.
연구진의 실험 환경
연구진은 6개 조직의 7개 구현 경로를 exact revision에 고정했습니다. Google ADK Python 2.8.0, Google ADK TypeScript 2.0.0, UiPath LangChain 0.17.3, BeeAI Framework 0.1.83, Solace Agent Mesh 1.28.8, Mozilla Any-Agent 1.18.0, AutoDev 2.4.1 lineage가 대상입니다.
테스트는 두 synthetic 또는 loopback 피어를 만들고 동일 이름을 광고하게 한 뒤 어느 client·endpoint가 호출되는지 기록했습니다. 실제 외부 서비스나 사용자 데이터는 사용하지 않았고 recording client, in-process double, controlled loopback HTTP를 사용했습니다. 2026-09-09에 보존된 evidence bundle과 7개 reproducer·authority test manifest의 SHA-256 검증이 통과했습니다.
주요 실험 결과
클라이언트형 통합 6개 모두에서 A 이름으로 선택한 요청이 B의 client 또는 loopback endpoint로 전달됐고 A 바인딩은 호출되지 않았습니다. Solace에서는 registry replacement와 production publish가 동일한 이름 기반 route로 수렴했지만 최종 소비는 브로커 설정에 의존했습니다.
테스트된 ADK Python·TypeScript, BeeAI, Any-Agent, AutoDev 경로에서 A 전용 transport credential이 B 경계에 나타난 경우는 0건이었습니다. A 소유 in-process tool이 B로 직접 이전되거나 이름 충돌만으로 privileged action이 결정적으로 실행된 사례도 0건입니다. Solace의 a2aUserConfig는 caller identity·scope·delegated token을 담을 수 있어 1개의 조건부 delegated-context 경로로 분류됐습니다.
UiPath와 BeeAI에서는 B가 만든 출력이 host-only tool이 있는 다음 모델 결정 지점으로 들어가는 2개의 2차 dataflow가 확인됐습니다. 이는 compound prompt-injection 가능성을 보여 주지만, production model에서 도구가 실행될 확률이나 정책 우회 성공률을 뜻하지 않습니다.
실제 발견된 취약점 / 사례
- Google ADK Python과 TypeScript는 duplicate local name을 허용하거나 경고한 뒤 first match를 선택해 B의 A2A client를 호출했습니다. Registry helper가 card content에서 local name을 가져오는 production 경로는 존재하지만 공격자 admission은 조건부입니다.
- UiPath LangChain은 Agent Card에서 만든 함수 도구 이름이 충돌할 때 뒤의 transport가 앞의 도구를 대체했습니다.
- BeeAI는 handoff tool과 requirement selector에서 first-match가 B의 card URL로 client를 만들었습니다.
- Mozilla Any-Agent는
call_{card-name}도구 충돌에서 OpenAI Agents SDK 0.20.0의 warn 정책이 마지막 도구를 유지해 B loopback endpoint로 JSON-RPC를 보냈습니다. - AutoDev는 card와 client map을 같은 이름으로 keying해 뒤의 B가 A를 대체했습니다.
- Solace Agent Mesh는 card registry key, request topic, queue identity가 이름에 수렴해 공유 route로 publish했습니다. interception인지 standby인지 denial인지는 queue와 ACL에 달려 있습니다.
저자 주장 vs 실제 증명 범위
저자의 핵심 주장인 “표시 이름 충돌이 여러 독립 구현에서 안정적인 identity-to-transport binding을 깨뜨릴 수 있다”는 소스 추적과 통제 테스트가 뒷받침합니다. 또한 안전한 A2A 호환 구현 7개가 중복 거부, 명시적 로컬 ID, suffix alias, 운영자 제어 ID를 사용했다는 negative control은 이 문제가 A2A 호환성의 필연적 결과가 아님을 보여 줍니다.
반면 모든 A2A 구현이 취약하거나, 인터넷 공격자가 자동 등록할 수 있거나, A의 credential·tool·권한이 B로 상속된다는 주장은 입증되지 않았습니다. 공개 저장소 검색 결과도 실제 취약 배포 수가 아닙니다. 논문이 보여 준 것은 반복되는 implementation vulnerability class와 조건부 배포 영향입니다.
기존 공격 / 기존 점검 방식과의 차이
기존 Agent Card shadowing이나 Agent-in-the-Middle 연구는 capability 설명을 과장해 모델이 공격자 에이전트를 선택하도록 유도합니다. 이 연구의 핵심은 모델 선택이 아니라 등록 이후 deterministic local resolver가 동일 이름을 잘못된 principal에 결합한다는 점입니다. 모델 없이도 재현할 수 있습니다.
일반적인 중복 key 점검이 map overwrite 한 군데만 찾는다면, 이 연구는 agent tree, generated function tool, workflow selector, client map, topic, queue까지 “최종 dispatch binding”을 따라갑니다. 데이터 구조보다 admission identity가 실행 대상까지 유지되는지가 점검 단위입니다.
연구의 한계와 주의해서 볼 부분
저자가 인정한 한계는 실제 registry admission·refresh 권한, Solace production broker delivery, 실제 secret·business action 부재, scripted model을 사용한 2차 실행, purposive corpus와 검색 표본의 비대표성입니다. 결과는 현재 취약 상태가 아니라 고정 revision의 동작을 보고합니다.
추가로 이름 충돌이 존재해도 모든 routed data가 민감한 것은 아닙니다. tenant·업무별 authorization 차이와 실제 payload classification을 함께 봐야 severity를 정할 수 있습니다. 반대로 공유 host authentication이나 delegated caller context처럼 A 전용 secret이 아니더라도 B에게 허용되지 않은 권한이 붙을 수 있으므로 “credential theft 0건”을 영향 없음으로 해석해서도 안 됩니다.
공개 PoC / Exploit / Tool / Artifact 분석
저자가 공개한 agent-name-collision-attacks 저장소는 논문, 정규화 결과, source anchor, negative control, focused reproducer patch, SHA-256 manifest와 verify_archive.py를 포함합니다. Python 3.10 이상에서 archive integrity를 검증할 수 있고, 각 reproducer는 정확한 upstream revision과 테스트 명령을 명시합니다.
저장소는 실제 제품 공격 도구가 아니라 disposable checkout, recording client, loopback peer를 이용해 name-to-route binding을 재현하는 연구 artifact입니다. README도 Google ADK admission과 Solace consumption을 조건부로 명시하며, 논문의 주장 경계를 구현 수준에서 확인할 수 있게 합니다. 2026-09-25 확인 시 공개 접근이 가능했습니다.
레드팀 / 모의해킹에서 어떻게 활용할까
점검 목표는 이름 충돌 자체를 만드는 데 그치지 않고 “운영자가 선택한 stable identity가 최종 endpoint·credential·broker principal까지 유지되는가”를 확인하는 것입니다. 승인된 테스트 registry에 서로 다른 두 원점의 에이전트를 동일·대소문자 변형·Unicode 정규화 동등 이름으로 등록하고 순서를 바꿔 같은 요청을 반복합니다.
관찰 지점은 등록 레코드, 로컬 alias, generated tool name, workflow edge, selected client, 실제 destination URL, attached credential source, broker topic·queue·consumer입니다. 의도하지 않은 피어로 payload가 전송되거나 이름 충돌 후 winner가 순서에 따라 바뀌면 실패입니다. 실제 데이터나 공유 브로커로 확장하지 말고 loopback·synthetic token에서 중단합니다.
실제 점검 시 추가할 체크리스트
- Agent Card의
name이 UI 표시 외에 map key, tool name, workflow selector, topic, queue, ACL에 쓰이는지 추적합니다. - 등록 시점의 endpoint·registry subject·workload identity·signing key와 내부 stable ID가 묶이는지 확인합니다.
- exact, 대소문자, 공백, punctuation, Unicode normalization 충돌을 각각 시험합니다.
- first-match, last-write-wins, warn-and-continue, 자동 suffix가 최종 dispatch에 미치는 영향을 기록합니다.
- 등록 순서와 refresh 순서를 바꿔도 동일 stable ID가 같은 transport를 선택하는지 확인합니다.
- B 경계에서 prompt, 문서, conversation state, caller context, token, header를 분리 관찰합니다.
- credential과 scope가 이름 해석 전이 아니라 인증된 identity 확정 후 부착되는지 확인합니다.
- broker topic·queue·consumer identity와 ACL이 표시 이름이 아닌 principal ID를 사용하는지 확인합니다.
- 모호한 alias는 명확히 거부되고 경고 후 실행되지 않는지 확인합니다.
- 중복 등록 실패 시 audit log와 운영자 알림이 충분한지 확인합니다.
실무 가치 평가
실무 가치는 높습니다. 특별한 모델 jailbreak 없이도 일반적인 이름 해석 버그가 에이전트 생태계에서 기밀성·응답 무결성 문제로 이어질 수 있음을 여러 framework 형태로 보여 줍니다. 특히 “Agent Card의 이름은 보안 identity가 아니다”라는 원칙을 아키텍처 리뷰와 regression test로 바로 옮길 수 있습니다.
다만 취약점 등급은 제품명이 아니라 구체적인 admission·dispatch·authority 경로로 산정해야 합니다. B가 들어올 수 없거나 A와 B의 데이터 권한이 동일하면 영향은 낮아지고, 민감 문맥이나 delegated scope가 붙으면 높아집니다.
결론
Agent name collision의 본질은 중복 문자열이 아니라 등록된 principal과 최종 실행 대상의 결합이 원격 표시 메타데이터 때문에 끊기는 것입니다. 해결책은 origin-bound stable ID로 라우팅하고, 이름은 표시용으로만 유지하며, 호환상 alias가 필요하면 모호성을 fail-closed로 거부하는 것입니다.
논문은 7개 구현 경로에서 반복되는 wrong-peer dispatch 유형을 충분히 입증했지만, 이를 보편적 A2A protocol exploit이나 자동 credential theft로 확대하지 않습니다. 이 증거 경계를 유지하는 것이 실무 적용에서도 가장 중요합니다.
댓글