A2A 보안 메커니즘: 에이전트 상호 신뢰를 위한 출입 통제 시스템

두 AI가 서로 “전화”를 한다고 할 때, 가장 무서운 건 뭘까? 끝없이 수다를 떠는 게 아니라, 낯선 사람이 아는 척하고 문을 두드리는 거다.

보안 설계 원칙: 문을 열기 전에 먼저 잠근다

새집에 이사했을 때, 커튼부터 다는 게 아니라 현관문 잠금장치부터 바꾸는 걸 떠올려보자. A2A 프로토콜 설계자도 같은 생각을 했다 — 기본값은 안전, 모든 완화 조치는 명시적으로만 허용. 이 메커니즘은 완벽한 출입 통제 시스템과 같다: 자물쇠(token), 출입 카드(피어 키), 도어스코프(신원 확인), CCTV(감사 로그). Hermes 메시지 플랫폼에서 A2A 기능은 플러그인 형태로 제공되지만, 보안 기본값은 절대 타협하지 않는다: token이 설정되지 않으면 로컬 127.0.0.1에서만 수신 대기 — 자물쇠는 잠겨 있고, 열쇠는 내 손에만 있는 셈이다.

4중 방어선 상세 분석

첫 번째: 로컬 바인딩 + token (자물쇠)

기본적으로 A2A는 로컬에서만 수신 대기하므로 외부에서는 문을 만질 수조차 없다. 외부에 서비스를 제공하려면 두 가지 조건을 동시에 충족해야 한다: A2A_HOST 노출 주소를 설정하고, bearer token을 구성해야 한다. 창문을 열 뿐만 아니라 창틀에 가시 달린 선인장도 놓아야 하는 것과 같다 — 둘 중 하나라도 빠지면 안 된다.

두 번째: 피어별 독립 키 (출입 카드)

각 피어는 고유한 token을 가지며, A2A_PEER_TOKENS="alice:tok1,bob:tok2" 형식으로 구성한다. 만능 열쇠 하나로 모든 문을 여는 게 아니라, 방문자마다 별도의 출입 카드를 주는 방식이다. 인증된 신원을 기반으로 rate limit, 신뢰 목록, 감사가 이루어진다 — 누가 카드를 찍었는지, 몇 번 찍었는지, 언제 찍었는지 모두 기록된다.

세 번째: 주입 필터링 + 데이터 마스킹 (보안 검색대)

인바운드 텍스트는 필터링되어 “신뢰할 수 없는 피어 입력”으로 표시되며, 원격 피어는 운영자 슬래시 명령을 호출할 수 없다. 공항 보안 검색대에서 캐리어 속 액체류를 따로 꺼내 검사하는 것과 같다. 아웃바운드 응답에서는 자격 증명 형태의 문자열(API key, JWT, token)이 자동으로 삭제된다 — 보내는 편지에 수신자의 주민등록번호가 자동으로 지워지는 것과 같다.

네 번째: 감사 로그 + 루프 방지 (CCTV)

모든 교환은 ~/.hermes/a2a_audit.jsonl에 추가된다. 현관에 24시간 CCTV를 설치한 것과 같다. 루프 방지 라운드 상한선은 옆집 초인종 인터폰과 같다 — 두 AI가 끝없이 대화하면 시스템이 자동으로 끊어버린다.

실제 공격 사례: 커뮤니티가 발견하고 수정한 3가지 문제

사례 1: SSRF 우회 (#78298) — “숫자 암호”로 자물쇠 속이기

한 공격자가 콜백 URL 보안 검사가 문자열 접두사로 호스트 이름을 매칭한다는 점을 발견했다. 예를 들어 127.로 시작하는지 확인하는 방식이다. 그런데 IP 주소에는 “정수 표기법”이 있다 — 2130706433은 127.0.0.1의 또 다른 표기법이다. 집 주소를 모스 부호로 적어서 경비원이 알아보지 못하고 통과시킨 것과 같다. 수정 방법: 콜백 호스트를 먼저 표준 IP로 변환한 다음 판단한다. 경비원이 어떤 형식의 주소든 표준 주소로 번역한 후 대조하는 것과 같다.

사례 2: 리버스 프록시 신원 붕괴 (#80534/#80779) — 모두가 같은 사람이 됨

nginx나 K8s 뒤에 배포하면 A2A 플러그인은 소켓 주소에서 호출자 신원을 유추한다. 하지만 프록시 서버가 중간에 있으면 모든 피어가 동일한 IP — 프록시 주소로 표시된다. 아파트 경비실에서 모든 방문자가 “경비실 대리 서명”으로 등록되는 것과 같다. Rate limit은 하나의 버킷을 공유하고(한 명이 바쁘면 모두가 지연), 신뢰 화이트리스트에는 프록시 주소만 등록할 수 있으며, 감사에서는 실제 호출자를 볼 수 없다. 수정: X-Forwarded-For에서 실제 신원을 유추하되, “신뢰할 수 있는 프록시 뒤에서만” 해당 값을 신뢰하도록 보장한다.

사례 3: 감사 사각지대 (#81003/#81042) — 거부된 노크 소리가 기록되지 않음

감사 로그는 허용된 트래픽만 기록한다. 401(token 무효) 및 403(신뢰되지 않음) 요청은 기록을 생성하지 않는다. CCTV가 정상적으로 들어온 사람만 촬영하고, 도둑이 자물쇠를 따는 장면은 녹화되지 않는 것과 같다. 자격 증명 충전 공격, 폐기된 token 탐지, 수평 이동 시도 — 이런 공격 행위가 바로 감사가 가장 포착해야 하는 것이다. 수정: 모든 인증 거부도 append-only 감사 로그에 추가하며, decision 필드 + HTTP 상태 코드 + 호출자 IP를 포함한다.

사용자에게 의미하는 바

이 메커니즘의 핵심 논리는: 보안은 사후 대응이 아니라 기본 상태라는 것이다. Hermes 사용자라면 보안 전문가가 아니어도 기본적인 보호를 받을 수 있다 — 4중 방어선이 자동으로 작동한다. 더 중요한 것은, 커뮤니티가 실제 공격을 통해 지속적으로 강화하고 있다는 점이다: SSRF 우회부터 리버스 프록시 신원 붕괴, 감사 사각지대까지, 각 문제는 실제 시나리오에 대응한다. A2A 프로토콜은 끊임없이 보강되는 성과 같다. 모든 벽돌이 실전 검증을 거쳤다. 다음에 두 에이전트가 서로 “전화”할 때, 그 사이에는 자물쇠, 출입 카드, 보안 검색대, CCTV뿐만 아니라 로그를 주시하는 경비원들도 있다.