2026.03.10 / JUN
핵심 요약 (Executive Summary)
구글 클라우드의 Vertex AI Agent Engine은 AI 에이전트의 고유한 특성(비결정적, 상태 유지)을 반영하여 기존의 서비스 계정(Service Accounts) 방식을 넘어선 **에이전트 ID(Agent Identity)**를 도입했습니다. 서비스 계정이 프로젝트 단위의 공유된 권한 관리에 중점을 둔다면, 에이전트 ID는 개별 에이전트마다 고유하게 부여되는 암호화 증명(Cryptographic Attestation) 기반의 ID입니다.
에이전트 ID의 핵심 가치는 제로 트러스트(Zero Trust) 보안 모델의 구현에 있습니다. mTLS 바인딩과 컨텍스트 기반 액세스(CAA)를 통해 인증 정보 탈취 및 재사용을 원천적으로 차단하며, 최소 권한 원칙(Least Privilege)을 세밀하게 적용할 수 있습니다. 또한, 운영 측면에서도 자동 프로비저닝과 SDK의 자동 인식을 통해 개발 효율성을 극대화합니다. 본 문서는 에이전트 ID와 서비스 계정의 차이점을 분석하고, 에이전트 ID를 활용한 보안 및 운영 최적화 방안을 상세히 설명합니다.
| 비교 항목 | 서비스 계정 (Service Accounts) | 에이전트 ID (Agent Identity) |
| 관리 단위 | 프로젝트 단위로 생성 및 관리 (여러 에이전트가 공유 가능) | 에이전트별로 고유하게 자동 할당됨 |
| 보안 모델 및 인증 방식 | 키 파일 또는 임퍼스네이션(Impersonation) 방식 사용 | 암호화 증명(Cryptographic Attestation) 및 mTLS 바인딩 기반 |
| 권한 부여 원칙 | 프로젝트 내 여러 리소스에 대해 넓은 범위의 권한 부여 경향 | 최소 권한 원칙(Least Privilege) 준수에 최적화 |
| 운영 및 프로비저닝 | 사용자가 수동으로 생성하고 구성해야 함 | 배포 시 런타임에서 자동으로 프로비저닝됨 |
| 로깅 및 감사 (Auditing) | 서비스 계정 단위의 로그만 기록되어 개별 에이전트 식별이 어려움 | 로그에 에이전트 고유 ID 및 사용자 ID가 명확히 기록됨 |
| 동적 특성 대응 | 정적인 머신-투-머신 인증에 적합 | 비결정적(Non-deterministic)이고 상태를 유지(Stateful)하는 에이전트에 최적화 |
Sponsored by
AIGrape의 최신 기능인 Auto 모드를 켜면
다수의 AI가 협력해서 복잡한 임무를 처리합니다.
1. 에이전트 ID와 서비스 계정의 개념 및 용도
1.1 서비스 계정 (Service Accounts)
전통적인 머신-투-머신(Machine-to-Machine) 인증 방식으로, 특정 애플리케이션이나 가상 머신(VM)이 구글 클라우드 리소스에 접근할 수 있도록 권한을 부여받는 ‘가상 사용자’ 역할을 합니다. 프로젝트 단위로 관리되며 여러 에이전트가 공유하여 사용하는 경우가 많습니다.
1.2 에이전트 ID (Agent Identity)
Vertex AI Agent Engine에서 실행되는 개별 에이전트마다 부여되는 고유한 ID입니다. 에이전트는 실행 결과가 일정하지 않은 비결정적(Non-deterministic) 특성과 이전 대화 맥락을 기억하는 상태 유지(Stateful) 특성을 가집니다. 이러한 복잡성으로 인해 발생할 수 있는 보안 리스크를 관리하기 위해, 기존 서비스 계정보다 더 세밀하고 동적인 보안 모델로 설계되었습니다.
2. 주요 차이점 비교
| 구분 | 서비스 계정 (Service Accounts) | 에이전트 ID (Agent Identity) |
| 관리 단위 | 프로젝트 단위 (여러 에이전트 공유 가능) | 에이전트별 고유 ID 자동 할당 |
| 인증 메커니즘 | 키 파일 또는 임퍼스네이션(Impersonation) | 암호화 증명(Cryptographic Attestation) |
| 보안 모델 | 광범위한 권한 부여 경향 | 최소 권한 원칙(Least Privilege) 최적화 |
| 운영 방식 | 수동 생성 및 구성 필요 | 런타임 시 자동 프로비저닝 |
| 탈취 위험 | 인증 정보 유출 시 외부 재사용 가능성 존재 | mTLS 바인딩으로 유출 시에도 재사용 불가 |
3. 에이전트 ID의 핵심 장점
3.1 향상된 보안 (Zero Trust)
- 인증 정보 탈취 방지: mTLS(상호 TLS) 바인딩과 컨텍스트 기반 액세스(CAA)를 통해 인증 정보가 지정된 신뢰 환경(예: Cloud Run 컨테이너) 내에서만 유효하도록 강제합니다. 이로 인해 인증 정보가 유출되더라도 외부 환경에서의 재사용(Replay)이 불가능합니다.
- 임퍼스네이션(가장) 불가: 서비스 계정과 달리 다른 사용자나 프로세스가 해당 에이전트의 권한을 가장하여 남용할 수 없는 구조입니다.
3.2 세밀한 최소 권한 제어 (Granular Control)
- 에이전트별로 독립적인 권한을 부여하여 철저한 격리가 가능합니다.
- 예시: ‘구글 지도 에이전트’는 지도 API 키에만 접근할 수 있고, ‘사용자 삭제’나 ‘비밀번호 재설정’과 같은 민감한 기능에는 접근하지 못하도록 원천 차단할 수 있습니다.
3.3 투명한 로깅 및 감사 (Auditing)
- 모든 활동 로그에 에이전트의 고유 ID가 명확히 남습니다.
- 에이전트가 단독으로 수행한 작업뿐만 아니라, 사용자를 대신해 수행한 작업에서도 에이전트와 사용자의 ID가 동시에 기록되어 추적성이 보장됩니다.
3.4 운영 편의성 및 자동화
- 자동 인식: 구글 클라우드 SDK와 애플리케이션 기본 인증(ADC)이 에이전트 ID를 자동으로 인식합니다.
- Secret Manager 연동: 별도의 키 관리 없이 Secret Manager 등 다른 서비스와 즉시 안전하게 연동할 수 있습니다.
4. 에이전트 ID의 기술적 구조 및 생성
에이전트 ID는 SPIFFE 표준을 기반으로 하며, 에이전트 배포 시 x509 인증서가 자동으로 프로비저닝됩니다.
4.1 생성 방법
- 코드와 함께 배포 시: Vertex AI SDK for Python 사용 시
identity_type=AGENT_IDENTITY플래그를 설정합니다. - 사전 생성: 에이전트 코드를 배포하기 전에 IAM 정책을 먼저 설정하고 싶은 경우,
identity_type필드만 지정하여 Agent Engine 인스턴스를 생성할 수 있습니다.
4.2 식별자 형식 (Principal Identifier)
에이전트 ID는 다음과 같은 구조를 가집니다: spiffe://TRUST_DOMAIN/ns/NAMESPACE/sa/AGENT_NAME
- TRUST_DOMAIN: 조직 ID 또는 프로젝트 번호를 포함한 도메인.
- NAMESPACE: 에이전트의 불변 리소스 경로.
- AGENT_NAME: 에이전트의 고유 ID.
5. 리소스 접근 및 권한 관리 전략
5.1 권한 부여 (IAM Allow Policy)
에이전트가 원활하게 작동하기 위해 다음의 사전 정의된 역할을 부여할 것이 권장됩니다:
roles/aiplatform.expressUser: 추론, 세션, 메모리 기능 접근.roles/serviceusage.serviceUsageConsumer: 프로젝트 할당량 및 SDK 사용 권한.roles/browser: 기본적인 구글 클라우드 기능 탐색.
5.2 접근 차단 (IAM Deny Policy)
특정 리소스에 대한 접근을 명시적으로 차단하거나, 보안 주체 액세스 경계(Principal Access Boundary) 정책을 설정하여 에이전트가 접근할 수 있는 리소스의 범위를 엄격히 제한할 수 있습니다.
5.3 Secret Manager를 통한 자격 증명 관리
에이전트 ID를 사용하여 서드파티 서비스의 API 키나 OAuth 인증 정보를 안전하게 검색할 수 있습니다.
- API 키 사용: Secret Manager에 키를 저장하고 에이전트 ID에만
secretmanager.secretAccessor역할을 부여합니다. - OAuth 사용: Client ID와 Secret을 Secret Manager에 저장하고, 에이전트가 런타임에 이를 호출하여 사용자 위임 인증을 수행하도록 구성합니다.
6. 결론 및 향후 고려 사항
에이전트 ID는 AI 에이전트 환경에서 보안과 운영 효율성을 동시에 달성할 수 있는 진보된 인증 모델입니다. 기존 서비스 계정 방식에서 발생하던 관리의 번거로움과 권한 격리의 어려움을 효과적으로 해결합니다.
주의 사항 및 권장 사항:
- CAA 정책 유지: 보안 강화를 위해 기본 설정된 컨텍스트 기반 액세스(CAA) 정책을 해제하지 않는 것이 강력히 권장됩니다.
- Cloud Storage 제한: 현재 에이전트 ID는 Cloud Storage의 레거시 버킷 역할(Legacy Bucket roles)을 지원하지 않으므로, 테스트 환경에서 먼저 검증이 필요합니다.
- 하위 호환성: 명시적으로 에이전트 ID 플래그를 설정하지 않을 경우 기존처럼 서비스 계정을 사용하므로, 기존 인프라와의 점진적인 전환이 가능합니다.
참고자료 다운로드
- 다운로드 | Agent Identity vs. Service accounts 비교표
https://docs.google.com/spreadsheets/d/1y9AHb_Pikd-8ST4ZQBpY-YnhjlG2HGlp1vQtwzbofcU/edit?usp=sharing - 다운로드 | Agent Identity vs. Service accounts 슬라이드
https://drive.google.com/file/d/1xl26bH1EQp4BwDsIY6mXFURb3Iwzd04x/view?usp=sharing
