AI 에이전트의 대리 호출, 토큰은 어디까지 넘겨야 할까

Larry

사내 AI 에이전트에게 고객 정보를 찾아 티켓 시스템에 기록해 달라고 요청했다고 하자. 첫 API에서는 사용자를 확인할 수 있지만, 고객 데이터베이스를 조회하고 티켓 API에 결과를 쓰는 동안 각 시스템에는 누구의 신원이 남아야 할까?

구현을 서두르면 모든 호출을 공용 서비스 계정으로 처리하거나, 사용자가 처음 제출한 토큰을 뒤쪽 시스템까지 그대로 넘기기 쉽다. 전자는 어느 사용자의 권한으로 실행했는지 감추고, 후자는 첫 API용 자격 증명을 다른 수신 대상에게 노출할 수 있다. 호출이 다음 시스템으로 넘어갈 때마다 신원과 권한을 다시 제한해야 하는 이유다.

AWS가 2026년 7월 공개한 Amazon Bedrock AgentCore Gateway의 멀티테넌트 구현 사례도 사용자를 대신하는 토큰을 교환하고 audience binding으로 수신 API를 제한한다. 특정 제품의 구현이지만 판단 기준은 다른 환경에도 적용할 수 있다. 호출 단계마다 다음 네 가지가 분명해야 한다.

누구를 대신하는가
실제로 누가 실행하는가
어느 서비스에 전달할 수 있는가
어떤 작업까지 허용하는가

사용자 신원과 에이전트 신원은 함께 남겨야 한다

OBO(on-behalf-of) 흐름에서는 중개 서비스가 사용자 토큰을 받은 뒤 권한 부여 서버에 다운스트림용 새 토큰을 요청한다. 새 토큰은 지정된 API에서만 사용할 수 있어야 하며, 허용 범위는 사용자의 기존 권한과 시스템 정책이 함께 허용하는 수준을 넘으면 안 된다.

클라이언트 인증을 요구하는 구현이라면 에이전트는 자신의 서비스 신원으로 토큰 교환 엔드포인트에서 인증하고, 위임 정보에는 대신하는 사용자도 남겨야 한다. RFC 8693은 이를 subject와 actor로 구분한다. subject는 작업이 대신하는 주체, actor는 실제로 실행하거나 다음 단계로 전달하는 주체다. 실제 토큰의 act claim 지원 여부와 관계없이 감사 데이터에서는 두 역할을 복원할 수 있어야 한다.

에이전트에 아직 독립된 신원을 부여하지 않았다면 ERP의 AI 에이전트에는 왜 고유한 신원이 필요한가?를 먼저 확인하자. 서비스 신원은 에이전트를 식별하는 장치이지 사용자 맥락을 지우는 대체 신원이 아니다.

호출 경로를 그릴 때 확인할 다섯 단계

사용자 → 에이전트 → API만 그려서는 토큰의 검증과 교환 지점을 알 수 없다. 토큰을 받는 지점과 새 토큰을 발급받는 지점을 나눠 표시하고 다음 순서로 점검한다.

진입 토큰이 이 API를 대상으로 발급됐는지 확인한다. 진입 API는 발급자, 만료 시간, audience를 검증한다. 서명이 유효해도 audience가 다른 서비스라면 거부해야 한다.
사용자와 실행자를 별도 필드로 남긴다. 사용자는 subject, 다운스트림 요청을 보내는 에이전트는 actor로 기록한다. 로그에 공용 서비스 계정만 보인다면 위임 관계가 그 구간에서 끊긴 것이다.
교환할 토큰의 대상을 하나의 다운스트림 리소스로 좁힌다. 요청에 다음 API의 resource 또는 audience를 명시하고, 발급 후에도 정확히 일치하는지 검증한다. ‘내부 서비스’가 아니라 ‘티켓 API’처럼 실제 수신 대상을 지정해야 한다.
scope를 이번 작업에 필요한 수준으로 줄인다. 고객 정보 조회에 삭제나 전체 데이터베이스 내보내기 권한을 포함해서는 안 된다. 발급 scope는 사용자의 기존 권한, 에이전트 허용 범위, 다운스트림 정책이 모두 허용하는 범위 안에 있어야 한다.
허용과 거부의 근거를 추적할 데이터를 남긴다. 교환 시각, subject, actor, 대상 audience, 요청 scope, 발급 scope, 거부 사유를 기록하되 전체 토큰 자체는 로그에 저장하지 않는다. 이 정보로 권한 부여자, 실행 에이전트, 수신 서비스와 판단 근거를 설명할 수 있어야 한다.

