Agent2026년 10월 8일

사람의 계정을 물려주지 않는 위임 — 에이전트의 워크로드 신원과 범위 제한 토큰 설계

#non-human-identity#workload-identity#spiffe#oauth-token-exchange#rich-authorization-requests

여행 예약을 맡은 에이전트가 사용자의 OAuth 액세스 토큰을 그대로 받아 예약 API를 호출한다고 하자. API 서버의 감사 로그에는 사용자가 직접 한 예약과 에이전트가 한 예약이 같은 주체로 남고, 에이전트가 프롬프트 인젝션(prompt injection)에 넘어가 의도하지 않은 예약을 냈을 때 그 에이전트의 권한만 철회할 방법도 없다. 토큰을 폐기하면 사용자의 다른 세션까지 함께 끊기고, 토큰을 그대로 두면 에이전트는 사용자가 가진 범위 전체를 계속 행사한다. 에이전트가 예약, 주문, 데이터 조회 같은 행위를 맡는 순간 "누가 무엇을 할 수 있는가"라는 인가의 질문은 사람 하나가 아니라 사람과 그 사람을 대리하는 소프트웨어의 쌍을 대상으로 다시 답해야 한다.

이 글은 에이전트에 사람의 계정 대신 고유한 비인간 신원(non-human identity)과 범위가 제한된 위임 자격증명을 발급하는 설계를 다룬다. 먼저 공격 표면이 모델의 답변에서 에이전트의 신원과 위임된 권한으로 옮겨 가는 흐름을 짚고, 사람과 에이전트의 신원을 분리해야 하는 이유를 정리한다. 이어서 워크로드 신원을 발급하는 SPIFFE와 SPIRE의 동작, 사람의 토큰을 에이전트용 제한 토큰으로 바꾸는 OAuth 토큰 교환(RFC 8693)과 RAR(RFC 9396)의 동작을 차례로 설명하고, 마지막으로 동적 도구 선택과 위임 체인의 철회와 감사에 남은 과제를 짚는다.

모델의 답변에서 에이전트의 신원과 권한으로 옮겨 간 공격 표면

에이전트 보안의 공격 표면은 모델이 무엇을 말하는가에서 에이전트가 누구의 자격으로 무엇을 할 수 있는가로 옮겨 가고 있다. 에이전트가 메일을 보내고 결제를 요청하고 사내 데이터를 조회하려면 대상 시스템에 인증하고 인가를 받아야 하며, 이때 쓰는 자격증명이 곧 침해된 에이전트가 행사할 수 있는 권한의 상한이 된다. 이 이동을 개별 침해 사례로 입증하려 하면 사례마다 제품의 구성과 공개된 정보의 범위가 달라 원인을 일반화하기 어렵고 사실관계의 확인도 제한된다. 그래서 이 글은 개별 사례 대신 여러 사례에 공통된 구조를 항목으로 정리한 위험 분류와 표준 문서를 따라 흐름을 짚는다. 먼저 OWASP Top 10 for Agentic Applications 2026은 목표 탈취와 도구 오용과 별도로 신원과 권한의 남용(ASI03 Identity and Privilege Abuse)을 독립된 위험 항목으로 두었다. 이어서 OpenID 재단의 AI 신원 관리 커뮤니티 그룹이 2025년 10월에 낸 보고서 Identity Management for Agentic AI는 현재의 배포에서 에이전트가 외부 서비스가 알아볼 수 없는 방식으로 사용자를 가장(impersonation)하는 경우가 많고, 그 결과 에이전트의 API 호출이 사용자가 직접 한 행위와 구분되지 않은 채 로그에 남는다고 지적한다. 토큰이 탈취되든 도구가 오용되든 피해는 결국 그 자격증명을 거쳐 일어나므로 방어의 초점도 모델의 출력에서 자격증명의 주체와 범위로 이동한다.

