AI 에이전트 ID 거버넌스와 접근 제어 설계

AI 에이전트 ID의 거버넌스 공백과 최소 권한, 위임 신뢰 체인, 제로 트러스트 기반 접근 제어 설계를 다룬다.

2026-08-14 · 최초 발행 2026-08-02

사고는 발생했지만 ID 관리는 따라가지 못하고 있다

Okta가 발표한 2026년 AI 보안 보고서는 AI 에이전트 보안 거버넌스의 간극을 보여준다. AI 에이전트 관련 보안 사고를 경험한 기업은 88%였지만, 에이전트 ID를 공식 액세스 제어 대상으로 관리하는 기업은 22%에 그쳤다. 현재의 Identity 시스템이 에이전트 ID를 효과적으로 처리할 수 있다고 확신한 보안 리더도 18%뿐이다.

사고가 88% 규모로 발생하는 반면 관리 체계는 22% 수준이라는 점에서, 약 4배의 거버넌스 공백이 존재한다. 이는 개별 에이전트 설정의 문제가 아니라 기존 IAM이 비인간 ID를 수용하는 방식 자체를 다시 설계해야 하는 문제다.

AI 에이전트는 기존 서비스 계정이나 봇과 구별되는 특성을 갖는다. 사람 개입 없이 API와 리소스에 접근하고, 프롬프트와 처리 데이터에 따라 접근 패턴이 바뀐다. 사람 사용자에서 오케스트레이터 에이전트, 다시 서브 에이전트로 이어지는 다단계 위임도 발생한다. 태스크 중 생성됐다가 완료 후 사라지는 에피메럴 ID가 늘어나며, 기업 내 에이전트 수가 인간 사용자 수를 넘어서는 상황도 전제해야 한다.

대표적인 사고 양상은 다음과 같다.

사고 유형 발생 메커니즘 피해 규모
과잉 권한 남용 에이전트에 부여된 불필요한 광범위 권한 악용 데이터 무단 접근·유출
프롬프트 인젝션 통한 권한 상승 악의적 입력으로 에이전트 행동 조작 승인되지 않은 API 호출
에이전트 ID 탈취 토큰/자격증명 하드코딩·노출 장기간 시스템 침투
멀티에이전트 신뢰 체인 오용 위임된 권한의 무제한 전파 횡적 이동(Lateral Movement)
감사 로그 부재 에이전트 행동 추적 불가 사고 원인 분석 불가

ID 발급부터 폐기까지 태스크 단위로 다루기

에이전트 ID는 사람 계정과 다른 수명 주기를 전제로 관리해야 한다. 등록 단계에서는 오케스트레이터(Orchestrator), 워커(Worker), 브로커(Broker)를 구분하고, 소유 팀·목적·허용 리소스 범위·만료 정책을 메타데이터로 등록한다. ID는 X.509 인증서 또는 JWT with short-lived TTL을 이용해 디지털 서명 기반으로 발급한다.

인증에는 클라우드 플랫폼의 네이티브 ID 브로커와 연결하는 Workload Identity Federation을 활용할 수 있다. 하드코딩된 자격증명을 없애고 동적 자격증명을 발급하는 Secretless Authentication, 그리고 에이전트 사이 통신을 보호하는 mTLS도 함께 고려 대상이다.

권한 부여는 태스크가 실제로 필요한 범위에서 출발한다. 최소 권한 원칙으로 스코프를 세분화하고, 태스크 범위로 제한한 임시 토큰을 발급한다. ABAC(Attribute-Based Access Control)를 적용하면 에이전트 컨텍스트, 태스크, 환경 속성에 따라 권한을 동적으로 결정할 수 있다.

태스크가 끝나면 자격증명을 즉시 회수한다. 이상 행동이 탐지되면 토큰을 실시간으로 무효화하고, 정기 감사 과정에서 좀비 에이전트 ID를 정리해야 한다.

위임 요청에이전트 ID 인증 요청단기 토큰 발급(Ephemeral Token)서브 에이전트 위임서브 에이전트 위임최소 권한 접근최소 권한 접근감사 로그 전송감사 로그 전송감사 로그 전송이상 행동 탐지정상이상알림사람 사용자(Human User)오케스트레이터 에이전트AI Agent Identity Provider(Okta / Azure AD / AWSIAM)서브 에이전트 A(데이터 조회)서브 에이전트 B(외부 API 호출)데이터베이스(Read-Only Scope)외부 API(제한적 엔드포인트)SIEM / 감사 로그 시스템이상 탐지엔진(1) 계속 실행(2) 즉시 토큰 폐기에이전트 격리보안 인시던트 대응

권한 모델은 기본 거부 상태에서 태스크에 필요한 권한만 산출하고, 실행이 끝나면 회수하는 흐름을 가져야 한다.

에이전트 권한 스코프 설계 원칙:

[DENY-ALL DEFAULT]
  ↓
[태스크 정의 기반 최소 스코프 산출]
  ↓
[단기 토큰 발급 (TTL: 15분~1시간)]
  ↓
