AI 에이전트는 사용자가 아니다: 이를 반영하는 아이덴티티 모델 구축하기

2026년 4월, 자동차 렌탈 회사들이 사용하는 B2B 플랫폼인 PocketOS의 전체 프로덕션 데이터베이스와 모든 볼륨 레벨 백업이 단 9초 만에 삭제되는 사건이 발생했습니다. 이 에이전트는 Cursor였으며, 최첨단 프론티어 모델 위에서 구동되었고, 그 개발자가 나중에 '벤더들이 개발자들에게 정확히 하라고 말하는 것'이라고 설명한 명시적인 안전 규칙으로 설정되어 있었습니다. 일상적인 스테이징 작업 중 크리덴셜 불일치에 직면하자, 충분한 권한을 가진 토큰을 발견하고 단 하나의 GraphQL 뮤테이션을 발행하여 모든 것을 지워버렸습니다.

시스템 프롬프트는 승인 없이 파괴적인 행동을 하지 말라고 지시했지만, 시스템 프롬프트는 강제되는 것이 아니라 자문(advisory)에 불과합니다. 사후 분석이 명확히 보여주듯이, 더 깊은 아키텍처적 실패는 비결정론적 에이전트에게 인간 운영자와 동일한 접근 권한을 부여하고, 그 접근 권한으로 무엇을 할지 제약하는 것을 자연어 지침에 의존했다는 점입니다.

이 에이전트는 인간 사용자와 같이 행동하지 않았습니다. 지속적으로 실행되었고 명시적인 지침을 무시했습니다. 또한 고정된 코드 경로와 감사자(auditor)가 읽을 수 있는 워크플로우가 없었기 때문에 백엔드 서비스처럼 행동하지도 않았습니다. 그 아래의 아이덴티티 레이어는 이 두 가지 형태 중 하나를 선택해야만 했고, 왜냐하면 그것이 우리가 제공하는 아이덴티티 인프라가 가진 형태들이기 때문입니다. 에이전트는 잘못된 것을 선택했지만, 올바른 형태 자체가 실제로 존재하지 않았기 때문에 올바르게 선택할 방법은 없었습니다.

이 글은 AI 에이전트를 인간 사용자나 기존의 기계적 정체성과는 별개로, 그 자체로 독립적인 1급(first-class) 정체성으로 취급해야 한다고 주장합니다. 이 주장은 전통적인 모델이 왜 무너지는지, 1급 에이전트 정체성이 무엇으로 구성되는지, 라이프사이클 관리가 어떻게 바뀌어야 하는지, 권한 부여가 프로비저닝 시점에 역할에 고정되기보다 요청별로 런타임(runtime)에서 평가되어야 하는 이유, 그리고 어떤 관측 가능성(observability) 요구사항이 발생하는지를 다룹니다. 목표는 완전히 새로운 정체성 기본 요소(identity primitive)를 구축하는 것이 아니라, 기존 인프라를 설계되지 않은 액터(actor) 클래스를 처리할 수 있도록 확장하는 것입니다.

레거시 모델이 무너지는 이유

OAuth 위임은 에이전트에게 사용자와 동일한 권한을 부여합니다. 사용자가 자신이 가진 범위(scope)로 에이전트에게 자신의 CRM 접근 권한을 부여하면, 에이전트는 특정 순간에 무엇을 요청받든 관계없이 모든 미래 상호작용에서 사용자가 할 수 있는 모든 것을 수행할 수 있습니다. 의도는 선택적 위임이지만, OAuth는 그 세밀함(granularity)에서 이를 표현할 수 없습니다. '내가 현재 작업 중인 계정의 연락처 정보만 에이전트가 볼 수 있게 하고, 법무 보관 대기열에 있는 것은 아무것도 볼 수 없게 해달라'고 말하려면 몇 안 되는 제품만이 노출하는 복잡한 범위 엔지니어링(scope engineering)이 필요합니다.

서비스 계정은 정반대의 문제를 가집니다. 에이전트는 자체 자격 증명(credential)을 얻지만, 이 자격 증명은 일반적으로 정적이고, 광범위하게 범위를 지정하며, 사용자 컨텍스트와 분리되어 있습니다. 문제가 발생하면 감사 로그에는 서비스 계정이 수행했다고만 기록될 뿐이며, 이는 거의 정보가 되지 못합니다. 위임 체인(chain of delegation)을 거슬러 추적할 방법도 없고, 어떤 사용자 요청이 해당 작업을 촉발했는지 볼 방법도 없으며, 전체 서비스 계정을 취소하지 않고 단일 에이전트 실행만 취소할 방법도 없습니다.

두 모델 모두 에이전트 사용량이 증가함에 따라 악화되는 네 가지 실패 모드를 공유합니다:

• 과도한 권한 부여(Over-permissioning): 자격 증명이 현재 작업에 에이전트가 필요로 하는 것보다 더 광범위한 권한을 가지고 있습니다. 이는 스코프(scope)가 일반적으로 기능 수준(billing.refund.issue_under_50_usd)보다는 리소스 수준(billing:write)에서 정의되기 때문입니다.
• 폭발 반경(Blast radius): 에이전트 프로세스, 메모리 또는 로그가 손상되면 운영 시스템에 대한 영구적인 접근 권한을 부여하는 자격 증명이 노출됩니다.
• 행동 컨텍스트 부족(Lack of behavioral context): 신원 계층은 "에이전트가 티켓을 요약하고 있는지"와 "에이전트가 환불을 처리하고 있는지"를 구별할 수 없습니다. 왜냐하면 두 작업 모두 이 두 가지 작업을 승인하는 동일하게 광범위한 스코프의 자격 증명을 제시하기 때문입니다.
• 자격 증명 확산(Credential sprawl): 에이전트가 통합되는 새로운 도구가 생길 때마다 프로비저닝, 저장, 로테이션 및 감사를 위한 또 다른 자격 증명이 필요합니다.

위 네 가지 실패 모드는 AI 에이전트 이전에 존재했으며 전통적인 자동화에서 발생하는 사고에서도 목격되었습니다. 그러나 에이전트는 두 가지 주요 이유로 이러한 문제를 악화시킵니다.

1. 자격 증명의 권한과 에이전트가 특정 순간에 수행하는 작업 사이의 격차가 전통적인 자동화보다 훨씬 넓습니다.
2. 에이전트의 동작은 비결정적(non-deterministic)이며, 이는 두 모델 모두에 내재된 가정과 충돌합니다.

서비스 계정이 안전한 부분은 호출하는 코드가 고정되어 있기 때문입니다. 에이전트의 "코드"는 자연어 입력을 해석하는 LLM(대규모 언어 모델)에 의해 안내되는 도구 호출 루프입니다. 자동화 코드의 결정론에 더 이상 의존할 수 없을 때, 자격 증명의 스코핑은 에이전트가 할 수 있는 일을 제한하는 몇 안 되는 제약 조건 중 하나가 됩니다.

일급 에이전트 신원(What a First-Class Agent Identity Looks Like)

일급 에이전트 신원은 단순히 라벨만 다른 서비스 계정을 넘어섭니다. 자체적인 생명 주기, 권한, 정책 바인딩 및 감사 추적을 가집니다. 이는 사용자나 전통적인 기계 신원과는 구조적으로 구별되는 신원 원시 요소(identity primitive)입니다.

OpenFGA는 Auth0의 Fine-Grained Authorization 제품의 기반이 되는 CNCF 권한 엔진으로서, 에이전트를 위한 권한 패턴(authorization patterns for agents)에서 이를 공식화합니다. 에이전트는 사용자와 동일한 권한 계층 구조에 참여하는 [퍼스트 클래스 주체(first-class principals)]로 모델링되며, 권한 모델 내에서 고유한 유형을 가지고 리소스와의 관계도 가지지만, 사용자의 역할로부터 단순히 상속되는 것이 아니라 역량(capabilities)에 범위가 지정되고 작업(tasks)에 바인딩된 권한을 가집니다.

구체적으로, 퍼스트 클래스 에이전트 ID는 네 가지 속성을 갖습니다:

• 사용자나 서비스 계정과 구별되는 디렉토리 식별자: 이 식별자는 에이전트 유형, 에이전트 정의 버전 등의 메타데이터를 포함하며, 이상적으로는 해당 행동에 대한 책임 주체를 명시합니다.
• 비즈니스 용어로 정의된 범위 지정 권한: 이는 에이전트가 사용자를 대신하여 행동할 때조차도 사용자에게 부여된 권한과는 별개입니다.
• 위임 컨텍스트(Delegation context): 에이전트가 누군가를 대신하여 행동할 때, 행위자(actor)로서의 에이전트와 주체(subject)로서의 사용자를 모두 기록합니다. 하위 시스템은 단순히

백엔드 서비스는 감사자가 읽을 수 있는 정적인 워크플로우와 코드 경로를 가지고 있으므로, 광범위하게 범위가 지정된 자격 증명(credential)은 코드가 수행하는 작업에 의해 제약됩니다. 에이전트는 이러한 제약 중 어느 것도 없습니다. 에이전트의 워크플로우는 LLM에 의해 런타임에 결정되며, 코드 경로는 신뢰할 수 없는 입력(untrusted input)을 받는 도구 호출 루프입니다. 따라서 자격 증명은 코드가 수행하지 않는 작업을 해야 하며, 이를 프로비저닝 시점이 아니라 요청 수준에서 수행해야 합니다. OAuth 2.0 Token Exchange (RFC 8693)은 이러한 종류의 동적이고 요청 범위가 지정된 위임(delegation)을 지원하도록 설계되었으며, 이는 Auth0의 Token Vault가 기반으로 하는 토대입니다.

임시 액터(Ephemeral Actors)를 위한 생명주기 관리

사용자 계정은 수년 동안 존재하고, 서비스 계정은 서비스의 수명 주기 동안 존재합니다. 에이전트 ID는 그 중간 어딘가에 존재하며, 종종 스펙트럼의 더 낮은 곳에 위치합니다. 지원 티켓을 처리하는 장기 실행 에이전트는 배포(deployment)의 수명 주기 동안 지속될 수 있습니다. 단일 사용자 질의에 응답하기 위해 한 번 실행되는 작업 범위 에이전트는 해당 작업 기간 동안만 존재할 수도 있습니다.

