AgentCore Identity에서 on‑behalf‑of 토큰 교환으로 다중 테넌트 신원 전파 구현 가이드

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

생성형 에이전트가 여러 테넌트를 대리하여 downstream API를 호출할 때 누구의 신원이 호출과 함께 이동해야 하는지가 핵심 문제로 드러났고, 이 문제는 inbound 토큰의 audience가 downstream과 일치하지 않을 때 특히 심각하다. Amazon Bedrock AgentCore Identity는 OAuth 2.0 Token Exchange(RFC 8693)를 네이티브 credential‑provider 그랜트로 지원하여 AgentCore Gateway가 인바운드 사용자 토큰을 도구 호출 전에 대상에 바인딩된 새 토큰으로 교환하도록 함으로써 sub 클레임을 보존하면서 aud 클레임으로 권한 범위를 제한한다. 이 방식은 에이전트 코드에 교환 로직을 추가할 필요를 없애고 발급된 토큰이 특정 downstream 서비스에서만 유효하도록 만들어 암호학적 최소 권한을 구현한다. 참조 구현인 TravelBot과 함께 Okta 대상 설정과 각 홉에서의 JWT 클레임 변형을 순차적으로 제시하여 다중 테넌트 전반에 걸친 방어 심층과 실무 적용 방법을 검증한다.

섹션별 상세

생성형 에이전트를 다중 테넌트 프로덕션에 배포할 때 downstream API 호출에 어떤 신원이 실려야 하는지의 문제가 발생한다; 에이전트가 자체 서비스 계정으로 호출하면 감사 추적이 붕괴되고, 사용자의 토큰을 그대로 전달하면 downstream이 혼란 대리인 상태에 빠질 수 있으며 둘 다 다수 테넌트에서 확장성이 떨어진다. 본문은 이러한 문제의 핵심이 inbound 토큰의 audience가 downstream 서비스와 일치하지 않는 점임을 지적하고, 단일 테넌트에서는 토큰 직접 전달이 충분할 수 있음을 분명히 했다. 다중 테넌트 시나리오에서는 각 호출마다 대상에 바인딩된 토큰이 필요하며 이를 자동화하지 못하면 감사와 권한 경계가 유지되지 않는다.

Amazon Bedrock AgentCore Identity가 OAuth 2.0 Token Exchange(RFC 8693)를 네이티브 credential‑provider 그랜트 타입으로 지원함으로써 AgentCore Gateway가 인바운드 사용자 토큰을 도구 호출 전에 대상(audience)에 바인딩된 새로운 토큰으로 투명하게 교환한다. 교환 과정에서 원래 호출자의 신원은 sub 클레임으로 보존되고 발급된 토큰은 aud 클레임으로 특정 downstream 서비스에 묶여 발급되어 권한의 최소화를 구현한다. 이 방식은 에이전트 코드에 교환 로직을 넣지 않아도 되며 표준화된 토큰 교환 요청 형식을 지원하는 인증 서버를 그대로 credential provider로 활용할 수 있다는 장점이 있다.

근거

AgentCore Identity가 OAuth 2.0 Token Exchange(RFC 8693)를 네이티브 credential‑provider 그랜트 타입으로 지원한다. — Introducing on-behalf-of token exchange in AgentCore Identity 섹션의 첫 문단
AgentCore Gateway는 인바운드 사용자 토큰을 downstream 도구 호출 전에 대상(audience)에 바인딩된 새 토큰으로 투명하게 교환할 수 있다. — Introducing on-behalf-of token exchange in AgentCore Identity 섹션의 설명 및 이점 목록

실습 차원에서 참조 구현인 TravelBot은 Acme와 Globex 두 테넌트를 서비스하는 다중 테넌트 예약 도우미로 제시되었고, 본 게시물은 Okta를 대상으로 한 완전한 OBO 설정을 단계별로 보여주며 각 홉에서 JWT 클레임이 어떻게 변형되는지와 audience binding이 어떻게 테넌트 전반에 걸쳐 방어 심층을 제공하는지를 입증한다. 참조 구현은 aws-samples/sample-obo-flow-poc 저장소에 공개될 예정으로 실제 설정 파일과 흐름을 통해 토큰 교환 요청과 응답의 필드 변화를 재현할 수 있다. 이러한 실무 예시는 설계 결정을 검증 가능한 형태로 제시하여 다중 테넌트 에이전트의 신원 전파와 권한 경계 설계에 실질적 지침을 제공한다.

용어 해설

Token Exchange (RFC 8693): — OAuth 2.0 Token Exchange(RFC 8693)는 클라이언트가 수신한 액세스 토큰을 다른 대상(audience)에 바인딩된 토큰으로 교환하는 표준 규격이다. 교환 요청은 원본 토큰의 소유자(sub) 정보를 보존하면서 새로운 aud 클레임을 포함한 토큰을 발급하도록 설계되어 다중 서비스 호출 시 권한 범위를 세분화할 수 있다. 다중 테넌트 에이전트 환경에서 에이전트가 대리로 호출할 때 발생하는 혼란 대리인 문제를 해소하는 핵심 수단이다.
Audience Binding: — 오디언스 바인딩은 발급된 액세스 토큰의 aud(대상) 클레임을 특정 downstream 서비스로 제한하는 방식이다. 토큰이 특정 서비스에만 유효하도록 청중을 고정하면, 동일 토큰이 다른 테넌트나 서비스에서 오용되는 것을 방지할 수 있다. 다중 테넌트 에이전트 아키텍처에서 권한의 최소화와 방어 심층을 제공하는 수단으로 중요하다.
Confused Deputy Problem: — 혼란 대리인 문제는 대리자(서비스)가 사용자 대신 호출을 수행할 때 본래 권한과 호출 대상 권한이 섞여 잘못된 권한 위임이 발생하는 취약성이다. 에이전트가 자체 서비스 계정으로 모든 호출을 수행하면 감사 추적이 붕괴되고, 반대로 원본 사용자의 토큰을 그대로 전달하면 downstream 서비스가 사용자의 의도가 아닌 에이전트의 권한으로 동작할 수 있다. 다중 테넌트 환경에서 OBO 패턴과 토큰 교환으로 이 문제를 완화할 수 있다.
JWT Claims: — JSON Web Token의 클레임은 토큰에 포함된 발행자, 주체(sub), 청중(aud) 등 메타데이터로서 수신 측에서 권한과 신원을 검증하는 데 사용된다. 본문에서는 각 홉(hop)에서 sub와 aud 클레임이 어떻게 변형되어 전파되는지와 그에 따른 보안 의미가 핵심 기술 요소로 다뤄졌다. 클레임 변형 추적은 감사와 권한 경계 유지에 필수적이다.