A2A Agent Security Literature Map

한 줄 결론

A2A는 에이전트 간 “말”만 이어주는 채널이 아니라 신뢰, 권한, artifact, task lifecycle, 비용과 책임을 함께 전파하는 채널이며, 로컬 에이전트는 실제 컴퓨터 권한을 가진 실행 주체다.

발표의 주장과 연결

발표의 중심 문장은 “A2A에 publish하는 것은 기능이 아니라 제한된 권한과 정체성을 가진 대리 행위자를 신뢰 경계 밖으로 내보내는 일”이다. 이 문헌 묶음은 그 주장을 보안 관점에서 보강한다.

  • A2ASecBench는 A2A 자체의 공격면을 보여준다. AgentCard, capability, task lifecycle, artifact가 모두 공격 표면이다.
  • OpenClaw security analysis, ClawWorm, OpenClaw FASA는 로컬 개인형 에이전트가 shell, filesystem, browser, messaging, skill marketplace와 연결될 때 실행 권한의 문제가 된다는 점을 보여준다.
  • Skill-Inject, Skill supply-chain poisoning, Malicious agent skills는 “전문 기능을 skill로 가져오는 방향이 자연스럽다”는 발표 주장에 필요한 단서를 준다. skill은 편리하지만 supply-chain 공격면이 된다.
  • CaMeLs, AgentSentinel, RedTeamCUA는 에이전트가 OS와 웹을 직접 조작할 때, prompt safety가 아니라 system-level security가 필요하다는 점을 보강한다.

문헌 지도의 4개 축

1. A2A 프로토콜의 공격면

A2A는 capability discovery, AgentCard, task submission/subscription, artifact exchange를 표준화한다. 그래서 공격자는 다음 위치를 노린다.

  • 발견 단계: AgentCard Spoofing, Capability Cloaking.
  • 실행 단계: Cycle Overflow, Half-Open Task Flooding.
  • 권한 경계 단계: Agent-Side Request Forgery.
  • 산출물 단계: Artifact-Triggered Script Injection.

발표 문장으로 바꾸면: “A2A에서 agent card는 단순 소개 페이지가 아니라 신뢰 경계의 입구다.”

2. 로컬 에이전트는 실행 권한을 가진 principal

OpenClaw류 개인 에이전트는 LLM reasoning을 shell, filesystem, browser, Docker, messaging channel에 연결한다. 이때 LLM tool call은 host process까지 이어지는 제어 신호가 된다.

중요한 함의:

  • 로컬 에이전트가 A2A peer가 되면 원격 agent가 간접적으로 내 로컬 실행 표면에 영향을 줄 수 있다.
  • “내 에이전트가 판단했다”는 말은 충분하지 않다. 어떤 provenance의 입력이 어떤 권한으로 실행됐는지를 추적해야 한다.
  • skill, memory, AGENTS/CLAUDE-style instruction file은 코드처럼 취급해야 한다.

3. Skill/MCP는 기능 흡수의 경로이자 supply-chain 공격면

발표에서는 많은 전문 기능이 A2A agent보다 skill/MCP로 내 환경 안에 들어올 수 있다고 말한다. 하지만 이 문헌들은 그 경로가 안전하려면 다음 조건이 필요하다고 말한다.

  • skill provenance, publisher identity, version pinning.
  • skill별 capability permission.
  • 문서와 코드 예제를 신뢰된 실행 지시로 바로 재사용하지 않는 구조.
  • instruction file에 들어온 내용을 user/system/internal/inter-agent/external provenance로 구분.

즉 “기능은 내 환경 안으로 가져오는 편이 자연스럽다”는 주장은 “내 환경 안으로 가져온 기능을 supply-chain artifact로 검증해야 한다”는 보안 조건과 함께 가야 한다.

4. Computer-use agent는 prompt defense만으로는 부족하다

CUA는 화면을 보고 클릭하고 명령을 실행한다. 이때 악성 웹페이지, 문서, UI 텍스트, 파일 내용이 agent 행동을 바꿀 수 있다.

방어 방향은 두 계열이다.

  • 구조적 격리: trusted planner와 untrusted observation을 분리하고, planner가 허용한 control flow만 실행하게 한다.
  • 실시간 집행: 민감한 OS-level side effect를 감지하고, 실행 전 감사하거나 차단한다.

발표 문장으로 바꾸면: “A2A agent가 외부 세계와 상호작용할수록 보안 단위는 prompt가 아니라 실행 권한, side effect, 감사 로그가 된다.”

발표에서 바로 쓸 수 있는 비교

질문Skill/MCPA2A Agent
무엇을 확장하나내 agent의 기능과 도구 접근다른 주체와의 상호작용
주된 위험supply-chain poisoning, tool misuse, local secret exposureidentity spoofing, capability misrepresentation, task/artifact abuse
실행 책임대체로 내 agent runtime과 내 승인 흐름양쪽 agent와 각자의 운영 주체
필요한 방어skill provenance, sandbox, least privilege, context provenancesigned AgentCard, scoped/short-lived token, capability attestation, artifact sanitization

발표에 넣을 보강 문장

  • “A2A는 기능 marketplace가 아니라 신뢰 경계 밖의 대리인 네트워크다.”
  • “AgentCard는 capability 광고가 아니라 identity와 권한에 대한 보안 claim이다.”
  • “로컬 에이전트가 A2A에 붙는 순간, A2A 메시지는 내 컴퓨터의 실행 표면과 연결될 수 있다.”
  • “Skill은 전문성을 내 환경 안으로 가져오는 좋은 방식이지만, supply chain 검증 없이는 instruction-level malware가 된다.”
  • “A2A의 안전성은 OAuth/JWT 하나로 끝나지 않는다. capability attestation, artifact sanitization, lifecycle bounds, provenance-aware execution이 필요하다.”

아직 빈틈

  • 이 문헌들은 A2A와 OpenClaw/Codex/Claude Code를 실제로 한 시스템에 연결한 end-to-end 실험을 하나로 완결하지는 않는다.
  • 따라서 발표에서는 “단일 논문이 모든 위험을 입증한다”보다 “A2A 프로토콜 공격면 + 로컬 에이전트 실행권한 + skill supply-chain 위험이 결합될 수 있다”로 말하는 편이 정확하다.
  • Web3/DID/payment/reputation까지 직접 다루는 논문은 이 묶음에 많지 않다. 발표의 Web3 파트는 보안 문헌에서 도출한 요구사항을 신원, 서명, 한도, 감사 로그의 설계 문제로 연결하는 식이 좋다.