에이전트 ID는 SPIFFE 표준을 기반으로 각 에이전트에 강력하게 증명된 암호화 ID를 제공합니다. 에이전트 ID를 사용하면 에이전트가 자체적으로 또는 최종 사용자를 대신하여 MCP 서버, 클라우드 리소스, 엔드포인트, 기타 에이전트에 안전하게 인증할 수 있습니다. 에이전트 ID는 에이전트 자체 사용자 인증 정보와 에이전트 ID 인증 관리자를 사용합니다. 인증 관리자를 사용하여 API 키, OAuth 클라이언트 ID, OAuth 클라이언트 보안 비밀번호, 위임된 최종 사용자 OAuth 토큰을 획득, 관리, 보호하는 데 사용되는 특정 구성인 인증 제공자를 만들고 관리할 수 있습니다.
서비스 계정과 달리 에이전트 ID는 기본적으로 여러 워크로드에서 공유되지 않으며, 가장할 수 없고, 개발자가 수명이 긴 서비스 계정 키를 생성할 수 없습니다. Google Cloud에 대해 생성된 액세스 토큰은 토큰 도난을 방지하기 위해 에이전트의 고유한 X.509 인증서에 암호화 방식으로 바인딩됩니다.
에이전트 ID는 에이전트 레지스트리 및 에이전트 게이트웨이와 함께 작동하여 AI 에이전트를 보호하고 관리합니다. 에이전트 ID는 암호화 ID를 프로비저닝하고 사용자 인증 정보를 관리하며, Agent Registry는 환경의 도구와 대상을 카탈로그화하고, Agent Gateway는 에이전트가 이러한 대상을 호출할 때 액세스 정책을 적용하고 네트워크 트래픽을 검사합니다.
에이전트 ID를 Agent Gateway 및 Gemini Enterprise와 함께 사용하면 Gemini Enterprise 커넥터에서 프로비저닝한 것과 같은 최종 사용자 사용자 인증 정보가 인증 관리자에 의해 암호화되고 게이트웨이에서 복호화되어 에이전트가 원시 사용자 인증 정보에 액세스할 수 없습니다.
다음 서비스는 에이전트 ID를 지원합니다.
- Gemini Enterprise Agent Platform Runtime (Agent Runtime)
- Gemini Enterprise
- Cloud Run
인증 모델
다양한 도구와 서비스로 인증하기 위해 에이전트 ID는 여러 인증 모델을 지원합니다. 에이전트가 사용하는 모델은 타겟 리소스에서 제공하는 인증 방법과 에이전트가 자체 권한으로 작동하는지 아니면 최종 사용자를 대신하여 작동하는지에 따라 달라집니다.
| 권한 | 인증 방법 | 대상 리소스 | 사용 사례 및 솔루션 |
|---|---|---|---|
| 사용자 위임 권한 | OAuth 2.0 (3-legged) | 외부 도구 및 서비스 | 상담사가 특정 사용자를 대신하여 조치를 취하는 경우 (예: 사용자의 Jira 작업 또는 GitHub 저장소에 액세스) 사용자 동의 및 토큰을 관리하기 위해 에이전트 ID 인증 관리자에서 3-legged OAuth 인증 공급자를 구성합니다. 자세한 내용은 인증 관리자를 사용하여 3-legged OAuth로 인증을 참고하세요. |
| 상담사의 자체 권한 | 클라우드 기반 ID (에이전트 ID) | Google Cloud 서비스 | Google Cloud 에서 호스팅되는 상담사가 자체 ID를 사용하여 다른 Google Cloud 서비스에 액세스해야 하는 경우 자세한 내용은 상담사의 자체 ID를 사용하여 인증을 참고하세요. |
| OAuth 2.0 (2-legged) | 외부 도구 및 서비스 | OAuth를 지원하는 외부 서비스와의 머신 간 인증에 권장됩니다. 에이전트 ID 인증 관리자에서 2단계 OAuth 인증 공급자를 구성하여 클라이언트 사용자 인증 정보와 액세스 토큰을 처리합니다. 자세한 내용은 인증 관리자로 2단계 OAuth를 사용하여 인증을 참고하세요. | |
| API 키 | 외부 도구 및 서비스 | 인증에 암호화 키 또는 비밀번호가 필요한 외부 서비스 에이전트 ID 인증 관리자에서 API 키 인증 제공자를 구성하여 키를 안전하게 저장하고 관리할 수 있습니다. 자세한 내용은 인증 관리자로 API 키를 사용하여 인증을 참고하세요. | |
| HTTP 기본 인증 | 외부 도구 및 서비스 | 일반 텍스트 비밀번호를 사용합니다. 이 방법은 권장되지 않습니다. API 키와 유사한 비밀번호를 저장할 수 있습니다. 자세한 내용은 인증 관리자로 API 키를 사용하여 인증을 참고하세요. |
핵심 구성요소
에이전트 ID에는 안전한 인증 및 승인을 제공하는 데 도움이 되는 여러 주요 구성요소가 포함됩니다.
SPIFFE 기반 ID
각 에이전트에는 SPIFFE 표준에 따라 고유한 ID 문자열(SPIFFE ID)이 할당됩니다. 이 ID는 강력하게 증명되고, 에이전트의 수명 주기에 연결되며, 에이전트가 호스팅되는 리소스 URI에 직접 매핑됩니다.
ID는 다음 형식을 따릅니다.
spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH
예를 들면 다음과 같습니다.
spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
에이전트 ID가 IAM 허용 정책에 사용되면 주 구성원 식별자는 다음 형식을 따릅니다.
principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH
예:
- Vertex AI Agent Engine (조직):
principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent - Vertex AI Agent Engine (조직이 없는 프로젝트):
principal://agents.global.proj-9876543210.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent - Gemini Enterprise:
principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent
식별자는 다음을 사용합니다.
TRUST_DOMAIN: 리소스 계층 구조의 트러스트 도메인입니다.- 조직의 프로젝트:
agents.global.org-ORGANIZATION_ID.system.id.goog - 조직이 없는 프로젝트의 경우:
agents.global.proj-PROJECT_NUMBER.system.id.goog
- 조직의 프로젝트:
SERVICE: Google Cloud 서비스의 약칭입니다 (예:aiplatform또는discoveryengine).RESOURCE_PATH: 에이전트를 호스팅하는 리소스의 전체 경로입니다.
에이전트 자체가 주 구성원이므로 이 식별자에 직접 권한을 부여하여 에이전트가 액세스할 수 있는 리소스를 제어합니다.
ID 및 권한 수명 주기
에이전트 ID의 IAM 바인딩을 관리해야 합니다. 상담사를 삭제해도 해당 상담사의 주 구성원을 참조하는 IAM 바인딩은 삭제되지 않습니다. 이러한 바인딩은 정책에 비활성 권한으로 남아 있으며 에이전트 폐기의 일환으로 수동으로 삭제해야 합니다.
에이전트의 ID는 reasoningEngines 리소스 ID와 같이 에이전트를 호스팅하는 리소스의 ID에서 파생됩니다. 동일한 표시 이름, 코드, 구성으로 에이전트를 삭제하고 대체 에이전트를 배포하더라도 새 에이전트에는 새 리소스 ID가 할당되므로 새 주 구성원 식별자가 할당됩니다. 이전 ID를 참조하는 기존 IAM 바인딩은 새 주 구성원에게 적용되지 않습니다. 새 주 구성원에게 필요한 역할을 부여해야 합니다.
에이전트 사용자 인증 정보
에이전트 사용자 인증 정보는 에이전트의 ID에 대한 암호화 증명을 제공합니다. 시스템은 X.509 인증서와 Google Cloud 액세스 토큰을 지원합니다. X.509 인증서는 더 강력한 인증을 지원하기 위해 에이전트에서 자동 프로비저닝되고 관리됩니다.
기본적으로 에이전트 ID는 Google Cloud API와 직접 통신할 때 X.509 인증서와 함께 상호 TLS (mTLS)를 사용합니다. 에이전트가 에이전트 게이트웨이에서 상호작용할 때도 소유 증명 (DPoP)을 사용하여 엔드 투 엔드 보안을 위한 이중 바인딩된 사용자 인증 정보를 만듭니다. 이중 바인딩은 에이전트가 게이트웨이에 대한 퍼스트 파티 액세스에 mTLS를 사용하여 인증하고 게이트웨이 외부 상호작용에 DPoP를 사용한다는 의미입니다.
에이전트 ID 인증 관리자
에이전트 ID 인증 관리자는 에이전트의 아웃바운드 도구 인증을 간소화하는 중앙 집중식 사용자 인증 정보 보관소 및 인증 브로커입니다. 이를 통해 상담사는 API 키 또는 OAuth 클라이언트 ID 및 비밀번호를 사용하여 인증하거나 최종 사용자 액세스 토큰을 사용하는 OAuth 위임을 통해 사용자를 대신하여 인증할 수 있습니다. 인증 관리자 내에서 특정 서드 파티 애플리케이션의 인증 유형과 사용자 인증 정보를 정의하는 인증 제공업체를 구성합니다.
에이전트 ID 인증 관리자에 대한 액세스는 IAM에 의거하여 관리되며 에이전트는 자체 에이전트 SPIFFE ID를 사용하여 인증 관리자에 인증합니다. 모든 최종 사용자 액세스 이벤트는 상담사의 SPIFFE ID에도 귀속되므로 손쉽게 관리할 수 있습니다.
에이전트 ID 인증 관리자는 사용자 로그인 및 동의를 위한 대화상자를 여는 등 OAuth 사용자 인증 정보 획득을 자동화합니다. 또한 최종 사용자 액세스에 대한 가시성을 제공하고 액세스 취소를 허용하여 사용자 위임 권한에 대한 거버넌스를 개선합니다.
자세한 내용은 에이전트 ID 인증 관리자 개요를 참고하세요.
보안 및 거버넌스
에이전트 ID는 IAM, 보안 주체 액세스 경계 (PAB), VPC 서비스 제어와 같은 Google의 정책 시스템과 완전히 통합되어 보안과 거버넌스를 강화할 수 있습니다. 또한 감사 로깅과 통합되어 에이전트가 자체적으로 행동할 때와 최종 사용자를 대신하여 행동할 때 모두 책임감을 보장하고 명확한 감사 로그를 제공합니다.
- 컨텍스트 인식 액세스: 기본적으로 Google 관리 컨텍스트 인식 액세스 정책은 mTLS 및 DPoP 토큰 바인딩을 적용하여 에이전트 사용자 인증 정보를 보호합니다. 이 접근 방식을 사용하면 인증서 바인딩 토큰이 신뢰할 수 있는 런타임 환경 외부에서 재생될 수 없습니다.
- IAM 통합: 표준 IAM 허용 정책 및 거부 정책 지원
- 보안 주체 액세스 경계 (PAB): PAB는 다른 권한과 관계없이 에이전트가 액세스할 수 있는 리소스를 제한합니다.
- VPC 서비스 제어: 경계 보호 및 주 구성원 사용 지원:
- 경계 보호: 서비스 경계에 에이전트 ID API (
agentidentity.googleapis.com)와 에이전트 ID 사용자 인증 정보 API (agentidentitycredentials.googleapis.com)를 추가하여 이러한 API에 대한 액세스를 제어할 수 있습니다. 서비스 경계 내에서 이러한 API를 사용하려면 클라이언트가 제한된 VIP (restricted.googleapis.com)를 통해 요청을 라우팅해야 합니다. - 인그레스 및 이그레스 규칙: 인그레스 및 이그레스 규칙에서 에이전트 ID를 주 구성원으로 사용하여 서비스 경계로 보호되는 리소스에 대한 액세스를 허용하는 기능이 지원됩니다.
- 경계 보호: 서비스 경계에 에이전트 ID API (
에이전트 ID 작동 방식
에이전트 ID는 보안 강화를 위해 설계된 워크플로를 통해 에이전트 작업을 인증하고 승인합니다.
- ID 할당: 에이전트를 배포하면 Google Cloud에서 고유한 SPIFFE ID와 X.509 인증서를 할당합니다. 각 X.509 인증서는 24시간 동안 유효하며 Google Cloud 보안을 유지하기 위해 자동으로 최신 상태로 유지됩니다.
- 사용자 인증 정보 획득: 에이전트가 사용자 인증 정보를 획득하는 방법은 액세스하려는 항목에 따라 다릅니다. 다음은 몇 가지 예입니다.
- 액세스 Google Cloud 서비스: 에이전트가 바인딩된 액세스 토큰을 요청합니다. 이 토큰은 토큰 도용을 방지하기 위해 에이전트의 고유한 X.509 인증서에 암호화 방식으로 바인딩됩니다. 자세한 내용은 보안 및 거버넌스를 참고하세요.
- 외부 도구 액세스: 에이전트는 에이전트 ID 인증 관리자를 사용하여 인증 제공업체에서 필요한 사용자 인증 정보 (예: API 키 또는 OAuth 토큰)를 가져옵니다. 인증 관리자는 사용자 위임 권한과 상담사의 자체 권한을 모두 지원합니다.
상담사 ID의 이점
에이전트 ID는 표준 서비스 계정보다 보안을 강화합니다.
- 강력한 격리: 서비스 계정과 달리 에이전트 ID는 기본적으로 여러 워크로드에서 공유되지 않으며, 가장할 수 없고, 개발자가 장기 서비스 계정 키를 생성할 수 없습니다.
- 사용자 인증 정보 보안: 기본 컨텍스트 인식 액세스 정책으로 바운드 토큰을 재생할 수 없게 되어 토큰 도용 및 계정 탈취를 방지할 수 있습니다. 에이전트 ID를 Agent Gateway 및 Gemini Enterprise와 함께 사용하면 Gemini Enterprise 커넥터에서 프로비저닝한 것과 같은 최종 사용자 사용자 인증 정보가 인증 관리자에 의해 암호화되고 게이트웨이에서 복호화되므로 에이전트가 원시 사용자 인증 정보에 액세스할 수 없습니다.
- 최소 권한 접근 방식: 과도한 권한이 부여된 에이전트를 제거하기 위해 공유 서비스 계정 대신 에이전트별 ID를 제공합니다.
- 마찰 감소: 복잡한 OAuth 흐름을 자동화하고 API 키를 관리하여 도구 통합을 간소화합니다.
- 모니터링 가능성 개선: 명확한 감사 로그를 제공합니다. 상담사가 사용자를 대신하여 행동하면 로그에 상담사와 사용자의 신원이 모두 표시됩니다.
제한사항
- Cloud Storage 기존 버킷 역할: 에이전트 ID에 기존 버킷 역할 (예:
storage.legacyBucketReader)을 부여할 수 없습니다.
다음 단계
- Agent Runtime에서 에이전트 ID를 사용하는 방법에 대해 자세히 알아보세요.
- 에이전트 관리에 대해 자세히 알아보세요.