다운스트림 시스템이 늘어날 때마다 토큰 교환과 audience 검증을 다시 거쳐야 한다. 고객 정보 API용 토큰을 티켓 API에 재사용해서는 안 된다. Microsoft의 OBO 문서도 중개 서비스가 다운스트림 웹 API용 새 토큰을 받는 원칙을 따른다.

권한 부여 판단을 프롬프트에만 맡겨서도 안 된다. AI 에이전트 승인 전 4문항: 신원, 권한, 이유, 결과에서는 모델의 자체 판단이 아니라 백엔드에서 강제해야 할 검사를 다룬다.

작업 유형에 따라 호출의 출구를 다르게 정한다

모든 작업에 OBO를 적용하거나 모든 호출을 서비스 계정으로 통일할 수는 없다. 다음 네 가지 상황을 구분한다.

특정 사용자를 대신하고 권한 부여 시스템과 다운스트림 API가 위임을 지원한다면: 토큰 교환으로 subject와 actor를 유지하고, 서비스마다 audience가 다른 토큰을 발급한다.
공개 데이터를 일정에 따라 정리하는 등 특정 사용자를 대신하지 않는다면: 에이전트의 워크로드 신원을 사용하고 백그라운드 작업에 필요한 권한만 부여한다. OBO를 위해 가상의 사용자를 만들지 않는다.
사용자를 대신하지만 다운스트림이 OBO를 지원하지 않거나 위임 관계를 검증할 수 없다면: 진입 토큰을 넘기지 않는다. 자동 호출을 멈추고, 통제되는 백엔드가 제한적인 작업 인터페이스를 제공하게 하거나 다운스트림 단계에서 사람이 직접 확인한다.
대상 audience를 증명할 수 없거나 scope가 현재 작업에 필요한 범위보다 크다면: 토큰 교환이나 API 호출을 즉시 거부한다. audience와 scope는 에이전트가 추측할 값이 아니다.

먼저 작업이 특정 사용자를 대신하는지 확인하고, 전체 호출 체인에서 위임 관계를 검증할 수 있는지 살핀다. 한 구간이라도 공용 계정으로 사용자 신원을 가리거나 자기에게 속하지 않은 토큰을 받게 한다면 영향이 큰 작업을 자동 실행해서는 안 된다.

위임 검증을 통과해도 영향이 큰 작업에는 사람의 승인이 필요하다. 데이터 또는 시스템 소유자가 subject, actor, 대상 API, scope, 예상 영향과 rollback 방법을 확인해야 한다. 정책에 따른 자동 실행은 결과를 되돌릴 수 있는 저영향 조회 작업으로 제한한다.

오늘은 가장 자주 쓰는 호출 경로 하나만 점검하자

여러 시스템에서 작업하는 에이전트 하나를 고르고 가장 자주 사용하는 호출 경로를 다음 형식으로 기록하자.

사용자 subject → 실행자 actor → 토큰 발급자 → 대상 audience/resource → 발급 scope → 거부 조건

그다음 두 가지만 먼저 찾는다.

공용 서비스 계정만 남아 사용자를 추적할 수 없는 구간이 있는가?
audience가 다른 두 서비스가 같은 토큰을 받아들이는가?

하나라도 해당한다면 새 자동화 기능을 추가하기 전에 그 구간의 신원 전달 방식과 권한부터 좁혀야 한다.

AI 정리 카드

먼저 각 홉의 subject와 actor를 기준으로 호출 흐름을 복원한다. 공유 서비스 계정이 사용된 지점과 원본 토큰이 전달된 위치도 함께 표시한다. 누락된 권한이나 값은 추측하지 말고 모두 '확인 필요'로 남긴다.

그다음 진입 토큰의 발급자, audience, 만료 시각과 토큰 교환 대상의 resource와 audience, 교환 엔드포인트, scope와 권한 경계, 거부 로그의 거부 코드와 사유를 근거로 각 홉의 위험을 판정한다. 위험 상태는 '확인됨', '확인 필요', '차단' 중 하나만 사용하며, 결과는 홉별 기록만 출력한다.

분석할 호출 체인: [여기에 붙여 넣기]