Data Eng Wiki

AI Agent Identity and Security

7 min read

AI Agent Identity and Security

AI 에이전트에 검증 가능한 정체성을 부여하고 “누가·무엇을·왜” 했는지 추적하는 체계

핵심 개념

AI Agent Identity and Security는 자율 에이전트가 도구를 호출하고 행동할 때 “특정 사용자를 대신해 행동하는 특정 에이전트”임을 암호학적으로 증명하고, 그 provenance(출처)를 hop 간 전파하는 체계다. 에이전트가 다단계로 일하면서 다른 에이전트·도구·시스템을 호출하면, 기존 정체성 모델로는 각 hop이 generic service identity만 보게 되어 감사·컴플라이언스·인시던트 대응이 불가능해진다.

왜 기존 정체성 모델로 부족한가

전통적 IAM은 human과 workload(NHI — service account, API key)를 중심으로 설계됐다. 그러나 에이전트는 “타인을 대신해(agency) 행동하도록 인가된 엔티티”다. 두 가지 핵심 문제:

  1. Agency 미표현: 에이전트는 보통 사람을 대신해 작업하는 workload인데, 기존 모델은 이 대리 관계를 표현 못함
  2. Provenance 유실: 실행 컨텍스트(원 사용자, 중간 에이전트)가 hop 간 드롭 → 불완전한 감사, fine-grained 정책 활용 불가

에이전트 워크플로의 특성: 위임이 기본, 구성적(에이전트가 에이전트·도구·시스템 호출), 동적(중간 결과로 계획 진화).

Uber 아키텍처 (Zero Trust 확장)

  • Agent Registry: 에이전트-워크로드 연결의 source of truth
  • STS (Security Token Service): 동적 trust broker. 광범위·장수명 자격증명 대신 per-hop 단명·scoped JWT 발행
  • MCP Gateway: AI Agent Mesh → 시스템 호출의 정책 집행점(tool 접근 + 민감 데이터 redaction)
  • AI Gateway: LLM 호출 중재 + AI Guard(prompt injection/jailbreak/PII redaction)

정체성 발급 흐름

  1. 워크로드가 SPIRE에서 SVID(SPIFFE Verifiable ID) 획득 — 컴퓨트 환경 정당성 증명
  2. SDK가 SVID로 인증해 STS에 JWT 요청
  3. STS가 Agent Registry로 agent_id가 그 워크로드에서 실행 인가됐는지 검증(워크로드의 에이전트 사칭 방지)
  4. STS가 JWT 발행 → 다음 hop에 사용

핵심 설계

  • Single-hop, 단명 토큰: 특정 Audience claim + 분 단위 TTL → A→B용 토큰을 가로채 DB 호출에 재생 불가
  • Full contextual attribution: 토큰에 검증된 actor chain(engineer → Oncall Agent → Investigation Agent …) 임베드 → 전체 lineage 기반 감사·정책. OAuth 2.0 Token Exchange(RFC 8693) 기반 커스텀
  • Paved path: Standardized A2A Client가 STS 토큰 교환·actor chain 전파를 자동화 → secure path = easiest path

Least-Privilege Gateway와의 관계

Data Governance에서 다룬 Least-Privilege AI Agent Gateway(dew_260)가 “에이전트가 무엇에 접근할 수 있는가”(권한 최소화)에 초점이라면, Agent Identity는 “누가 행동했는가”(정체성·attribution)에 초점이다. 둘은 상보적 — Gateway가 정책 집행점이라면 Identity는 그 정책이 평가할 actor chain을 제공한다.

실행 환경 격리 — Palana (Grab)

Uber 아키텍처가 “정체성·attribution”에 초점이라면, Grab의 Palana는 에이전트가 어디서 어떻게 실행되는가의 격리·containment에 초점을 둔 Kubernetes-native 실행 플랫폼:

  • isolation이 trust의 단위: 에이전트당 namespace·service account·storage·network policy·Vault scope. 프레임워크가 완벽한 multi-tenant isolation을 가정 안 해도 안전
  • proxy-only secret: 에이전트는 placeholder(TOKEN_GITHUB_PAT)만 보고, proxy가 outbound 시 Vault의 실제 자격증명으로 교체 → prompt injection·의존성 침해 시 장수명 자격증명 노출 방지. “credential 읽기”와 “credentialed 요청 유발”의 분리가 high-leverage
  • egress가 control point: 금지가 아닌 observable·policy-mediated. L3/L4(NetworkPolicy + Cilium, containment) + L7(Envoy/OPA, host/method/identity별 audit) 이중 제어 — “기본은 nothing, 필요한 internal service만”
  • control plane은 에이전트 밖에: kill switch가 요청이 아닌 네트워크 경로 제거(safety control). idle shutdown은 compute 정지 + state 보존
  • identity: raw user identity를 authoritative owner로 유지(RBAC subject), 향후 SPIFFE/SPIRE로 “agent on behalf of user” — Uber STS 접근과 수렴

두 접근은 상보적: Uber STS는 provenance 전파(actor chain in JWT), Palana는 실행 격리(namespace + proxy). 둘 다 SPIFFE/SPIRE를 기반으로 하며 “agents on behalf of users with cut-down permissions”를 지향. north star: “useful autonomy를 boring하게 — attributable·inspectable·revocable·recoverable”.

3계층 비전 (Uber)

  1. Identity & Trust Foundation: 검증 가능한 에이전트 정체성 + 위임 체인 보존
  2. Dynamic Access Control: 컨텍스트 기반 권한, human-in-the-loop, 워크플로 인가
  3. Unified Enforcement Plane: 도구·세션·프로토콜 전반의 일관된 정책·관측성

표준 동향

IETF WIMSE 워킹그룹, “AI Agent Authentication and Authorization”(draft-klrc-aiagent-auth) 드래프트.

연관 개념

Source: Solving the Identity Crisis for AI Agents at Uber, Nabin Debnath - Building a Least-Privilege AI Agent Gateway, Palana Part 1 - Why Grab Built a Secure Platform for AI Agents, Palana Part 2 - Architecting Isolation Identity and Auditability

그래프 뷰

백링크