프로비저닝은 거의 상호작용적이지 않습니다. 동의(Consent)는 사용자가 에이전트를 사용하는 애플리케이션을 승인할 때 발생하며, 에이전트 ID는 그 애플리케이션에 의해 온디맨드(on demand)로 생성됩니다. 프로비저닝은 인간의 승인 워크플로우보다는 프로그램적이고,멱등성(idempotent)을 가지며, 에이전트 정의와 연결되어야 합니다.

실행 컨텍스트 자격 증명(Execution-context credentials)은 에이전트의 정체성을 확립하는 데 사용되는 자격 증명과 같아서는 안 됩니다. 정체성은 에이전트가 누구이며 원칙적으로 무엇을 할 수 있는지를 확립하는 반면, 실행 컨텍스트 자격 증명은 에이전트 앞에 놓인 특정 작업에 범위가 한정된 단기 토큰으로, 특정한 호출을 승인합니다. 이것이 Auth0의 Token Vault가 OAuth 계층에서 구현하는 패턴입니다. 즉, 에이전트는 연결된 서비스의 장기 지속 리프레시 토큰(long-lived refresh token)을 보유하지 않고, 대신 OAuth 2.0 토큰 교환(Token Exchange)을 통해 필요할 때 액세스 토큰(just-in-time access token)을 요청합니다. 만약 에이전트가 손상된다 하더라도 노출되는 자격 증명은 현재 보유하고 있는 단기 토큰뿐입니다.

아래 다이어그램은 이 흐름이 실제에서 어떻게 보이는지 보여줍니다. 여기에는 두 단계가 있습니다. 첫 번째는 애플리케이션이 처음 승인될 때, 사용자가 동의를 부여하고 정체성 제공자(identity provider)는 장기 지속 리프레시 토큰을 Token Vault에 저장하며, 그곳에 보관됩니다. 그런 다음, 에이전트가 수행해야 하는 각 작업마다 해당 특정 작업에 범위가 한정된 단기 액세스 토큰을 요청합니다. 정체성 제공자는 정책과 비교하여 요청을 평가하고, 며칠 동안 지속되는 것이 아니라 몇 분 동안 지속되는 토큰을 반환하며, 에이전트는 이를 단일 도구 호출(tool call)에 사용한 후 폐기합니다. 만약 에이전트가 손상된다 하더라도 공격자는 메모리에 우연히 있는 단기 토큰만 상속받게 되며, 정체성 제공자에서 연결을 취소하면 모든 미래의 토큰 교환이 즉시 무효화됩니다.

[

Sequence diagram showing the provisioning of agent credentials](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ffeaxp31k09o5vappx4iw.png

에이전트의 일시 중지(Suspension) 및 폐기(decommissioning) 또한 쉽고, 빠르며, 정확해야 합니다. PocketOS 사고를 기억해 보세요: 에이전트가 통제 불능 상태에 빠졌을 때, '무슨 일이 일어났는지 파악하는 동안 다음 10분 동안 에이전트의 데이터베이스 쓰기 권한을 취소할 수 있는' 것과 같은 것이 없었습니다. 이 에이전트가 사용하던 자격 증명(credential)은 지속적인 권한(standing authority)을 부여했고, 지속적인 권한은 전체 자격 증명 수준에서만 취소될 수 있습니다. 단일 ID 제공자(identity provider)를 통해 토큰 발급을 중앙 집중화하면, 연결을 취소하는 것만으로 미래의 토큰 교환이 즉시 무효화되어 시스템의 나머지 부분은 계속 실행되면서 더 세밀한 권한 취소가 가능해집니다.

정책 기반 권한 부여 (Policy-Driven Authorization)

정적 역할 할당(Static role assignment)은 사용자 및 서비스 ID에 대한 전통적인 모델입니다: 행위자(actor)는 역할을 가지며, 그 역할이 권한을 부여하고, 이 권한은 동작과 비교하여 확인됩니다. 이는 행동이 예측 가능한 경우에는 잘 작동하지만, 에이전트에게는 부적절합니다. 에이전트는 원칙적으로 광범위한 기능에 접근할 수 있지만, 주어진 어떤 작업에서도 해당 작업 자체에 의해 결정되는 좁은 하위 집합만을 사용해야 합니다.

더 나은 모델은 권한 부여를 ID가 아닌 행동과 연결하고, 실행 시간(runtime)에 특정 요청을 기반으로 평가하는 것입니다. 여기에는 두 가지 관련 패턴이 있습니다. 속성 기반 접근 제어(Attribute-based access control, ABAC)는 상황적 속성을 고려합니다: 에이전트가 대리하여 행동하는 사용자, 리소스, 시간, 동작, 그리고 모든 작업 매개변수입니다. 관계 기반 접근 제어 (Relationship-based access control, ReBAC)는 더 나아가 엔티티 간의 관계 측면에서 권한 부여를 표현합니다. 이로 인해