보안과 신뢰의 기본값
에이전트 협업은 먼저 신뢰 문제다
A2A에서 에이전트는 단순히 문장을 주고받지 않는다. 한 에이전트가 다른 에이전트에게 보고서 작성, 주문 변경, 고객 정보 조회, 장애 조치 같은 행동을 맡길 수 있다. 이때 중요한 질문은 "어떤 메시지를 보낼 것인가"보다 먼저 나온다.
"상대가 정말 그 에이전트인가?"
"이 요청자는 이 작업을 맡길 권한이 있는가?"
"처리 과정과 결과를 나중에 설명할 수 있는가?"
A2A의 보안은 이 질문에 답하기 위한 기본값이다. Agent Card는 원격 에이전트의 신원, 기능, 엔드포인트, 인증 요구사항을 설명하고, Task와 Message는 작업의 상태와 이력을 추적할 수 있는 구조를 제공한다.1 즉 A2A의 신뢰 모델은 별도의 장식 기능이 아니라, 발견·호출·실행·감사 전 과정에 깔린 운영 조건이다.
AI 생성 이미지
HTTPS는 최소 조건이다
에이전트 간 통신의 첫 번째 기본값은 HTTPS다. HTTPS는 전송 중인 데이터를 암호화하고, 통신 상대의 서버 인증서를 검증하며, 중간자 공격으로 메시지가 바뀌는 위험을 줄인다. A2A는 새로운 전송 보안 체계를 만들기보다, 표준 웹 보안 관행 위에서 동작하도록 설계된다.2
실무에서는 다음 원칙이 기본이다.
모든 A2A 엔드포인트는 운영 환경에서 HTTPS로만 노출한다.
인증서의 호스트명과 Agent Card에 적힌 서비스 엔드포인트가 일치하는지 확인한다.
액세스 토큰, API 키, 세션 값은 URL 쿼리 문자열에 넣지 않고 HTTP 헤더로 전달한다.
로그에는 토큰, 쿠키, 개인식별정보를 그대로 남기지 않는다.
내부망 호출이라도 평문 HTTP를 기본값으로 두지 않는다.
TLS는 가능한 한 최신 버전을 사용하고, 약한 암호군은 비활성화한다.
기업 환경에서는 여기에 상호 TLS(mutual TLS, mTLS)를 더할 수 있다. mTLS는 서버만 인증하는 것이 아니라 클라이언트도 인증서로 신원을 증명하는 방식이다. A2A의 모든 배포에서 필수로 요구되는 것은 아니지만, 금융·의료·공공처럼 강한 네트워크 신뢰 경계가 필요한 환경에서는 좋은 선택지가 된다.
HTTPS는 충분조건이 아니다. HTTPS는 "전송 중에 안전하게 도착했는가"를 주로 다룬다. 그러나 "이 사용자가 이 작업을 해도 되는가", "이 에이전트가 이 데이터에 접근해도 되는가"는 별도의 인증과 인가가 맡아야 한다.
인증은 호출 전에 끝나야 한다
A2A에서 원격 에이전트는 하나의 엔터프라이즈 애플리케이션처럼 다뤄진다. 따라서 신원 확인은 메시지 본문 안의 임의 필드가 아니라 HTTP 계층의 표준 인증 방식으로 처리하는 것이 자연스럽다. 클라이언트는 사전에 발급받은 자격 증명을 HTTP 헤더에 담아 보내고, 서버는 요청을 처리하기 전에 이를 검증해야 한다.
Agent Card는 이때 중요한 안내서가 된다. 원격 에이전트가 어떤 인증 방식을 요구하는지, 어떤 보안 스킴을 지원하는지 카드에 드러내기 때문이다. A2A의 엔터프라이즈 지침은 Agent Card의 보안 정보가 OpenAPI의 인증 체계와 정렬되도록 안내한다.2 OpenAPI 인증 체계란 API 문서에서 OAuth2, Bearer 토큰, API 키, OpenID Connect 같은 방식을 일관되게 표현하는 표준적인 방법이다.
예를 들어 구매 에이전트가 공급망 에이전트에게 재고 확보 가능성을 묻는다고 하자. 공급망 에이전트의 Agent Card에는 다음과 같은 정보가 담길 수 있다. 실제 필드 구성은 사용하는 SDK와 명세 버전에 맞춰 확인해야 하지만, 의미는 "어떤 인터페이스로 호출하고, 어떤 인증 방식과 권한 범위가 필요한가"를 알려 주는 것이다.
{
"name": "Supply Chain Agent",
"description": "재고 조회와 주문 요청을 처리하는 공급망 에이전트",
"supportedInterfaces": [
{
"url": "https://supply.example.com/a2a/v1",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"securitySchemes": {
"oauth2": {
"type": "oauth2",
"flows": {
"clientCredentials": {
"tokenUrl": "https://auth.example.com/token",
"scopes": {
"inventory.read": "재고 조회",
"order.request": "주문 요청"
}
}
}
}
},
"security": [
{ "oauth2": ["inventory.read", "order.request"] }
]
}이 정보는 "이 에이전트는 OAuth2 토큰을 요구하며, 재고 조회와 주문 요청에는 각각의 범위(scope)가 필요하다"는 뜻이다. 범위는 권한의 작은 단위다. inventory.read는 재고를 읽을 권한이고, order.request는 주문 요청을 만들 권한이다. 두 권한은 다르게 관리되어야 한다.
인증 실패와 권한 부족은 구분해야 한다. 자격 증명이 없거나 잘못되었다면 401 Unauthorized가 적절하다. 이때 서버는 어떤 인증 방식이 필요한지 WWW-Authenticate 헤더로 알려줄 수 있다. 반대로 사용자의 신원은 확인되었지만 필요한 권한이 없다면 403 Forbidden이 적절하다.2 이 구분은 운영에서 중요하다. 전자는 로그인·토큰 문제이고, 후자는 정책·권한 문제이기 때문이다.
때로는 작업 도중에 추가 자격 증명이 필요할 수도 있다. 예를 들어 원격 에이전트가 사용자를 대신해 별도의 업무 시스템에 접근해야 한다면, 그 자격 증명은 A2A 메시지 안에 임의로 숨겨 넣기보다 별도의 OAuth 흐름이나 보안 절차를 통해 획득해야 한다. A2A는 이런 2차 자격 증명의 필요성을 표현할 수 있지만, 자격 증명을 발급하고 검증하는 일 자체는 조직의 기존 인증 인프라가 맡는 것이 자연스럽다.2
인가는 에이전트의 능력 단위로 좁혀야 한다
인증이 "누구인가"를 확인한다면, 인가는 "무엇을 할 수 있는가"를 결정한다. 에이전트 협업에서는 인가가 특히 중요하다. 에이전트는 사람보다 빠르게 많은 작업을 요청할 수 있고, 한 번의 잘못된 권한 설정이 여러 시스템으로 확산될 수 있기 때문이다.
좋은 인가 설계는 최소 권한 원칙에서 시작한다. 원격 에이전트를 호출할 수 있다는 사실이 모든 스킬을 사용할 수 있다는 뜻이 되어서는 안 된다. Agent Card가 여러 스킬을 공개한다면, 스킬별로 필요한 권한을 나눌 수 있어야 한다. 예를 들어 같은 재무 에이전트라도 "환율 조회", "지급 요청 생성", "지급 승인"은 서로 다른 권한이어야 한다.
또한 권한 검사는 한 번으로 끝나지 않는다. 호출 시점의 OAuth 범위가 맞더라도, 실제 백엔드 데이터에 접근하기 전 다시 확인해야 한다. 사용자가 A 고객사의 송장을 볼 수 있다고 해서 B 고객사의 송장까지 볼 수 있는 것은 아니다. 에이전트가 다른 에이전트를 대신 호출할 때도 이 경계는 유지되어야 한다.
A2A 명세에서도 Task 목록 조회는 인증된 클라이언트가 볼 수 있는 작업만 반환해야 하며, 구현체는 적절한 권한 범위를 적용해야 한다고 설명한다.1 이는 단순한 목록 API의 문제가 아니다. Task ID 하나가 고객명, 계약 내용, 내부 의사결정, 산출물 위치를 연결할 수 있기 때문이다. 작업 조회 권한은 작업 실행 권한만큼 신중히 다뤄야 한다.
Agent Card는 발견의 시작이자 공격 표면이다
Agent Card는 에이전트 협업의 출발점이다. 클라이언트는 카드를 읽고 "이 에이전트가 어떤 일을 할 수 있는지", "어디로 호출해야 하는지", "어떤 인증이 필요한지" 판단한다. 따라서 Agent Card가 위조되거나 변조되면 잘못된 에이전트를 신뢰하게 된다.
가장 기본적인 방어는 카드 자체를 신뢰할 수 있는 HTTPS 도메인에서 제공하는 것이다. 클라이언트는 카드의 위치, 카드에 적힌 서비스 엔드포인트, 인증서의 주체, 조직의 허용 목록을 함께 확인해야 한다. 공개 인터넷에서 발견한 Agent Card를 곧바로 신뢰하는 방식은 위험하다.
기업 환경에서는 여기에 Agent Card 서명 검증을 더할 수 있다. 현재 A2A의 핵심 명세가 특정 카드 서명 방식을 필수로 고정한다고 보기는 어렵다. 그러나 운영 관점에서는 카드에 전자서명을 붙이거나, 신뢰된 레지스트리가 카드의 해시와 발행자를 검증해 주는 패턴이 유용하다.
서명된 Agent Card에는 보통 다음 정보가 함께 관리된다.
카드 발행 조직
카드 버전
유효 기간
서명 키 식별자
서비스 엔드포인트
지원 스킬과 보안 요구사항
카드 본문 해시
클라이언트는 카드를 사용할 때 서명이 유효한지, 유효 기간이 지나지 않았는지, 발행자가 조직의 신뢰 목록에 있는지 확인한다. 이 과정은 위조된 에이전트 발견, 오래된 카드 재사용, 엔드포인트 바꿔치기 위험을 줄인다.
중요한 점은 서명이 권한을 대신하지 않는다는 것이다. 서명은 "이 카드가 신뢰된 발행자로부터 왔고 변조되지 않았다"는 사실을 도와준다. 그러나 "이 요청자가 이 작업을 실행해도 되는가"는 여전히 인증과 인가가 판단해야 한다.
불투명 실행은 보안 경계다
A2A는 원격 에이전트의 내부 프롬프트, 메모리, 도구 체인, 독점 로직을 공개하지 않아도 협업할 수 있게 한다. 이를 불투명 실행(opaque execution)이라고 볼 수 있다. 외부에는 선언된 능력, 요청 형식, 상태, 산출물만 드러내고, 내부 구현은 각 에이전트의 책임 영역 안에 둔다.
이 모델은 보안에 유리하다. 한 회사의 가격 산정 로직, 고객 분류 규칙, 내부 승인 프롬프트, 사내 도구 호출 순서를 협업 상대에게 모두 공개할 필요가 없다. 상대 에이전트는 "견적 가능 여부를 판단해 달라"는 작업을 맡기고, 결과와 근거 수준의 설명만 받을 수 있다.
하지만 불투명 실행은 면책 장치가 아니다. 내부가 보이지 않는다는 이유로 아무 데이터나 보내서는 안 된다. 클라이언트는 필요한 최소 정보만 전달해야 한다. 원격 에이전트는 받은 입력을 정책에 맞게 처리하고, 민감한 데이터가 Artifact나 로그에 과도하게 남지 않도록 해야 한다.
실무에서는 다음 검사를 조합한다.
입력 데이터 최소화
파일 첨부의 악성코드 검사
구조화 데이터의 스키마 검증
개인정보·기밀정보 마스킹
산출물의 정책 위반 검사
외부 URL과 파일 참조의 접근 제어
A2A는 에이전트 간 협업 형식을 제공하지만, 데이터 거버넌스와 보안 정책을 자동으로 대신 집행하지는 않는다. 각 조직은 어떤 데이터를 어떤 에이전트에게 보낼 수 있는지 별도의 정책으로 정해야 한다.
감사 가능성은 Task에서 시작된다
기업에서 신뢰는 "지금 안전하다"만으로 완성되지 않는다. 나중에 설명할 수 있어야 한다. 누가 요청했는지, 어떤 에이전트가 처리했는지, 어떤 권한으로 실행했는지, 언제 상태가 바뀌었는지, 어떤 산출물이 만들어졌는지 추적할 수 있어야 한다.
A2A의 Task 모델은 이 감사 가능성의 중심이다. Task는 고유 ID를 가지고 상태를 바꿔 가며, Message 이력과 Artifact를 연결할 수 있다. 스트리밍에서는 상태 업데이트와 산출물 업데이트가 이벤트로 전달될 수 있고, Get Task나 List Tasks 같은 작업은 현재 상태와 필요한 이력을 조회하는 데 쓰인다.1
운영 로그에는 최소한 다음 항목을 남기는 것이 좋다.
taskId요청자 주체 또는 서비스 계정
호출한 클라이언트 에이전트와 원격 에이전트
사용한 Agent Card 버전
호출한 스킬
OAuth 범위 또는 권한 세트
상태 전이 기록
실패·거절·취소 사유
Artifact 식별자와 해시
상관관계 ID(correlation ID)와 trace context
A2A의 엔터프라이즈 지침은 표준 추적, 로깅, 모니터링과의 통합을 강조하며, W3C Trace Context 같은 HTTP 기반 분산 추적 헤더를 활용할 수 있다고 설명한다.2 분산 추적은 하나의 요청이 여러 서비스와 에이전트를 거칠 때 전체 경로를 이어 보는 방법이다.
단, 감사 로그는 많이 남길수록 좋은 것이 아니다. 프롬프트 전문, 원본 고객 데이터, 액세스 토큰, 내부 추론 내용을 무분별하게 저장하면 로그 자체가 새로운 위험이 된다. 감사에 필요한 사실은 남기되, 민감한 내용은 마스킹하거나 별도 보안 저장소에 분리해야 한다.
안전한 기본 흐름
A2A 호출의 안전한 흐름은 다음처럼 정리할 수 있다.
클라이언트가 신뢰된 위치에서 Agent Card를 가져온다.
HTTPS 인증서, 도메인, 카드 발행자, 필요 시 카드 서명을 검증한다.
Agent Card의 서비스 인터페이스, 보안 요구사항, 스킬 권한을 확인한다.
필요한 OAuth 토큰이나 자격 증명을 획득한다.
원격 에이전트는 요청을 처리하기 전에 인증과 인가를 수행한다.
권한이 충분할 때만 Task를 만들거나 Message 응답을 반환한다.
Task 상태 전이, 메시지, 산출물 참조를 감사 로그와 추적 시스템에 연결한다.
완료·실패·취소·거절 같은 최종 상태를 명확히 남긴다.
이 흐름의 핵심은 간단하다. 통신보다 먼저 신뢰가 있어야 한다. 신뢰는 한 번의 토큰 검사로 끝나지 않는다. Agent Card의 진위, 전송 보안, 인증, 인가, 실행 경계, 감사 로그가 함께 맞물릴 때 엔터프라이즈 환경에서 에이전트에게 행동을 위임할 수 있다.
A2A는 이 신뢰 구조를 만들기 위한 공통 언어를 제공한다. 그러나 최종 책임은 구현과 운영에 있다. 어떤 에이전트를 등록할지, 어떤 권한을 줄지, 어떤 로그를 남길지, 어떤 데이터는 절대 보내지 않을지는 조직의 보안 정책이 결정해야 한다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.