위험 분류와 현황 진단에 이어 표준화 작업도 같은 방향으로 움직이고 있다. IETF WIMSE 작업 그룹의 아키텍처 초안(Workload Identity in a Multi System Environment Architecture)은 AI와 ML 중개자를 위임된 워크로드의 특수한 경우로 보고 별도의 절에서 다룬다. 이 초안은 에이전트가 상위의 맥락을 전파하고, 자율적 행위와 위임받은 행위를 구분하며, 다중 에이전트 위임 체인의 각 홉에서 범위를 명시적으로 다시 정해야 한다고 기술한다. OAuth 작업 그룹의 도메인 간 신원⁠·⁠인가 체이닝(identity and authorization chaining) 초안은 RFC 발간 절차가 진행 중이다. 즉 에이전트의 신원과 위임은 개별 구현의 관례가 아니라 워크로드 신원과 OAuth라는 기존 표준의 연장선에서 정리되는 중이다. 도구 호출을 실행 직전에 판정하는 구조는 "가드레일에서 실행 경계로 — 에이전트의 도구 호출을 통제하는 정책 집행 구조"에서 다뤘고, 이 글은 그 판정의 입력이 되는 주체와 권한이 어떻게 만들어지는지를 다룬다.

사람과 에이전트의 신원 분리 원칙

이 흐름에서 설계자가 취해야 할 원칙은 사람의 신원과 에이전트의 신원을 분리하고 둘을 잇는 위임을 별도의 자격증명으로 표현하는 것이다. RFC 8693은 이 차이를 가장과 위임(delegation)이라는 두 의미론으로 구분한다. 가장에서 행위자는 주체의 권한을 넘겨받아 받는 쪽에서 주체와 구별되지 않는다. 반면 위임에서 행위자는 자신의 신원을 유지한 채 주체를 대리하고, 발급된 토큰에는 두 당사자의 정보가 함께 담긴다. 사람의 토큰이나 API 키를 에이전트가 그대로 쓰는 방식은 가장에 해당한다. 그래서 감사 로그는 행위의 주체를 사람으로만 기록하고, 문제가 생긴 에이전트 하나의 권한을 철회하려 해도 철회의 단위가 사람의 자격증명이어서 사람의 다른 접근까지 함께 끊긴다. 에이전트가 과제에 필요한 범위가 아니라 사람이 가진 범위 전체를 행사하므로 최소 권한(least privilege)도 성립하지 않는다.

따라서 에이전트에는 두 가지를 따로 발급해야 한다. 하나는 에이전트라는 워크로드 자체를 가리키는 신원으로, 어느 에이전트가 호출했는지를 암호학적으로 증명한다. 다른 하나는 특정 사용자를 대리해 특정 자원에 특정 행위를 할 수 있다는 위임 자격증명으로, 범위와 대상(audience)과 유효기간이 과제에 맞게 제한된다. 이 분리가 있어야 감사 로그에 "사용자 U를 대리한 에이전트 A"가 남고, 철회도 사용자 전체가 아니라 에이전트 A의 위임만을 대상으로 할 수 있다. **Authenticated Delegation and Authorized AI Agents(2025)**가 OAuth 2.0과 OpenID Connect를 에이전트 전용 자격증명과 메타데이터로 확장하자고 제안하고 Identity Management for Agentic AI가 명시적인 대리(on-behalf-of) 위임을 권고하는 것도 같은 원칙에서 나온다. 이 원칙을 구현하는 데 새 프로토콜이 필요한 것은 아니다. 워크로드 신원에는 SPIFFE가, 범위가 제한된 위임에는 OAuth 토큰 교환과 RAR이 이미 표준으로 있다.

워크로드 신원의 발급과 검증: SPIFFE와 SPIRE

SPIFFE(Secure Production Identity Framework for Everyone)는 워크로드에 서비스 신원을 부여하는 규격이고 SPIRE는 그 구현체다. 신원은 spiffe:// 스킴, 신뢰 도메인(trust domain), 경로로 이루어진 URI인 SPIFFE ID로 표현된다. 예를 들어 spiffe://example.org/agent/travel-booking은 example.org 신뢰 도메인의 여행 예약 에이전트를 가리킨다. 이 ID를 서명과 함께 담아 상대에게 제시하는 문서가 SVID(SPIFFE Verifiable Identity Document)이고, SVID는 그 신뢰 도메인의 서명 기관이 서명했을 때만 유효하다. X.509-SVID는 SPIFFE ID를 인증서의 URI SAN에 담는데, URI SAN은 정확히 하나여야 하고 cA 플래그는 거짓이어야 한다. 그래서 검증자는 인증서 하나에서 신원 하나를 모호함 없이 읽고, 그 인증서로 다른 인증서를 서명할 수 없음을 확인한다. JWT-SVID는 audience를 지정해 받는 단기 토큰이고, 받는 쪽은 신뢰 번들(trust bundle)의 JWK Set으로 서명을 검증한다.

