AI 에이전트의 정체성: 누가 행동했으며, 누구의 권한으로?

만약 당신이 에이전트에게 'Acme을 At Risk로 이동시키고, 계정 소유자에게 태스크를 생성하며, 갱신 계획을 준비하라'고 지시한다고 가정해 봅시다. 에이전트는 정확히 그렇게 합니다.

당신의 CRM은 무엇이 발생했다고 기록해야 할까요?

Alex가 요청했기 때문에 마지막 수정자는 Alex인가? 에이전트가 작업을 수행했기 때문에 마지막 수정자는 Renewal Agent인가? 아니면 두 사실 모두 중요하기 때문에, Alex를 대신하여 Renewal Agent가 수정했는가?

이것은 사용자 경험(UX)의 세부 사항처럼 보입니다. 하지만 그렇지 않습니다. 이것은 **AI 에이전트 정체성(AI agent identity)**에 대한 문제입니다. 그리고 솔직한 대답은 세 번째 경우입니다. 거의 어떤 엔터프라이즈 시스템도 이를 기록할 공간을 가지고 있지 않습니다.

AI 에이전트 정체성이란 무엇인가?

AI 에이전트 정체성은 AI 에이전트에게 시스템 내에서 고유하고 검증 가능한 자신만의 정체성을 부여하는 관행입니다. 이 정체성은 해당 에이전트에게 행동을 요청한 인간 사용자나, 에이전트가 빌려 쓸 수 있는 공유 서비스 계정과 분리되어 있습니다. 이는 에이전트가 수행하는 모든 행동이 오직 그 에이전트에게 귀속될 수 있도록 존재합니다.

어려운 점은 정의가 빠뜨리는 부분에 있으므로, 바로 이름을 붙여보겠습니다:

• **정체성(Identity)**은 '누가 이 작업을 수행했는가?'에 답합니다. 이를 **행위자(actor)**라고 부릅니다.
• **권한(Authority)**은 '누구의 권한이 이것을 가능하게 했는가?'에 답합니다. 이를 **권한 주체(authority)**라고 부릅니다.

정체성 용어에서 **주체(principal)**란 시스템이 인증하고 권리를 부여할 수 있는 모든 개체를 의미합니다. 인간 사용자의 경우, 행위자와 권한 주체는 동일한 주체입니다. 따라서 엔터프라이즈 소프트웨어는 항상 하나의 필드만 구축해 왔습니다. 사용자가 인증하고, 사용자는 역할을 가지며, 사용자가 행동을 수행하고, 감사 로그가 사용자 기록을 남깁니다. 시작부터 끝까지 단일 주체(principal)인 것입니다.

에이전트는 이 방식을 깨뜨립니다. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)을 통해 라우팅되는 동일한 데이터베이스 쓰기를 생성하는 두 개의 체인을 고려해 봅시다:

Alex            ->  Renewal Agent  ->  MCP  ->  HubSpot
Renewal policy  ->  Renewal Agent  ->  MCP  ->  HubSpot

둘 다의 경우, Renewal Agent가 행위자(actor)입니다. 첫 번째 사례에서는 사람이 권한을 가지고 있고, 두 번째 사례에서는 아무도 키보드 앞에 있지 않은 상태에서 03:14에 실행되므로, 권한은 조직 정책과 에이전트 자체에 부여된 권한입니다. 같은 행위자, 같은 쓰기 권한이지만 완전히 다른 책임 소재를 가집니다. 하나의 필드로 이들을 구분할 수 없습니다.

따라서 본문의 주장은 다음과 같습니다: 모든 프로덕션(production) 에이전트는 정체성(identity)을 가져야 하지만, 모든 에이전트가 자체적인 권한(authority)을 가져야 하는 것은 아닙니다. 이것은 두 가지 별개의 결정입니다. 이 둘을 혼동하면 흔히 발생하는 두 가지 실패 모드를 초래합니다: 인간의 이름 뒤에 숨는 에이전트와 업무가 필요로 하는 것보다 훨씬 많은 권한을 부여받는 에이전트들입니다.

엔터프라이즈 소프트웨어는 한 종류의 행위자를 위해 구축되었다

정체성 시스템(Identity systems)은 수십 년 동안 사람들에게 능숙해지는 데 시간을 보냈습니다. 그런 다음, 미리 정의된 작업을 수행하는 기계들을 위해 두 번째 범주인 애플리케이션 및 서비스 계정을 추가했습니다. 이것이 우리에게 깨끗한 두 개의 상자 모델을 제공했습니다: 결정하는 인간과 실행하는 소프트웨어입니다.

