𝗔𝟮𝗔 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗔𝘂𝘁𝗵: 𝗪𝗵𝘆 𝘁𝗵𝗲 𝗦𝗽𝗲𝗰 𝗶𝘀 𝗧𝗵𝗶𝗻 𝗮𝗻𝗱 𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗛𝗼𝗹𝗲𝘀 𝗔𝗿𝗲

A2A(Agent2Agent) 프로토콜은 AI 에이전트 통신의 표준이 되어가고 있습니다. Google은 2025년에 이를 발표했으며, 현재는 Linux Foundation에서 운영하고 있습니다.

명세(spec)의 인증 섹션을 살펴보았을 때, 거의 아무것도 찾을 수 없었습니다. 새로운 인증 메커니즘을 정의하지 않고, 단순히 OAuth2, OpenID Connect 또는 mTLS와 같은 기존 표준을 사용하라고 안내할 뿐입니다.

이러한 빈약함은 의도된 것입니다. A2A는 프레임워크를 정의할 뿐, 그 내용은 다른 표준에 위임합니다. 주의를 기울이지 않으면 이로 인해 보안 허점이 발생할 수 있습니다.

𝗛𝗼𝘄 𝗔𝟮𝗔 𝗪𝗼𝗿𝗸𝘀 A2A는 한 에이전트가 다른 에이전트에게 작업을 전달하기 위한 프로토콜입니다. HTTP 기반의 JSON-RPC를 사용합니다.

• 클라이언트 에이전트(Client Agent): 요청을 보내는 에이전트. • 원격 에이전트(Remote Agent): 작업을 받는 에이전트. • 에이전트 카드(Agent Card): 원격 에이전트가 자신의 기능과 인증 요구 사항을 나열하는 JSON 파일.

에이전트 카드가 가장 중요한 부분입니다. 클라이언트는 요청을 보내기 전, 인증 방법을 파악하기 위해 이 카드를 먼저 읽습니다.

𝗧𝗵𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗛𝗼𝗹𝗲𝘀 A2A는 몇 가지 중요한 작업을 구현자에게 맡깁니다. 이를 제대로 처리하지 않으면 에이전트가 위험에 처할 수 있습니다.

  • 카드 변조(Card Tampering): 에이전트 카드에 서명하는 것은 선택 사항(MAY)입니다. 서명을 하지 않으면 공격자가 에이전트를 악성 서버로 리다이렉트할 수 있습니다.
  • 재전송 공격(Replay Attacks): A2A에는 토큰을 특정 클라이언트에 바인딩하는 방법이 없습니다. 누군가 베어러 토큰(bearer token)을 훔치면 귀하의 에이전트로 사칭할 수 있습니다.
  • 권한 상승(Privilege Escalation): 권한 부여(Authorization)는 외부 인프라에 맡겨져 있습니다. 스킬별 체크(per-skill checks)를 강제하지 않으면, "읽기 전용" 에이전트가 "쓰기" 권한을 얻을 수도 있습니다.
  • ID 체이닝(Identity Chaining): A2A는 사용자의 ID가 에이전트 체인을 통해 어떻게 전달되는지 처리하지 않습니다.

𝗛𝗼𝘄 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗜𝘁 𝗦𝗮𝗳𝗲𝗹𝘆 명세에만 의존하지 마십시오. 선택 사항인 규칙들을 필수 사항으로 만들어야 합니다.

• 항상 에이전트 카드에 서명하십시오. JWS와 JCS를 사용하세요. • 에이전트 간 경로에는 mTLS를 사용하십시오. 이를 통해 토큰 탈취만으로 시스템이 침해되는 것을 방지할 수 있습니다. • API 게이트웨이에서 스킬별 권한 부여를 강제하십시오. • 재전송 공격을 막기 위해 송신자 제한 토큰(sender-constrained tokens, 예: DPoP)을 사용하십시오.

A2A는 배관과 같습니다. 보안은 그 배관을 통해 흐르는 물에서 나옵니다. 빈틈을 메우기 위해 SPIFFE나 Identity Chaining과 같이 검증된 표준을 사용하십시오.

Source: https://dev.to/kanywst/a2a-protocol-auth-taken-apart-why-the-spec-is-thin-and-where-that-leaves-holes-22ii

Optional learning community: https://t.me/GyaanSetuAi