SPIRE가 에이전트 프로세스에 SVID를 발급하는 순서는 다음과 같다. 먼저 운영자가 SPIRE Server에 등록 항목(registration entry)을 만든다. 등록 항목은 SPIFFE ID와 워크로드가 갖춰야 할 셀렉터(selector), 예컨대 Kubernetes 네임스페이스와 서비스 어카운트, 유닉스 사용자 ID를 짝지은 것이다. 다음으로 각 노드의 SPIRE Agent가 클라우드 인스턴스 신원 문서 같은 증거를 제시하는 노드 증명(node attestation)을 거쳐 자신의 SVID를 받고, 그 SVID로 자신에게 허가된 등록 항목을 내려받는다. 에이전트 프로세스는 유닉스 도메인 소켓으로 노출된 Workload API를 호출하는데, 이때 워크로드는 아무 자격증명도 제시하지 않는다. Workload API 규격이 클라이언트의 직접 인증을 두지 않고 대역 외(out-of-band) 확인에 기대도록 정하기 때문이다. SPIRE Agent는 호출한 프로세스의 PID를 확인하고, 워크로드 증명자(workload attestor)가 커널이나 kubelet에 질의해 얻은 셀렉터를 등록 항목과 대조해 신원을 결정한 뒤 X.509-SVID와 개인 키, 신뢰 번들을 돌려준다. 즉 에이전트의 코드나 프롬프트에는 처음부터 비밀이 없고 신원은 실행 환경의 속성에서 도출된다.

철회의 성격은 발급 이후의 수명주기가 결정한다. SPIRE Server의 기본 TTL은 X.509-SVID가 1시간, JWT-SVID가 5분이다. Workload API는 스트림으로 동작하며 SVID가 교체될 때마다 전체 상태를 다시 보내고, 응답에서 빠진 항목은 클라이언트가 폐기해야 한다. 그래서 등록 항목을 지우면 그 신원은 더 이상 발급되거나 갱신되지 않고, 차단(ban)된 노드는 다시 증명하지 못한다. 반면 X.509-SVID 규격은 CRL이나 OCSP 같은 인증서 폐기 절차를 정하지 않으므로 이미 발급된 SVID는 서명이 유효한 동안 검증을 통과할 수 있다. 결국 SPIFFE에서 신원의 철회는 짧은 TTL과 갱신 중단으로 구현되며, 철회가 효력을 갖기까지의 지연은 TTL의 길이에 묶인다. 또한 SPIFFE가 증명하는 것은 어떤 워크로드가 호출했는가까지다. 그 워크로드가 어느 사용자를 대리하고 어떤 범위의 권한을 받았는지는 SVID에 담기지 않으며, 그 부분은 위임 토큰이 맡는다.

범위 제한 위임: OAuth 토큰 교환과 RAR

RFC 8693 OAuth 2.0 Token Exchange는 이미 가진 토큰을 인가 서버의 토큰 엔드포인트에 제시하고 다른 토큰을 받는 절차를 정의한다. 요청의 grant_type은 urn:ietf:params:oauth:grant-type:token-exchange이고, 대리받는 당사자를 나타내는 subject_token, 실제로 행위하는 당사자를 나타내는 actor_token, 토큰을 쓸 대상을 가리키는 resource나 audience, 요청하는 scope를 함께 보낸다. 앞의 예에 옮기면 여행 예약 에이전트는 사용자의 액세스 토큰을 subject_token으로, Workload API에서 받은 JWT-SVID를 actor_token으로 제시하고 예약 API를 audience로 지정한다. 인가 서버는 사용자 토큰의 may_act 클레임으로 이 에이전트가 이 사용자를 대리할 자격이 있는지 판정할 수 있고, 통과하면 sub에 사용자를, act 클레임에 에이전트의 SPIFFE ID를 담은 새 토큰을 짧은 expires_in과 함께 발급한다. 에이전트가 하위 에이전트에 일을 넘기면 같은 교환을 다시 거치며 act 클레임이 중첩되는데, 가장 바깥의 act가 현재 행위자이고 가장 깊이 중첩된 act가 가장 먼저 행위한 당사자다.