두 번째 상자는 이제 엄청나게 커졌습니다. Palo Alto Networks의 2026 Identity Security Landscape는 2,900명 이상의 사이버 보안 의사결정권자를 대상으로 조사했으며, 기계 정체성이 인간을 능가하여 109:1이라고 보고합니다. 발행사가 정체성 보안 제품을 판매하기 때문에 이를 정확한 수치라기보다는 방향성으로 간주하십시오. 이 산업에서 그 상자에 붙인 이름은 '비(非)인간 정체성(non-human identity)'이며, 그 배경에 있는 운영상의 관심사는 스프로울(sprawl), 즉 아무도 소유하거나 순환시키지 않는 수천 개의 장기 생존 자격 증명(credentials)입니다.

에이전트는 이 두 상자 어디에도 맞지 않습니다. 에이전트는 추론하고, 어떤 도구를 호출할지 선택하며, 어떤 레코드를 수정할지 결정하고, 아무도 지정하지 않은 일련의 과정을 시작할 수 있습니다. 이것은 인간의 상자입니다. 또한 기계 자격 증명(machine credentials), 결정론적 정책(deterministic policy), 그리고 엄격한 권한 범위 설정(tight privilege scoping)이 필요합니다. 이것은 서비스 계정의 상자입니다.

AI 에이전트는 서비스 계정이어야 할까요, 아니면 사용자 계정이어야 할까요?

둘 다 아닙니다. 에이전트를 서비스 계정(service account)으로 취급하면 자격 증명 위생(credential hygiene)은 확보하지만, 그 에이전트가 스스로 선택했다는 사실을 잃게 됩니다. 사용자 계정(user account)으로 취급하면 출처 추적(attribution)은 가능해지지만, 은연중에 사람의 전체 권한을 부여하게 됩니다. 이 두 가지 방식 모두 하나의 주체 모델(one-principal model)이 두 개의 주체 현실(two-principal reality)과 충돌하는 상황입니다.

행위자(Actor)와 권한(Authority)은 별개의 개념이다

행위자와 권한을 분리하면 많은 혼란스러운 논쟁들이 해소됩니다.

'그냥 에이전트가 사용자의 OAuth 토큰을 쓰게 하자'는 것이 가장 흔한 지름길입니다. 이는 권한에 대한 진술이지만, 실수로 행위자를 파괴합니다. 에이전트는 적절한 권한을 얻고 그 과정에서 투명해지는데, 왜냐하면 에이전트가 취하는 모든 행동이 인간 본인의 행동과 구별할 수 없기 때문입니다. 이는 에이전트가 보고서를 요약할 때는 용인될 수 있습니다. 하지만 에이전트가 03:14에 어떤 결정을 내렸을 때는 오해를 불러일으킵니다.

이 두 가지 사실(행위자와 권한)을 모두 유지하는 메커니즘은 이미 ID 영역에 존재합니다. OAuth의 on-behalf-of 플로우와 RFC 8693 토큰 교환 방식은 한 주체가 다른 주체의 권한으로 행동하면서도 구별 가능하게 남도록 하며, 동일한 토큰 내에 subject와 actor를 담을 수 있게 합니다. 부족했던 것은 암호학(cryptography)이 아닙니다. 에이전트에 이를 사용하겠다는 기업적 관행과 다운스트림 시스템에서 그 결과를 기록할 필드입니다.

Microsoft 자체 가이드라인은 이것을 모든 에이전트 ID 모델이 답해야 하는 질문으로 제시합니다: 이 행동이 사용자 대신 수행된 것인가, 아니면 애플리케이션 자체가 수행한 것인가? 이것이 공급업체 관점에서 본 행위자/권한의 구분이며, 이는 귀사의 CRM에 있는 Last Modified By 필드가 구조적으로 답변할 수 없는 질문입니다.

에이전트 자율성의 다섯 가지 모델

'AI 에이전트(AI agent)'는 너무나도 다른 배포 방식을 설명하는 용어라 하나의 ID 정책으로 모두 커버할 수 없습니다. 아키텍처별로 분류하기보다 자율성(autonomy) 순서로 분류하면 다섯 가지 모델이 나오며, 각 모델이 필요로 하는 가시적 ID의 양은 목록을 따라 내려갈수록 증가합니다.

1. 보이지 않는 조수(The invisible assistant). 에이전트는 사용자의 권한을 사용하여 검색하거나, 요약하거나, 초안을 작성합니다. 비즈니스 애플리케이션의 관점에서 인간은 여전히 행위자(actor)이며, 이는 문제가 되지 않습니다. 낮은 위험도의 지원의 경우, 별도의 주체(principal)를 추가하면 아무것도 통제할 것이 없는 거버넌스 오버헤드만 발생합니다.

