Skip to content

A2A 에이전트를 위한 엔터프라이즈급 기능

Agent2Agent(A2A) 프로토콜은 핵심적으로 엔터프라이즈 요구 사항을 염두에 두고 설계되었습니다. 보안 및 운영을 위해 새롭고 독점적인 표준을 만드는 대신, A2A는 기존 엔터프라이즈 인프라 및 널리 채택된 모범 사례와 원활하게 통합하는 것을 목표로 합니다. A2A는 원격 에이전트를 표준 HTTP 기반 엔터프라이즈 애플리케이션으로 취급합니다. 이러한 접근 방식을 통해 조직은 보안, 모니터링, 거버넌스 및 ID 관리에 대한 기존 투자와 전문 지식을 활용할 수 있습니다.

A2A의 핵심 원칙은 에이전트가 일반적으로 "불투명(opaque)"하다는 것입니다. 즉, 내부 메모리, 도구 또는 직접적인 리소스 액세스를 서로 공유하지 않습니다. 이러한 불투명성은 표준 클라이언트/서버 보안 패러다임과 자연스럽게 일치합니다.

1. 전송 계층 보안(TLS)

전송 중인 데이터의 기밀성과 무결성을 보장하는 것은 기본입니다.

  • HTTPS 필수: 프로덕션 환경의 모든 A2A 통신은 반드시 HTTPS를 통해 이루어져야 합니다.
  • 최신 TLS 표준: 구현은 도청 및 변조로부터 데이터를 보호하기 위해 강력한 산업 표준 암호화 제품군과 함께 최신 TLS 버전(TLS 1.2 이상 권장)을 사용해야 합니다(SHOULD).
  • 서버 ID 확인: A2A 클라이언트는 TLS 핸드셰이크 중에 신뢰할 수 있는 인증 기관(CA)에 대해 TLS 인증서를 확인함으로써 A2A 서버의 ID를 확인해야 합니다(SHOULD). 이는 중간자 공격을 방지합니다.

2. 인증

A2A는 주로 HTTP 헤더와 OAuth2 및 OpenID Connect와 같은 기존 표준에 의존하여 인증을 표준 웹 메커니즘에 위임합니다. 인증 요구 사항은 A2A 서버가 해당 에이전트 카드에 명시합니다.

  • 페이로드 내 ID 없음: A2A 프로토콜 페이로드(JSON-RPC 메시지)는 사용자 또는 클라이언트 ID 정보를 전달하지 않습니다. ID는 전송/HTTP 계층에서 설정됩니다.
  • 에이전트 카드 선언: A2A 서버의 AgentCard는 해당 security 필드에서 지원하는 인증 schemes를 설명합니다. 이 필드의 각 명명된 체계는 해당 카드에 특정한 식별자입니다. 체계 유형을 포함하여 각 명명된 체계에 대한 세부 정보는 에이전트 카드의 securitySchemes 필드에 제공될 수 있습니다. 지원되는 체계 유형 이름("apiKey", "http", "oauth2", "openIdConnect")은 OpenAPI 인증 사양에 정의된 이름과 일치합니다.
  • 대역 외 자격 증명 획득: A2A 클라이언트는 A2A 프로토콜 자체 외부의 프로세스를 통해 필요한 자격 증명 자료(예: JWT 형식 또는 기타 형식의 OAuth 2.0 토큰, API 키 등)를 획득할 책임이 있습니다. 여기에는 OAuth 흐름(인증 코드, 클라이언트 자격 증명), 보안 키 배포 등이 포함될 수 있습니다.
  • HTTP 헤더 전송: 자격 증명은 선택한 인증 체계의 요구 사항에 따라 표준 HTTP 헤더(예: Authorization: Bearer <token>, API-Key: <key_value>)로 반드시 전송되어야 합니다.
  • 서버 측 유효성 검사: A2A 서버는 HTTP 헤더에 제공된 자격 증명과 선언된 요구 사항을 기반으로 모든 수신 요청을 반드시 인증해야 합니다.
    • 인증에 실패하거나 누락된 경우, 서버는 401 Unauthorized 또는 403 Forbidden과 같은 표준 HTTP 상태 코드로 응답해야 합니다(SHOULD).
    • 401 Unauthorized 응답에는 클라이언트에게 올바르게 인증하는 방법을 안내하는 필수 체계(들)를 나타내는 WWW-Authenticate 헤더가 포함되어야 합니다(SHOULD).
  • 작업 내 인증(보조 자격 증명): 에이전트가 작업 중에 다른 시스템에 대한 추가 자격 증명이 필요한 경우(예: 사용자를 대신하여 특정 도구에 액세스하기 위해), A2A는 다음을 권장합니다.
    1. A2A 서버는 A2A 작업을 input-required 상태로 전환합니다.
    2. TaskStatus.message(종종 DataPart 사용)는 AuthenticationInfo와 유사한 구조를 사용하여 보조 시스템에 필요한 인증에 대한 세부 정보를 제공해야 합니다.
    3. 그런 다음 A2A 클라이언트는 보조 시스템에 대한 이러한 새 자격 증명을 대역 외로 얻습니다. 이러한 자격 증명은 A2A 서버(요청을 프록시하는 경우)에 다시 제공되거나 클라이언트가 보조 시스템과 직접 상호 작용하는 데 사용될 수 있습니다.