scope 문자열만으로는 "예약 생성"은 표현할 수 있어도 "특정 일정의 특정 금액 이하 예약 생성"은 표현하기 어렵다. RFC 9396 Rich Authorization Requests는 이를 authorization_details라는 JSON 배열로 표현한다. 배열의 각 객체는 필수 필드인 type과 공통 필드인 locations, actions, datatypes, identifier, privileges로 구성되고 금액이나 수취인 같은 API 고유 필드를 더할 수 있다. 한 객체 안에서 요청된 권한은 나열된 값들의 곱이므로 더 세밀하게 제한하려면 객체를 나눈다. 클라이언트는 이 파라미터를 토큰 요청에도 실을 수 있고, 인가 서버는 원래의 그랜트가 그 요청을 허용하는지 확인한 뒤 실제로 허가한 authorization_details를 토큰 응답에 돌려준다. 리소스 서버는 JWT 액세스 토큰이나 토큰 인트로스펙션 응답에서 같은 구조를 읽는다. 따라서 에이전트용 토큰에 과제 하나에 맞춘 자원과 행위 단위의 권한을 담을 수 있다.

여기서 주의할 점은 권한의 축소가 프로토콜이 보장하는 성질이 아니라 인가 서버의 정책이라는 것이다. RFC 8693은 어떤 교환을 허용할지에 대한 요구를 두지 않고, 발급되는 토큰이 subject_token보다 좁아야 한다고 요구하지도 않는다. 보안 고려 사항에서 남용을 줄이는 수단으로 scope와 제한된 토큰 수명을 권할 뿐이다. 축소를 규범으로 명시한 것은 도메인 간 체이닝 초안으로, 인가 서버가 요청된 scope가 제시된 subject_token의 scope보다 높은 권한이 아닌지 검증해야 한다고 정한다. RAR에서는 이 판정이 더 복잡하다. RFC 9396은 두 authorization_details를 비교하는 일반적인 방법을 정의하지 않으며 단순한 객체 동일성 비교에 기대지 말라고 명시한다. 쓰기가 읽기를 함의하는 경우처럼 필드 사이의 관계가 API마다 다르기 때문이다. 즉 위임 체인의 각 홉에서 권한이 단조롭게 줄어든다는 보장은 인가 서버가 type마다 "이 요청이 원래 권한의 부분집합인가"를 판정하는 로직을 구현했을 때만 성립한다. 표준이 제공하는 것은 축소를 표현하는 어휘이며, 축소를 강제하는 일은 배포 환경의 책임이다.

같은 문제를 OAuth를 확장하지 않고 다시 설계한 프로토콜로 RFC 9635 GNAP(Grant Negotiation and Authorization Protocol)이 있다. GNAP에서 클라이언트 인스턴스는 사전 등록 대신 자신의 키로 식별되고 그 키로 요청에 서명하며, 권한은 RAR과 같은 type, actions, locations, datatypes 구조의 access 배열로 요청한다. 발급된 토큰은 bearer 플래그를 명시하지 않는 한 클라이언트의 키에 바인딩되고, 클라이언트는 토큰 관리 URI로 토큰을 교체하거나 폐기할 수 있다. 에이전트마다 고유한 키를 두고 탈취된 토큰의 재사용을 막는다는 점에서 이 글의 원칙과 맞닿아 있지만, 규격 스스로 OAuth 2.0과 직접 호환되지 않는다고 밝히므로 기존 인가 서버를 그대로 쓰는 배포에는 적용하기 어렵다.

동적 도구 선택과 위임 체인 감사의 한계

신원과 위임을 분리하는 구조를 실제 에이전트에 적용할 때 아직 해법이 정립되지 않은 문제는 다음과 같다.

첫째, 동적 도구 선택과 최소 권한의 충돌이다. 범위 제한 위임은 과제에 필요한 권한을 미리 알 수 있다고 전제하지만 LLM 에이전트는 실행 시점에 사용자의 의도에 따라 새 도구와 서비스를 찾아 연결한다. 어떤 도구를 쓸지 실행 전에 알 수 없는 에이전트에 권한을 미리 부여하려면 쓰일 수 있는 도구를 모두 포함하는 넓은 범위를 줄 수밖에 없고, 이는 최소 권한과 정면으로 어긋난다. 범위를 넓게 주면 최소 권한이 무너지고 좁게 주면 과제가 중단되므로, 도구를 고를 때마다 토큰 교환으로 그 호출에 맞는 토큰을 받는 방식이 대안이 된다. 그러나 그만큼 인가 서버와의 왕복이 늘고, 사람의 승인을 거치는 위임이라면 승인 요청이 잦아져 사용자가 내용을 확인하지 않고 승인하는 동의 피로(consent fatigue)가 커진다.