2. 명명된 기능(The named capability). 조직은 인식 가능한 "갱신 에이전트(Renewal Agent)" 또는 "연구 에이전트(Research Agent)"를 만듭니다. 사람들은 이를 호출하며, 여전히 호출하는 사용자의 권한으로 실행됩니다. 이 에이전트는 독립적인 직원이 되지는 않지만 제품으로서의 정체성을 가집니다. 대부분의 내부 AI 도구는 여기에 속하며, 대부분은 그래야 합니다.

3. 위임된 에이전트(The delegated agent). 에이전트는 자체적인 정체성을 가지고 누군가 위임한 권한 하에 행동합니다. 따라서 시스템은 subject: Alex, actor: Renewal Agent와 같이 기록할 수 있습니다. 기업의 대부분의 에이전트 활동은 여기에 속할 것으로 예상되는데, 이는 감사(audit)를 통과하는 첫 번째 단계이기 때문입니다. 누가 작업을 원했는지와 무엇이 수행했는지를 모두 재구성할 수 있습니다.

4. 자율 에이전트(The autonomous agent). 자체적인 정체성 및 자체적으로 제한된 권한을 가집니다. 사람의 요청을 기다리기보다는 조직 정책에 따라 모니터링하고, 결정하며, 행동합니다. 아무도 현장에 존재하지 않기 때문에 인간의 권한을 빌리는 것은 부정확할 뿐만 아니라 허구입니다.

5. 디지털 동료(The digital coworker). 에이전트가 자체 계정과 존재감을 가진 조직 참여자가 됩니다. 동료들은 마치 다른 팀원에게 하듯이 이와 상호작용합니다. 여기서 정체성은 선택 사항이 아닙니다. 에이전트는 1급(first-class) 조직 계정이 필요하며, 왜냐하면 다른 사람들이 그것을 언급하고, 작업을 할당하며, 동료의 행동처럼 그 행동에 귀속될 것을 기대할 것이기 때문입니다.

이 다섯 가지 모델은 선택해야 하는 경쟁하는 표준이 아닙니다. 이것들은 사다리 단계(rungs)이며, 유용한 원칙은 방향성적입니다: 에이전트가 독립적으로 행동할수록, 인간의 정체성 뒤에 숨는 것이 덜 용인됩니다.

오늘날 6개 플랫폼이 에이전트(Agent)의 정체성을 처리하는 방법

이것은 의견이라기보다는 아키텍처에 관한 것입니다. 여섯 개의 플랫폼이 서로 다른 방식으로 동일한 구분을 채택했으며, 이들 사이에는 공유된 표준이 없습니다.

따라서 정확한 점수표는 오늘날 두 주체 모두를 기록하는 세 개의 플랫폼, 권한 측면을 다루는 두 개, 그리고 작업이 아직 진행 중임에도 불구하고 두 주체를 명명한 프로토콜 유지 관리자들로 구성됩니다. Microsoft, Google, GitHub는 표준에 대해 조정하지 않고 동일한 두 주체 구조에 도달했으며, MCP 유지 관리자들은 이를 좁혀야 할 격차(gap)로 독립적으로 명명했습니다. 한 가지 구조에 네 번의 등장은 이 구분이 유행처럼 선택된 것이 아니라 문제에 의해 강제되고 있음을 시사합니다.

에이전트 권한은 상속이 아닌 교차점이다

에이전트가 식별 가능한 주체가 되면, 두 번째 가정이 깨집니다. 즉, _내가 할 수 있다면 내가 사용하는 모든 에이전트도 그것을 할 수 있어야 하는가?_는 아닙니다.

명백히 그렇지 않습니다. 최고 매출 책임자(chief revenue officer)는 모든 기회(opportunity)를 보고, 소유권을 변경하고, 할인액을 승인하고, 기록을 삭제하며, 고객 데이터를 내보낼 수 있습니다. 이 임원에게 의해 호출된 파이프라인 분석 에이전트는 기회를 읽고, 몇 가지 필드를 업데이트하며, 작업을 생성할 필요가 있습니다. 그 외에는 아무것도 아닙니다.

따라서 정신적 모델은 에이전트 권한 = 사용자 권한이 아닙니다. 다음과에 가깝습니다:

effective permissions = user authority ∩ agent permissions ∩ workflow policy

상속이 아닌 교차점(intersection): 한 가지 부여가 아래로 흐르는 것이 아니라, 모든 행동을 허용하기 위해 반드시 통과해야 하는 세 가지 제약 조건입니다.

이는 가설이 아닙니다. ServiceNow가 이를 구현하여 제공합니다: 에이전트는 '동적 사용자(Dynamic user)'로 실행되며, 호출하는 사용자의 권한을 상속받고, 역할 마스킹(role-masking)은 에이전트가 수행할 수 있는 역할을 호출하는 사용자의 역할 중 하위 집합으로 최소화합니다. 이것은 호출하는 사용자의 권한과 에이전트별 부여된 권한의 교집합이며, 현재 버전에서는 선택 사항이 아니라 필수 구성입니다.