[실행 중 동적 권한 축소 (Progressive Shrinking)]
  ↓
[태스크 완료 → 즉시 폐기]

에이전트별 API 엔드포인트 화이트리스트를 관리하고, 데이터 접근은 행 수준(Row-Level)과 컬럼 수준(Column-Level)으로 나눠 통제할 수 있다. 네트워크는 에이전트 전용 VLAN 또는 마이크로세그멘테이션으로 분리하며, Rate Limit와 Token Quota 같은 리소스 소비 한도도 에이전트별로 설정한다.

위임된 권한이 신뢰 체인을 벗어나지 않게 하기

멀티에이전트 구조에서는 권한이 연쇄적으로 전파된다. 체인 안의 한 지점이 침해되면 전체 경로가 위험해질 수 있다.

혼란한 대리인 공격(Confused Deputy Attack)은 에이전트가 다른 에이전트를 대신하면서 자신의 권한을 초과하는 작업을 수행하는 경우다. 낮은 권한의 서브 에이전트가 상위 에이전트 권한을 상속하는 권한 에스컬레이션 체인도 구조적 결함이 된다. 프롬프트 인젝션으로 위임 체인에 악의적 명령을 삽입하는 신뢰 체인 오염(Trust Chain Poisoning) 역시 대응 대상이다.

위임은 암묵적으로 상속되지 않고 명시적으로 선언돼야 한다. 위임 토큰에는 발급자(Issuer), 수신자(Subject), 허용 작업(Action), 리소스(Resource), 만료(Expiry)를 기록한다. 에이전트 간 위임은 OAuth 2.0 Token Exchange (RFC 8693)를 기반으로 구현할 수 있다.

서브 에이전트에는 상위 에이전트 권한의 부분집합(Subset)만 전달한다. 위임 깊이(Delegation Depth)는 최대 N단계로 제한하는 정책을 두고, 위임 체인 전체를 추적할 수 있는 감사 로그를 남겨야 한다.

제로 트러스트 관점에서는 에이전트 간 통신도 매 요청마다 신원을 다시 검증한다. Istio/Envoy 기반 서비스 메시(Service Mesh)로 mTLS를 적용하고, SPIFFE/SPIRE로 워크로드 ID를 표준화하는 방식이 여기에 해당한다.

에이전트 레지스트리와 사고 대응을 운영 체계에 넣기

기존 IAM 위에 에이전트 전용 관리 레이어를 두면 ID의 소유와 접근 관계를 추적할 수 있다. 레지스트리에는 이름, 유형, 소유자, 목적, 생성일, 만료일을 담은 메타데이터 카탈로그가 필요하다. 어떤 에이전트가 어떤 시스템과 API에 접근하는지 나타내는 의존성 맵도 관리 대상이다.

위험 등급은 접근 가능한 리소스의 민감도에 따라 Critical / High / Medium / Low로 분류한다. 생명주기 상태는 Active / Suspended / Deprecated / Decommissioned로 관리할 수 있다. 배포 전 Security Review를 의무화하고, 분기별 Entitlement Review와 미사용 ID 자동 탐지·비활성화 정책을 운영 과정에 포함한다.

사고 대응은 탐지, 격리, 복구의 흐름으로 설계한다. 탐지 단계에서는 정상 API 호출 패턴, 데이터 접근량, 실행 시간을 기준선으로 삼고, 비정상적 대량 데이터 조회·새로운 엔드포인트 접근·비업무 시간 활동을 이상 시그니처로 본다. UEBA(User and Entity Behavior Analytics)를 에이전트 행동 분석으로 확장하는 방식도 가능하다.

격리 시에는 토큰을 자동 폐기하고 에이전트 실행을 중단한다. MTTR 목표는 수분 이내다. 의심 에이전트의 아웃바운드 트래픽을 네트워크 수준에서 차단하고, 관련 데이터 접근 이력을 즉시 수집·보존해 포렌식에 대비한다.

복구 단계에서는 탈취된 토큰으로 접근할 수 있었던 리소스를 전수 조사한다. 격리한 에이전트는 재인증 후 재배포하며, Post-Incident Review에서 확인한 사고 패턴은 탐지 규칙에 반영한다.

플랫폼 환경에 맞춰 ID 기반을 선택하기

비교 항목 Okta AI Agent Identity Azure Managed Identity AWS IAM Roles for Workloads
에이전트 ID 발급 전용 에이전트 ID 타입 지원 시스템/사용자 할당 MI 역할 기반 임시 자격증명
멀티클라우드 지원 클라우드 중립(Agnostic) Azure 네이티브 AWS 네이티브
위임 모델 OAuth 2.0 기반 명시적 위임 제한적 위임 역할 체인(Role Chaining)
에피메럴 토큰 지원 (TTL 세분화) 지원 STS 기반 단기 토큰
감사 로그 통합 에이전트 감사 스트림 Azure Monitor 연계 CloudTrail 연계
멀티에이전트 위임 네이티브 지원 예정 제한적 제한적
ISMS 연계 타사 연동 필요 M365 컴플라이언스 연계 AWS Security Hub 연계
비용 구조 에이전트 수 기반 라이선스 Azure 구독 내 포함 추가 비용 없음

