행사 글을 쓰다 보니 같은 질문이 계속 나왔습니다. Agent 365와 Entra Agent ID는 "어떤 에이전트가 어떤 사용자를 대신해 무엇을 건드리는지"를 보여 주겠다고 했습니다. Next 26의 Agent Identity는 에이전트마다 고유한 신원을 주겠다고 했습니다.
둘 다 "대신한다"는 말을 씁니다. 그런데 대신한다는 게 토큰 수준에서 정확히 무슨 뜻일까요. 이 문제를 표준으로 다룬 문서가 OAuth 2.0 토큰 교환, RFC 8693입니다.
문제: 서비스 계정 하나로는 누가 했는지 모른다
에이전트가 사용자 대신 메일을 보낸다고 해 봅시다. 가장 쉬운 방법은 에이전트에 넓은 권한의 서비스 계정을 주는 것입니다.
그러면 감사 로그에는 서비스 계정만 남습니다. 어느 사용자의 요청이었는지 알 수 없습니다. 반대로 사용자의 토큰을 그대로 넘기면, 이번에는 에이전트가 끼어 있었다는 사실이 사라집니다.
두 정보가 다 필요합니다. 누구를 위해서, 그리고 누가 실제로 했는지.
토큰 교환이 하는 일
RFC 8693은 HTTP와 JSON으로 동작하는 보안 토큰 서비스(STS) 프로토콜을 정의합니다. 클라이언트가 가진 토큰을 인가 서버의 토큰 엔드포인트에 내고, 다른 서비스에 쓸 새 토큰을 받아 옵니다.
요청은 이런 모양입니다.
POST /token
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<사용자 토큰>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=<에이전트 토큰>
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=mail-api
&scope=mail.send
subject_token(필수): 누구를 위해 요청하는지 나타냅니다.actor_token(선택): 실제로 행동하는 쪽이 누구인지 나타냅니다.audience,resource: 새 토큰을 쓸 대상 서비스입니다.scope: 대상 서비스에서 필요한 권한만 좁혀 요청합니다.
가장과 위임은 다르다
RFC는 두 방식을 구분합니다. 이 구분이 이 글의 핵심입니다.
가장(impersonation). 행위자가 사용자의 권한을 받아 사용자로 보입니다. 받는 쪽은 사용자만 봅니다. 에이전트가 끼어 있었다는 흔적이 토큰에 없습니다.
위임(delegation). 행위자는 자기 신원을 유지한 채 사용자를 대신합니다. 받는 쪽은 "에이전트 A가 사용자 B를 대신해 한 일"로 압니다.
에이전트 거버넌스 발표들이 원하는 건 위임 쪽입니다. 사고가 나면 어떤 에이전트였는지 알아야 하니까요.
act 클레임: 누가 대신했는지 남기기
위임은 JWT의 act(actor) 클레임으로 표현됩니다. RFC는 이 클레임이 "위임이 일어났음을 나타내고 행위자를 식별한다"고 설명합니다.
에이전트가 다른 에이전트를 부르면 act가 중첩됩니다. 이때 규칙이 하나 있습니다. 가장 바깥의 act가 현재 행위자입니다. 안쪽의 이전 행위자들은 참고용이고, 접근 허용 여부를 판단하는 데 쓰지 말라고 합니다.
권한 판단은 "지금 누가 하고 있나"로만 하라는 뜻입니다. 체인 전체를 믿으면 중간 어딘가에서 끼어든 행위자까지 믿게 됩니다.
may_act: 누가 대신해도 되는지 미리 적기
may_act 클레임은 반대 방향입니다. 사용자의 토큰에 "이 행위자는 나를 대신해도 된다"고 미리 적어 둡니다. 인가 서버는 교환 요청이 왔을 때 이 값을 보고 허용할지 정할 수 있습니다.
에이전트 등록 화면에서 "이 에이전트에 권한 위임"을 누르는 동작이, 토큰 수준에서는 이런 형태로 남는다고 보면 이해가 쉽습니다.
범위는 좁게
audience나 resource와 scope를 함께 쓰면, 요청한 권한은 대상 서비스마다 모든 scope를 곱한 조합이 됩니다. RFC는 대상을 여러 개 섞은 요청을 인가 서버가 invalid_target으로 거절할 수 있다고 적어 둡니다.
실무로 옮기면 간단합니다. 에이전트가 도구를 부를 때마다 그 도구 하나, 그 작업 하나에 맞는 토큰을 따로 받습니다. 만능 토큰 하나를 들고 다니게 하지 않습니다.
행사 발표와 이어 보면
벤더마다 이름은 다르지만, 발표들이 풀려는 문제는 이 RFC가 나눈 구분과 겹칩니다.
- 에이전트에게 고유 신원을 준다 →
actor_token이 가리킬 대상이 생긴다 - 누구를 대신했는지 기록한다 → 위임과
act - 도구 호출마다 권한을 좁힌다 →
audience·scope로 줄인 토큰
각 제품이 내부에서 실제로 RFC 8693을 쓰는지는 발표에 나오지 않았습니다. 그래서 이 글은 개념을 맞춰 보는 데까지만 씁니다. 제품을 고를 때는 감사 로그에 사용자와 에이전트가 둘 다 남는지부터 확인해 보면 좋겠습니다.
