Amazon Bedrock AgentCore와 RFC 8693 표준의 결합

AI 에이전트가 사용자를 대신해 내부 API를 호출할 때, 에이전트의 관리자 권한을 사용하면 감사 로그에 실제 요청자가 누락되고, 사용자의 토큰을 그대로 전달하면 API 서버가 권한 밖의 동작을 수행하는 보안 취약점이 발생한다. 이를 '혼동된 대리인(Confused Deputy)' 문제라고 하며, 에이전트의 권한을 악용해 사용자가 접근해서는 안 될 데이터에 접근하는 위험을 초래한다. 아마존 베드락 에이전트코어(Amazon Bedrock AgentCore)는 이 문제를 해결하기 위해 토큰 교환 표준인 RFC 8693을 도입했다.

아마존 베드락 에이전트코어 아이덴티티(Amazon Bedrock AgentCore Identity)는 OAuth 2.0 토큰 교환을 기본 credential-provider grant type으로 지원한다. 에이전트코어 게이트웨이(AgentCore Gateway)는 하위 도구를 호출하기 전, 인바운드 사용자 토큰을 대상 서비스 전용 토큰으로 자동 교환한다. 개발자가 직접 토큰 관리 코드를 작성할 필요 없이 게이트웨이 계층에서 처리되므로 비즈니스 로직 구현에만 집중할 수 있다.

이 메커니즘은 참조 구현체인 트래블봇(TravelBot)을 통해 확인할 수 있다. 트래블봇은 에이크메(Acme)와 글로벡스(Globex)라는 두 개의 서로 다른 테넌트(Tenant)를 지원하는 예약 도우미 에이전트로, 테넌트 간 권한 침범 방지 방식을 보여준다. 관련 구현 코드는 https://github.com/aws-samples/sample-obo-flow-poc 저장소에서 제공한다.

OBO(On-Behalf-Of) 토큰 교환의 작동 원리와 JWT 변환

OBO 흐름의 핵심은 JWT(JSON Web Token)의 클레임 변환을 통해 멀티테넌트 환경에서 사용자 신원을 유지하며 대상 서비스에 맞는 권한을 부여하는 것이다. 교환 과정에서 `sub`(subject, 사용자 식별자) 클레임은 그대로 유지하여 최종 API가 실제 사용자를 식별하게 하고, `aud`(audience, 대상 서비스) 클레임은 호출하려는 하위 서비스에 맞게 재작성하여 토큰의 사용 범위를 제한한다.

동시에 RFC 8693 표준에 따라 교환을 수행한 주체인 에이전트코어를 `act`(actor, 행위자) 클레임에 기록하며, Okta 환경에서는 `cid` 클레임을 사용한다. 전체 아키텍처는 User, Agent, AgentCore Gateway, AgentCore Identity, Tenant Auth Server, Downstream API의 6개 구성 요소로 작동한다. 하위 API는 전달받은 토큰 하나로 요청의 주체(`sub`)와 실제 동작 수행자(`act`)를 동시에 확인한다. 이를 통해 권한 결정은 사용자 기준으로, 속도 제한이나 감사 로그는 에이전트 기준으로 처리하는 정교한 제어가 가능하다.

이 구조는 각 홉(hop)마다 대상 서비스에 바인딩된 새 토큰을 발행하므로, 하위 서비스가 에이전트를 무조건 신뢰할 필요 없이 독립적으로 토큰을 검증하게 만든다. 결과적으로 사용자 개별 권한을 하위 API까지 안전하게 전파하고 명확한 감사 로그를 확보할 수 있다.

직접 전달 방식과 OBO 방식의 보안성 대비

사용자 권한을 그대로 전달하는 '직접 전달(Direct Forwarding)' 방식은 인바운드 토큰을 하위 서비스에 그대로 넘긴다. 이때 토큰의 `aud` 클레임은 에이전트 API를 대상으로 발행된 상태이므로 하위 서비스와 일치하지 않는다. 하위 서비스가 이를 수용하려면 `aud` 검증을 생략하거나 무분별하게 허용해야 하며, 이는 권한이 있는 대리자가 공격자의 요청을 정당한 요청으로 오인해 실행하는 혼동된 대리인 문제의 직접적인 원인이 된다.

반면 OBO 방식은 각 단계마다 대상 서비스에 바인딩된 새 토큰을 발행해 이 문제를 해결한다. 에이전트가 하위 도구를 호출할 때마다 해당 서비스 전용 토큰을 생성하므로, 하위 서비스는 전달받은 토큰의 `aud` 클레임이 자신의 서비스 식별자와 일치하는지 독립적으로 검증한다. 또한 `scp`(scope, 권한 범위)를 해당 도구 호출에 필요한 최소 수준으로 축소하여 전달함으로써 최소 권한 원칙을 구현하며, 특정 서비스의 토큰이 탈취되어도 다른 서비스로 권한이 확산되는 것을 방지한다.