Azure 단일 클라우드 환경에서는 Azure Managed Identity와 Entra ID 통합을 선택할 수 있다. AWS 단일 클라우드 환경은 IAM Roles, AWS Secrets Manager, OIDC Federation 조합이 기준이 된다. 멀티클라우드 또는 하이브리드 환경은 Okta AI Agent Identity나 HashiCorp Vault 기반 중앙화가 대상이며, 온프레미스 중심 환경은 SPIFFE/SPIRE 오픈소스 프레임워크 기반 자체 구축을 고려할 수 있다.

ISMS-P와 제로 트러스트에 연결되는 통제 항목

AI 에이전트 ID 거버넌스는 ISMS-P의 인증·권한관리, 접근통제, 시스템 및 서비스 보안관리, 사고 예방 및 대응과 맞닿아 있다.

  • 2.5 인증 및 권한관리: 에이전트 ID 인증 방식, 권한 부여 원칙, 특수 계정 관리. AI 에이전트는 특수 계정의 새로운 유형이다.
  • 2.6 접근통제: 최소 권한 원칙과 업무 목적 외 접근 통제를 에이전트 접근 제어에 적용한다.
  • 2.9 시스템 및 서비스 보안관리: 에이전트 워크로드의 보안 구성을 관리한다.
  • 2.11 사고 예방 및 대응: 에이전트 보안 사고의 탐지·격리·복구 절차를 다룬다.

설계 검토에서는 기존 서비스 계정과 AI 에이전트 ID의 차이, 멀티에이전트 위임 신뢰 체인의 위협과 대응, NHI(Non-Human Identity) 관점의 접근 제어 아키텍처가 핵심 논점이 된다.

NIST SP 800-207의 제로 트러스트 원칙을 적용하면 모든 요청에서 ID·컨텍스트·행동 의도를 검증해야 한다. 접근은 태스크 범위 안에서 시간 제한을 두고 허용하며, 에이전트가 이미 침해됐다는 가정 아래 격리 체계를 설계한다.

표준화와 자동화가 향하는 방향

AI 에이전트 전용 IAM은 CNCF, NIST, ISO/IEC 차원의 ID 표준 제정이 가속화되는 흐름에 있다. OpenID Foundation은 비인간 ID(NHI) 프로파일을 개발 중이며, MCP(Model Context Protocol)도 에이전트 인증과 권한 부여를 내장하는 보안 확장 표준화 대상이다.

행동 분석은 LLM 기반 자연어 의도 분석으로 프롬프트 인젝션을 탐지하고, Agent Behavior Graph로 정상·이상 행동 패턴을 학습하는 방향을 포함한다. 행동 패턴을 바탕으로 권한을 자동 조정하는 Dynamic Policy Adjustment도 여기에 속한다.

거버넌스 운영은 Infrastructure as Code(IaC)로 ID 정책을 Policy as Code로 관리하고, CI/CD 파이프라인에 에이전트 보안 게이트를 통합하는 방식으로 자동화할 수 있다. 에이전트 접근 패턴의 규정 준수 여부를 실시간으로 모니터링하는 컴플라이언스 자동화도 필요하다.

기업은 03개월 동안 운영 중인 AI 에이전트를 전수 조사해 인벤토리를 만들고, 에이전트 ID 레지스트리 구축과 하드코딩된 자격증명 탐지·제거에 착수할 수 있다. 36개월에는 ID 발급·인증·폐기 자동화, 감사 로그와 SIEM 연동, 최소 권한 기반 권한 재설계를 진행한다. 6~12개월에는 멀티에이전트 위임 신뢰 체인 정책과 기술을 적용하고, AI 기반 이상 행동 탐지 및 ISMS-P 에이전트 ID 관리 항목 내재화를 추진한다.

관리되지 않는 에이전트 ID는 보이지 않는 내부자 위협이 된다. 에이전트 인벤토리, 태스크 단위 권한, 위임 추적, 신속한 격리를 하나의 운영 체계로 연결해야 한다.

Sources

  • Okta, "State of AI Security Report 2026" — AI 에이전트 보안 사고 통계 및 거버넌스 현황
  • NIST SP 800-207, "Zero Trust Architecture" — ZTA 원칙의 에이전트 적용 기준
  • IETF RFC 8693, "OAuth 2.0 Token Exchange" — 에이전트 간 위임 토큰 표준
  • CNCF SPIFFE/SPIRE, "Workload Identity Framework" — 에이전트 워크로드 ID 표준
  • Microsoft Azure, "Managed Identity Best Practices for AI Workloads 2026"
  • AWS, "IAM Roles Anywhere and Workload Identity Federation for Agentic AI"
  • KISA, "AI 서비스 보안 가이드라인 2026" — 국내 AI 에이전트 보안 관리 지침
  • OpenID Foundation, "Non-Human Identities (NHI) Working Group" — 비인간 ID 표준화 동향
AI 에이전트에이전트 ID접근 제어제로 트러스트보안 거버넌스