3. 권한 부여

클라이언트가 인증되면 A2A 서버는 요청을 승인할 책임이 있습니다. 권한 부여 논리는 에이전트의 구현, 처리하는 데이터 및 적용 가능한 엔터프라이즈 정책에 따라 다릅니다.

  • 세분화된 제어: 권한 부여는 인증된 ID(최종 사용자, 클라이언트 애플리케이션 또는 둘 다를 나타낼 수 있음)를 기반으로 적용되어야 합니다(SHOULD).
  • 기술 기반 권한 부여: 에이전트 카드에 광고된 대로 기술별로 액세스를 제어할 수 있습니다. 예를 들어, 특정 OAuth 범위는 인증된 클라이언트에게 특정 기술을 호출할 수 있는 액세스 권한을 부여하지만 다른 기술은 호출할 수 없습니다.
  • 데이터 및 작업 수준 권한 부여: 백엔드 시스템, 데이터베이스 또는 도구와 상호 작용하는 에이전트는 해당 기본 리소스를 통해 민감한 작업을 수행하거나 민감한 데이터에 액세스하기 전에 적절한 권한 부여를 반드시 시행해야 합니다. 에이전트는 게이트키퍼 역할을 합니다.
  • 최소 권한의 원칙: 클라이언트 또는 사용자가 A2A 인터페이스를 통해 의도한 작업을 수행하는 데 필요한 권한만 부여합니다.

4. 데이터 개인 정보 보호 및 기밀 유지

  • 민감도 인식: 구현자는 A2A 상호 작용의 Message 및 Artifact 부분에서 교환되는 데이터의 민감도를 예리하게 인식해야 합니다.
  • 규정 준수: 관련 데이터 개인 정보 보호 규정(예: 도메인 및 데이터에 따라 GDPR, CCPA, HIPAA)을 준수해야 합니다.
  • 데이터 최소화: A2A 교환에 불필요하게 민감한 정보를 포함하거나 요청하지 마십시오.
  • 안전한 처리: 엔터프라이즈 데이터 보안 정책 및 규제 요구 사항에 따라 전송 중(필수 TLS를 통해) 및 저장 시(에이전트가 유지하는 경우) 데이터를 보호합니다.

5. 추적, 관찰 가능성 및 모니터링

A2A가 HTTP에 의존하므로 표준 엔터프라이즈 추적, 로깅 및 모니터링 도구와 간단하게 통합할 수 있습니다.

  • 분산 추적:
    • A2A 클라이언트 및 서버는 분산 추적 시스템(예: OpenTelemetry, Jaeger, Zipkin)에 참여해야 합니다(SHOULD).
    • 추적 컨텍스트(추적 ID, 스팬 ID)는 표준 HTTP 헤더(예: traceparent 및 tracestate와 같은 W3C 추적 컨텍스트 헤더)를 통해 전파되어야 합니다(SHOULD).
    • 이를 통해 여러 에이전트 및 기본 서비스에 걸쳐 흐르는 요청에 대한 엔드투엔드 가시성을 확보할 수 있으며, 이는 디버깅 및 성능 분석에 매우 중요합니다.
  • 포괄적인 로깅: 클라이언트 및 서버 측 모두에 상세한 로깅을 구현합니다. 로그에는 문제 해결 및 감사를 용이하게 하기 위해 taskId, sessionId, 상관 관계 ID 및 추적 컨텍스트와 같은 관련 식별자가 포함되어야 합니다.
  • 메트릭: A2A 서버는 성능 모니터링, 경고 및 용량 계획을 가능하게 하기 위해 주요 운영 메트릭(예: 요청 속도, 오류율, 작업 처리 대기 시간, 리소스 사용률)을 노출해야 합니다. 이러한 메트릭은 Prometheus 또는 Google Cloud Monitoring과 같은 시스템과 통합할 수 있습니다.
  • 감사: 작업 생성, 중요한 상태 변경 및 에이전트가 수행한 작업(특히 민감한 데이터 액세스, 수정 또는 영향이 큰 작업과 관련된 작업)과 같은 중요한 이벤트에 대한 감사 추적을 유지합니다.

6. API 관리 및 거버넌스

외부, 조직 경계를 넘어 또는 대기업 내에서도 노출되는 A2A 서버의 경우 API 관리 솔루션과의 통합이 적극 권장됩니다. 이를 통해 다음을 제공할 수 있습니다.

  • 중앙 집중식 정책 시행: 보안 정책(인증, 권한 부여), 속도 제한 및 할당량의 일관된 적용.
  • 트래픽 관리: 로드 밸런싱, 라우팅 및 중재.
  • 분석 및 보고: 에이전트 사용, 성능 및 추세에 대한 통찰력.
  • 개발자 포털: A2A 지원 에이전트 검색을 용이하게 하고, 설명서(에이전트 카드 포함)를 제공하며, 클라이언트 개발자를 위한 온보딩을 간소화합니다.

이러한 엔터프라이즈급 관행을 준수함으로써 A2A 구현은 복잡한 조직 환경 내에서 안전하고 안정적이며 관리 가능하게 배포되어 신뢰를 조성하고 확장 가능한 에이전트 간 협업을 가능하게 할 수 있습니다.