여기에는 더 광범위한 변화가 숨어 있습니다. 전통적인 역할 기반 접근 제어(RBAC)는 '이 사용자가 무엇을 할 수 있는가?'를 묻습니다. 에이전트 시스템은 훨씬 풍부한 질문을 해야 합니다: '이 에이전트가 이 사용자의 권한 하에, 이 도구를 통해, 이 리소스에 대해, 이 상황에서, 지금 당장 무엇을 할 수 있는가?' 이것은 정책 문제입니다. 그리고 그 정책은 에이전트 내부에 존재할 수 없습니다. 왜냐하면 프롬프트 형태의 가드레일(guardrail)은 단지 제안이기 때문입니다. 에이전트가 쿼리해야 하는 레이어에 존재하는 규칙만이 유효합니다. 프롬프트에 존재하는 규칙들은 하나의 교묘한 주입 공격만으로도 누출될 수 있습니다.

왜 MCP 권한 부여가 이제 에이전트 정체성 문제가 되었는가

Model Context Protocol(MCP)은 에이전트와 엔터프라이즈 도구 간의 일반적인 인터페이스가 되고 있으며, 이로 인해 정체성 가정이 시험대에 오르고 있습니다. 에이전트는 곧 에이전트 -> MCP 서버 -> CRM -> 청구 시스템 -> 다른 에이전트와 같은 체인을 실행할 수 있게 될 것입니다.

순진한 구현 방식은 사용자의 베어러 토큰(bearer token)을 이 전체 체인으로 전파합니다. 명세는 규범적인 언어로 이를 금지합니다: 클라이언트는 해당 서버의 권한 부여 서버가 발행한 토큰 외에는 MCP 서버에 토큰을 보내서는 안 되며, 서버는 자신들의 리소스에 유효한 토큰만 수락해야 합니다. 토큰은 의도된 대상(intended audience)으로서 특정 서버를 위해 발행되었는지 검증되어야 합니다 (RFC 8707).

청중 바인딩(Audience-binding)은 좋은 규칙입니다. 이는 광범위한 권한을 가진 서비스가 호출자(caller)를 대신하여 그 권한을 사용하도록 속는 혼란스러운 대리인 문제(confused-deputy problem)를 해결합니다. 하지만 이것이 정체성 문제(identity problem)를 해결하지는 못하며, 유지 관리자들 역시 그렇게 말합니다. 그들의 로드맵은 매우 직접적입니다: MCP 권한 부여는 동의 시 브라우저가 있는 사람을 가정하지만, 호출자는 점점 더 자신만의 정체성을 가진 에이전트, 사용자 부재 시 작동하는 클라우드 워크로드(cloud workload), 또는 부모보다 좁은 권한을 가져야 하는 서브-에이전트를 생성하게 됩니다. 그들은 "MCP 서버가 자체 정체성이나 사용자 위임된 정체성을 통해 에이전트에 의해 도달될 수 있는 의견이 명확한 방식"을 요구합니다.

이는 프로토콜을 유지 관리하는 사람들이 언급한 두 가지 원칙이며, 미완료 작업으로 목록화되어 있습니다.

실질적인 실패는 실제 데이터에 연결해 본 사람이라면 누구나 익숙하게 느낄 수 있는 것입니다. 행 수준 보안(Row-level security)은 주어진 사용자가 어떤 행을 볼 수 있는지 결정하는 데이터베이스 규칙입니다. 정체성 전파를 건너뛰면, 서버가 호출자의 정체성을 전달하지 않았기 때문에 조용히 적용을 멈추고, 모든 호출자는 모든 것을 보게 됩니다. MCP는 정체성 문제를 제거하지 않습니다. 단지 그것을 해결하는 것을 피할 수 없게 만듭니다.

감사 로그에서 액션 그래프로

전통적인 감사 로그(audit logs)는 하나의 사실을 기록합니다: Alex가 14시 32분에 필드 X를 A에서 B로 변경했다. 한 행위자, 하나의 행동, 하나의 타임스탬프입니다.

이러한 형태로는 에이전트의 작업을 담아낼 수 없습니다. 자율적인 행동에 대해 중요한 질문들은 일련의 사슬을 형성합니다: 누가 이것을 촉발했는가? 어떤 에이전트가 행동하기로 결정했는가? 어떤 컨텍스트를 사용했는가? 어떤 정책이 그것을 승인했는가? 인간의 승인이 필요했는가? 어떤 도구를 호출했는가? 무엇을 변경했는가? 그 결과 무슨 일이 일어났는가?