한 영업 담당자가 AI agent에게 부탁한다. “이 고객의 최근 주문을 찾아보고, 결과로 고객지원 티켓을 하나 열어 줘.” 사람에게는 분명한 말이지만, 뒤에 있는 시스템에게는 몇 가지 중요한 정보가 빠져 있다. 누가 이 일을 승인했는지, 실제로 어떤 agent가 하고 있는지, 어디까지 해도 되는지.
이 일을 끝내려면 agent는 고객 데이터베이스와 티켓 시스템, 적어도 두 시스템을 거쳐야 한다. 시스템마다 token을 내밀어야 하는데, token은 “이 일을 할 권한이 있다"는 것을 증명하는 전자 통행증이다. 이때 팀이 흔히 택하는 지름길은 두 가지다. agent가 모두 함께 쓰는 서비스 계정으로 일하게 하거나, 사용자가 로그인할 때 받은 token을 그대로 아래쪽으로 계속 넘기는 것이다. 두 지름길 모두 일은 돌아가게 하지만, 문제가 생겼을 때 누가 무엇을 승인했는지 알 수 없게 만든다.
더 안정적인 방법은 이렇다. agent가 다음 시스템으로 넘어갈 때마다, 그 시스템에서만 쓸 수 있고 이번 작업에 필요한 권한만 담긴 새 token으로 바꾼다.
두 지름길 각각의 문제
공용 서비스 계정을 쓰면 사용자가 사라진다. 모든 작업이 agent 계정 하나에 묶이면 고객 데이터베이스의 기록에는 “agent가 이 데이터를 조회했다"만 남는다. 어느 영업 담당자가 요청했는가. 그 사람은 원래 이 고객을 볼 권한이 있었는가. 기록에는 아무것도 없다. agent 계정은 보통 어떤 개별 사용자보다 권한이 넓어서, 누구나 agent를 통해 원래 볼 수 없던 것을 보게 된다.
token을 계속 넘기면 받는 사람이 틀린다. 모든 token에는 발급될 때 어느 시스템용인지가 적혀 있다. 이 항목을 audience(지정된 수신처)라고 한다. 사용자가 로그인할 때 받는 token의 audience는 첫 번째 시스템이다. agent가 그것을 티켓 시스템에 그대로 넘기면, 남의 이름이 적힌 출입증으로 문을 통과하는 것과 같다. AWS는 2026년 7월 기술 글에서 이렇게 하면 아래쪽의 모든 도구가 악용될 수 있는 대리인이 될 수 있다고 지적했다. 그 도구들이 받는 token이 애초에 자신에게 발급된 것이 아니기 때문이다. Microsoft도 이런 흐름을 설명하는 문서의 경고 상자에, 중간 서비스에 발급된 token을 지정된 수신처 이외의 곳으로 보내지 말라고 적어 두었다.
들르는 곳마다 열쇠를 바꾼다: 사용자를 대신한 교환
이렇게 “사용자를 대신해 다음 시스템에서 일을 보는” 흐름을 보통 on-behalf-of, 줄여서 OBO라고 부른다. 핵심 동작은 교환이다. agent는 사용자의 token을 들고 인가 서버(token을 발급하는 시스템)에 가서 새 token을 신청한다. 새 token은 지정된 다음 시스템에서만 쓸 수 있고, 권한도 사용자가 원래 허락받은 범위를 넘을 수 없다.
새 token은 두 역할을 기억해야 한다. 이 교환을 규정한 인터넷 표준 RFC 8693은 둘을 나눈다. subject는 대리되는 사람으로, 이 예에서는 영업 담당자다. actor는 실제로 일하는 쪽, 즉 agent다. AWS 글의 구현에서는 아래쪽 도구를 호출하기 전에 매번 token을 교환해서, 새 token이 사용자의 신원을 유지하고, 실행한 agent를 기록하고, 받는 시스템을 하나로 묶고, 권한도 아래쪽에 필요한 만큼만 갖도록 한다.
이렇게 하면 고객 데이터베이스의 기록은 “agent가 특정 영업 담당자를 대신해 읽기 전용 권한으로 이 데이터를 조회했다"가 된다. 아래쪽 시스템이 하나 늘 때마다 한 번 더 교환한다. 고객 데이터베이스용 token을 이어서 티켓 생성에 쓸 수는 없다.
먼저 일의 성격을 가려낸다
모든 agent 작업이 OBO를 써야 하는 것은 아니다. 넘겨주기 경로를 그리기 전에 이 일이 어떤 종류인지 판단한다.
- 특정 사용자를 정말 대리하고, 인가 체계와 아래쪽 시스템이 모두 교환을 지원한다: OBO를 쓰고, 단계마다 새 token으로 바꾸고, subject와 actor를 남긴다.
- 어떤 사용자도 대리하지 않는다. 예를 들어 매일 정해진 시간에 공개 데이터를 정리하는 예약 작업: agent 자신의 신원을 쓰고, 권한은 그 뒷단 작업에만 한정한다. OBO에 끼워 맞추려고 사용자를 지어내서는 안 된다.
- 사용자를 대리하지만 아래쪽 시스템이 교환을 지원하지 않는다: 원래 token을 넘기지 않는다. 중간 층에서 멈추고, 권한을 더 좁힌 백엔드 기능이 대신 처리하게 하거나, 사람이 아래쪽 시스템에서 확인하게 한다.
- 새 token이 어느 시스템용인지 말할 수 없거나, 이번 동작에 필요한 것보다 큰 권한을 요구한다: 바로 거부한다. 이 항목들은 agent가 추측하게 둬서는 안 된다.
교환이 됐다고 그 일을 해도 되는 것은 아니다
token 교환이 성공했다는 것은 “이 agent가 이 사용자를 대리해 이 시스템에 가도 된다"는 뜻일 뿐, 이번에 하려는 일이 옳다는 뜻은 아니다. 주문 조회는 미리 승인한 규칙에 따라 자동으로 통과시켜도 되지만, 데이터 삭제, 환불, 권한 변경 같은 영향 큰 쓰기 작업은 교환에 성공했더라도 실행 전에 담당자가 누가 승인했는지, 무엇을 하는지, 영향이 얼마나 큰지, 어떻게 되돌리는지를 확인해야 한다. 권한 확인을 agent의 프롬프트에만 적어 둬서도 안 된다. 백엔드 시스템이 강제해야 한다. AI 고객지원이 계정을 바꾸기 전에, 본인 확인은 대화가 아니라 시스템이 해야 한다를 참고하자.
교환 장치 자체에도 지켜야 할 것이 있다. AWS 글은 교환에 쓰는 agent 자격 증명이 전체 사슬에서 가장 민감한 열쇠라고 경고한다. 유출되면 누구든 아무 사용자의 token이나 신청할 수 있게 된다. 로그에도 token 전체를 남기지 말고 subject, audience, actor 같은 항목만 기록해야 한다.
실제로 돌고 있는 경로 하나를 그려 본다
이미 여러 시스템을 오가며 일하는 agent 하나를 골라, 가장 자주 지나는 경로만 그린다. 단계마다 같은 한 줄 형식으로 적는다.
대리되는 사용자 → 실행하는 agent → token 발급처 → 받는 시스템 → 허용된 동작 → 거부되는 조건
다 그리면 두 가지를 묻는다. 공용 계정만 보이는 단계가 있는가. 같은 token을 서로 다른 두 시스템이 받고 있지는 않은가. 어느 쪽이든 답이 “있다"라면, agent에게 일을 더 맡기기 전에 그 단계부터 좁힌다. agent에게 아직 자기 신원이 없다면 ERP 안의 AI agent에게는 자기 신원이 있어야, 로그에서 사람이 한 일과 AI가 한 일을 가릴 수 있다부터 보자.
AI 정리 카드
AI agent가 여러 시스템을 오가며 일할 때, 단계마다 신원 넘겨주기가 분명한지 확인하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-agent-on-behalf-of-token-handoff-map/
글의 관점은 이렇다. agent가 사용자를 대신해 여러 시스템을 잇달아 호출할 때 공용 계정을 쓰지 않고, 같은 token을 계속 넘기지도 않는다. 단계마다 그곳 전용이고 이번 작업에 필요한 권한만 담긴 새 token으로 바꾸고, "누구를 대리하는지"와 "누가 실행하는지"를 남긴다.
먼저 나에게 질문 3개를 해 달라:
1. 이 agent가 가장 자주 지나는 경로는 어떤 시스템을 어떤 순서로 거치고, 각 단계에서 무엇을 하는가;
2. 각 단계에서 agent는 어떤 신원으로 호출하는가. 사용자의 token인가, 교환한 새 token인가, 공용 서비스 계정인가;
3. 이 경로에 쓰기, 삭제, 결제, 권한 변경을 하는 동작이 있는가.
내 답을 바탕으로 다음을 출력해 달라:
- 단계마다 한 줄: 대리되는 사용자 / 실행하는 agent / 받는 시스템 / 허용된 동작 / 거부 조건. 확인할 수 없는 항목은 "확인 필요"로 표시;
- 공용 계정을 쓰는 단계, 또는 같은 token을 서로 다른 시스템이 받는 단계;
- 각 단계의 상태: 확인됨 / 확인 필요 / 차단 필요;
- 교환에 성공해도 사람이 확인한 뒤에 실행해야 하는 영향 큰 동작.
내 시스템 설정을 추측하지 말 것. 정보가 부족하면 먼저 나에게 물어볼 것.
참고 자료
- AWS Machine Learning Blog: Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway — https://aws.amazon.com/blogs/machine-learning/implement-on-behalf-of-token-exchange-for-multi-tenant-agents-with-amazon-bedrock-agentcore-gateway/ (2026-07-13)
- IETF / RFC Editor: RFC 8693: OAuth 2.0 Token Exchange — https://www.rfc-editor.org/rfc/rfc8693 (2020-01)
- Microsoft Learn: Microsoft identity platform and OAuth2.0 On-Behalf-Of flow — https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow (2026-06-15)