둘째, 위임 체인의 철회다. 토큰 교환으로 발급된 토큰은 원래의 subject_token과 별개의 새 토큰이고, RFC 8693은 두 토큰의 철회를 연동하는 절차를 정하지 않는다. 리소스 서버가 JWT의 서명과 만료만으로 토큰을 검증한다면 상위의 위임이 철회되었다는 사실을 알 수 없다. 따라서 사용자가 상위 에이전트의 위임을 철회해도 그 토큰으로 교환해 둔 하위 에이전트의 토큰은 만료될 때까지 유효할 수 있고, 체인 아래로 철회를 즉시 전파하는 표준 메커니즘은 아직 없다. 실행 횟수 제약으로 피해를 한정하거나 보안 이벤트를 공유하는 신호 체계로 보완하는 방향이 제시되지만 부분적인 해법에 그친다. 결국 SPIFFE의 짧은 TTL과 마찬가지로 현실적인 철회 수단은 여전히 짧은 유효기간이며, 철회를 더 빨리 반영하려면 하위 토큰의 수명을 짧게 잡거나 리소스 서버가 토큰 인트로스펙션으로 활성 여부를 매번 확인하게 해야 한다.

셋째, 위임 체인의 감사다. RFC 8693은 중첩된 act 클레임의 이전 행위자를 정보 제공용으로만 규정하고, 접근 제어 판정에는 최상위 클레임과 현재 행위자만 쓰라고 한다. 따라서 리소스 서버는 체인 전체를 근거로 판정하지 못하고, 체인 정보도 각 인가 서버가 빠짐없이 전달했을 때만 감사에 쓸 수 있다. WIMSE 아키텍처 초안이 각 홉에서 범위를 명시하고 맥락을 다시 바인딩하라고 요구하는 것은 이 공백을 메우려는 방향이지만 그 요구 자체가 아직 초안에 머물러 있다.

넷째, 신뢰 도메인을 넘는 신원이다. SPIFFE ID는 그 신뢰 도메인의 인프라를 알고 통제하는 쪽에서만 의미가 있으므로 이 모델은 조직의 경계를 넘어 그대로 옮겨지지 않는다. 도메인 간 체이닝 초안은 도메인 A의 인가 서버에서 토큰 교환으로 JWT 인가 그랜트를 받아 도메인 B의 인가 서버에 JWT 어서션 그랜트로 제시하는 흐름을 정의하지만, 옮겨 담는 클레임의 형식은 정하지 않아 양쪽이 의미를 따로 맞춰야 한다. 중앙 레지스트리 없이 검증할 수 있는 식별자를 정의한 W3C의 Decentralized Identifiers(DIDs) v1.0과 발급자, 보유자, 검증자의 역할과 유효기간을 정의한 Verifiable Credentials Data Model v2.0이 이식 가능한 에이전트 신원과 위임 증명의 후보로 거론되지만, 에이전트 신원과 위임을 조직 사이에서 상호운용 가능하게 표현하는 프로파일은 아직 표준화되지 않았다.

정리 및 요약

에이전트가 실제 행위를 맡으면서 공격 표면은 모델의 답변에서 에이전트가 지닌 신원과 위임된 권한으로 옮겨 갔다. 사람의 자격증명을 그대로 쓰는 가장 방식은 감사 로그에서 사람과 에이전트를 구분하지 못하게 하고 에이전트만의 철회를 불가능하게 하므로, 에이전트에는 워크로드 신원과 위임 자격증명을 따로 발급해야 한다. SPIFFE와 SPIRE는 실행 환경의 속성을 증명해 짧은 수명의 SVID를 발급하고, RFC 8693 토큰 교환은 사용자와 에이전트를 sub와 act로 함께 담은 토큰을 만들며, RFC 9396 RAR은 그 토큰의 권한을 자원과 행위 단위로 표현한다. 단일 신뢰 도메인 안에서 동기적으로 동작하는 에이전트라면 이 조합으로 충분히 구현할 수 있다. 반면 실행 시점에 도구를 고르는 에이전트의 최소 권한, 위임 체인의 철회 전파와 감사, 도메인을 넘는 신원은 아직 표준이 답하지 못한 영역이다.

결국 에이전트의 비인간 신원은 새 인증 기술을 고르는 문제가 아니라 누가 누구를 대리해 무엇을 언제까지 할 수 있는지를 토큰마다 명시하고, 위임의 각 단계에서 그 범위가 넓어지지 않도록 인가 서버가 판정하게 만드는 위임 설계의 문제다.

참고 자료

← Blog