[Figure 1]

TravelBot 사례에서 직접 전달 패턴은 인바운드 토큰과 하위 서비스 토큰이 동일해 보안 경계가 무너진 상태로 동작하지만, OBO 패턴은 각 단계마다 서로 다른 테넌트의 예약 API에 바인딩된 개별 토큰이 이동한다. 하위 API는 에이전트의 신원이 아닌 토큰 자체의 유효성과 축소된 `scp` 범위 내에서만 동작을 수행하여 시스템 전체의 보안성을 유지한다.

다양한 ID 제공자(IdP) 호환성 및 인프라 확장성

Amazon Bedrock AgentCore Identity는 RFC 8693 표준을 준수하여 특정 벤더에 종속되지 않고 Okta의 커스텀 인증 서버, Auth0의 커스텀 토큰 교환, Keycloak의 토큰 교환 기능을 모두 지원한다.

Microsoft Entra ID와 같이 RFC 7523 기반의 OBO 흐름을 사용하는 시스템을 위해 `grantType: JWT_AUTHORIZATION_GRANT` 설정을 네이티브하게 지원한다. 이는 RFC 7523의 JWT 베어러 토큰 교환 방식을 내부적으로 처리하여 개발자가 복잡한 인증 요청 메시지를 직접 구성할 필요 없이 Microsoft 생태계와 호환되도록 돕는다.

인증 서버 교체 시 소스 코드 수정 없이 `customParameters` 맵 설정만으로 대응이 가능하다. `subject_token_type`(원본 토큰 종류), `audience`(대상 서비스), `actor-token`(행위자 정보 포함 여부) 등의 세부 항목을 런타임 설정으로 관리하므로, IdP의 API 스펙이 미세하게 다르더라도 파라미터 조정만으로 즉시 적용할 수 있다.

인프라 측면에서는 퍼블릭 인터넷뿐만 아니라 VPC(Virtual Private Cloud) 내부의 프라이빗 연결을 지원한다. 기업 내부망에 구축된 프라이빗 IdP와 보안 터널을 통해 통신할 수 있어, 외부 노출 없이 내부 인증 서버와 연동해야 하는 금융이나 공공 분야의 폐쇄망 환경에서도 멀티테넌트 에이전트 구축이 가능하다.

한국 B2B AI 실무자를 위한 멀티테넌트 설계 시사점

B2B 환경에서 AI 에이전트에게 모든 테넌트 데이터에 접근할 수 있는 슈퍼 유저 권한을 부여하면, 보안 사고 발생 시 책임 소재를 가릴 수 없으며 혼동된 대리인 문제에 노출된다. 따라서 에이전트의 권한이 아닌 사용자 개별 권한을 하위 API까지 전파하는 구조가 필수적이다.

개발자가 인증 서버, 런타임, 하위 API 간의 복잡한 토큰 교환 로직을 직접 구현하는 것은 부담이 크다. AgentCore Gateway는 인터셉터 역할을 수행하며 도구 호출을 가로채 대상 테넌트를 식별하고, Identity 서비스에 토큰 교환을 요청하는 과정을 자동화한다. 이를 통해 개발자는 복잡한 토큰 갱신 코드를 작성하지 않고도 엔터프라이즈 수준의 보안 거버넌스를 확보할 수 있다.

사용자 식별자는 유지하고 행위자 정보만 추가하는 토큰 교환 방식은 에이전트에게 과도한 권한을 부여하던 관행을 해결한다. 하위 서비스가 독립적으로 권한을 검증하는 구조를 갖추면 에이전트의 오작동이 시스템 전체의 보안 사고로 이어지는 것을 방지할 수 있다.

멀티테넌트 에이전트를 구축하는 개발자는 혼동된 대리인 문제 해결 여부를 설계의 핵심 기준으로 삼고, RFC 8693 표준에 따른 클레임 변환 설정을 통해 테넌트별 독립적인 권한 제어 체계를 확보해야 한다.

멀티테넌트 AI 에이전트의 보안은 단순히 권한을 부여하는 것이 아니라, 권한을 어떻게 안전하게 '전달'하고 '제한'하느냐에 달려 있습니다. 아마존 베드락의 OBO 토큰 교환 구현법은 엔터프라이즈 환경에서 필수적인 감사 추적과 최소 권한 원칙을 동시에 달성할 수 있는 실무적인 가이드라인을 제시합니다.