🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

다중 테넌트 에이전트가 사용자의 신원을 보존하면서도 각 하위 서비스에만 유효한 토큰을 사용하도록, 아마존 베드록 에이전트코어 게이트웨이와 아이덴티티로 대리 토큰 교환을 구현하는 방법을 설명한다.

📌 핵심 요약

• 에이전트의 서비스 계정으로 하위 API를 호출하면 사용자별 감사 추적이 사라지고, 사용자의 기존 토큰을 그대로 전달하면 대상 서비스와 토큰의 수신 대상이 일치하지 않아 혼동된 대리인 문제가 발생한다.
• 대리 토큰 교환은 원래 사용자의 주체 식별자는 유지하되 수신 대상을 호출할 서비스로 바꾸고 권한 범위를 축소해, 사용자 신원 전파와 암호학적 최소 권한을 동시에 달성한다.
• 에이전트코어 게이트웨이는 인바운드 토큰을 검증하고 테넌트별 대상을 선택하며, 에이전트코어 아이덴티티는 해당 테넌트의 권한 부여 서버를 상대로 표준 토큰 교환을 수행한다.
• 예제 트래블봇은 에이컴과 글로벡스라는 두 테넌트에 각각 별도의 권한 부여 서버, 수신 대상, 접근 정책, 토큰 검증기를 배치해 테넌트 간 토큰 재사용을 차단한다.
• 하위 API는 발급자·수신 대상·권한 범위를 독립적으로 검증하고, 비즈니스 로직은 사용자 식별자와 허용 범위를 이용해 사용자별 데이터 접근 및 쓰기 권한을 제한한다.

🧩 주요 포인트

1. 에이전트의 서비스 계정으로 하위 API를 호출하면 사용자별 감사 추적이 사라지고, 사용자의 기존 토큰을 그대로 전달하면 대상 서비스와 토큰의 수신 대상이 일치하지 않아 혼동된 대리인 문제가 발생한다.
2. 대리 토큰 교환은 원래 사용자의 주체 식별자는 유지하되 수신 대상을 호출할 서비스로 바꾸고 권한 범위를 축소해, 사용자 신원 전파와 암호학적 최소 권한을 동시에 달성한다.
3. 에이전트코어 게이트웨이는 인바운드 토큰을 검증하고 테넌트별 대상을 선택하며, 에이전트코어 아이덴티티는 해당 테넌트의 권한 부여 서버를 상대로 표준 토큰 교환을 수행한다.
4. 예제 트래블봇은 에이컴과 글로벡스라는 두 테넌트에 각각 별도의 권한 부여 서버, 수신 대상, 접근 정책, 토큰 검증기를 배치해 테넌트 간 토큰 재사용을 차단한다.
5. 하위 API는 발급자·수신 대상·권한 범위를 독립적으로 검증하고, 비즈니스 로직은 사용자 식별자와 허용 범위를 이용해 사용자별 데이터 접근 및 쓰기 권한을 제한한다.

🧠 상세 정리

1. 다중 테넌트 에이전트의 신원 문제

다중 테넌트 환경에서 생성형 인공지능 에이전트가 사용자를 대신해 하위 API를 호출할 때는 어떤 신원이 그 호출과 함께 전달되어야 하는지가 핵심 문제가 된다. 에이전트의 서비스 신원만 사용하면 모든 요청이 같은 주체에서 발생한 것처럼 보여 사용자별 감사 추적이 무너지고, 하위 시스템은 에이전트를 무조건 신뢰해야 한다. 반대로 사용자의 인바운드 토큰을 변경 없이 전달하면 그 토큰이 원래 에이전트나 게이트웨이를 대상으로 발급됐음에도 하위 도구가 이를 받아들여야 하므로 혼동된 대리인 문제가 생긴다. 특히 한 에이전트가 여러 테넌트와 여러 서비스를 연결하고 실제 도구 호출 시점에 사용자가 직접 참여하지 않는 구조에서는 두 방식 모두 안전하게 확장되기 어렵다.

2. 대리 토큰 교환의 역할과 적용 범위

대리 토큰 교환은 오어스 2.0 토큰 교환 표준인 알에프시 8693을 이용해 인바운드 사용자 토큰을 특정 하위 API에만 유효한 새 토큰으로 바꾸는 방식이다. 새 토큰은 원래 호출자의 주체 식별자를 유지하면서 수신 대상을 대상 서비스로 변경하고, 필요한 최소 권한만 포함하도록 범위를 줄일 수 있다. 에이전트코어 아이덴티티는 이 교환을 자격증명 공급자의 기본 권한 부여 유형으로 지원하므로 에이전트 코드가 직접 교환 절차를 구현할 필요가 없다. 이 패턴은 인바운드 토큰의 수신 대상이 개별 하위 서비스와 다른 다중 테넌트 구조에서 필수적이며, 단일 테넌트에서 기존 수신 대상이 하위 서비스와 이미 일치하는 경우에만 직접 전달이 충분할 수 있다.

3. 세 가지 호출 방식과 혼동된 대리인 위험

첫 번째 선택지는 에이전트가 자신의 서비스 계정으로 인증한 뒤 헤더나 경로 매개변수에 사용자 정보를 넣는 방식이지만, 하위 API가 에이전트의 주장을 조건 없이 믿어야 한다는 문제가 있다. 이 경우 에이전트가 침해되면 공격자는 임의의 사용자와 테넌트를 가장할 수 있으므로 전형적인 혼동된 대리인 취약점이 된다. 두 번째인 사용자 토큰 직접 전달은 토큰의 수신 대상이 하위 API와 정확히 일치할 때만 작동하며, 여러 테넌트나 도구 게이트웨이를 거치는 환경에서는 일반적으로 이 조건을 충족하지 못한다. 세 번째인 대리 토큰 교환은 신뢰받는 권한 부여 서버가 원래 사용자, 대상 API, 대리 행위자를 각각 표현하는 새 토큰을 발급하므로 하위 API가 에이전트를 맹목적으로 신뢰하지 않고도 호출을 독립적으로 검증할 수 있다.

4. 토큰 청구값 변환과 권한 분리

대리 교환에서는 사용자를 나타내는 주체 청구값은 유지되고, 수신 대상 청구값은 실제로 호출할 하위 서비스에 맞게 다시 설정된다. 교환을 수행한 행위자는 알에프시 8693의 행위자 청구값이나 옥타의 클라이언트 식별자 청구값처럼 별도의 항목에 기록되므로, 하위 API는 누구를 대신하는지와 누가 행동을 수행하는지를 구분할 수 있다. 원문은 권한 부여 결정을 원래 사용자 주체에 기반해 내리고, 감사 기록과 호출량 제한은 대리 행위자에 기반해 처리해야 한다고 설명한다. 또한 새 토큰의 권한 범위를 최소 수준으로 축소하고 수신 대상을 하나의 서비스에 결합하면, 한 테넌트용 토큰을 다른 테넌트의 API에 재사용하는 행위를 암호학적으로 차단할 수 있다.

5. 트래블봇과 옥타 기반 참조 구성

참조 구현인 트래블봇은 에이컴과 글로벡스라는 두 테넌트를 지원하는 예약 도우미로, 인바운드 인증과 테넌트별 토큰 발급 역할을 분리한다. 트래블봇 공급자 권한 부여 서버가 에이전트에 전달할 인바운드 토큰을 발급하고, 에이컴 여행 API와 글로벡스 여행 API 권한 부여 서버가 각 테넌트의 수신 대상에 맞는 대리 토큰을 발급한다. 사용자 로그인에는 별도의 오픈아이디 커넥트 애플리케이션이 사용되며, 에이전트코어 아이덴티티는 대리자 애플리케이션의 자격증명으로 실제 교환을 수행한다. 세 권한 부여 서버는 모두 사용자 정의 서버이며, 사용자 정의 수신 대상과 권한 범위를 지원하지 않는 옥타의 기본 조직 권한 부여 서버는 이 패턴에 사용할 수 없다.

6. 다른 신원 공급자와의 호환 조건

이 구조의 역할은 옥타에 한정되지 않으며, 호환되는 토큰 교환 기능을 제공하는 다른 권한 부여 서버도 자격증명 공급자로 사용할 수 있다. 에이전트코어 아이덴티티가 보내는 주체 토큰 유형, 수신 대상, 행위자 토큰 포함 여부, 클라이언트 인증 방식은 자격증명 공급자의 사용자 정의 매개변수로 설정되므로 공급자 변경은 주로 구성 작업으로 다뤄진다. 오스제로와 키클록은 알에프시 8693 방식의 토큰 교환을 제공하지만, 마이크로소프트 엔트라 아이디는 다른 권한 부여 유형과 대리 사용 매개변수를 사용하는 별도 흐름을 따르며 에이전트코어는 이에 대응하는 권한 부여 유형도 지원한다. 아마존 코그니토 사용자 풀은 인바운드 호출을 인증하는 공급자 역할을 맡을 수 있지만 소비자 측 대리 교환 역할에 사용할 때는 현재 지원 범위를 문서에서 확인해야 하며, 사설 신원 공급자는 가상 사설 클라우드 연결로 접근할 수 있다.

7. 여섯 구성 요소와 방어 계층

전체 아키텍처는 공급자 권한 부여 서버, 에이전트코어 게이트웨이, 에이전트코어 아이덴티티, 테넌트별 권한 부여 서버, 테넌트별 API 표면, 테넌트 비즈니스 로직의 여섯 요소로 구성된다. 공급자 서버는 게이트웨이에 제시할 인바운드 토큰을 발급하고, 게이트웨이는 공개 키 집합으로 서명과 수신 대상을 검증한 뒤 올바른 테넌트 도구로 요청을 라우팅한다. 아이덴티티는 대리자 자격증명을 보관하고 선택된 테넌트의 권한 부여 서버를 상대로 교환을 실행하며, 각 서버는 자체 수신 대상과 접근 정책에 따라 새 토큰을 발급한다. 마지막으로 테넌트별 API의 토큰 검증기가 발급자·수신 대상·필수 권한을 다시 확인하므로, 앞선 계층이 잘못 구성되더라도 다른 테넌트용 토큰이 최종 API에서 거부될 수 있는 심층 방어가 형성된다.

8. 요청 흐름과 최종 데이터 격리

요청은 사용자가 권한 부여 코드 로그인으로 공급자 서버에서 인증하고, 게이트웨이를 수신 대상으로 하는 인바운드 토큰을 에이전트가 받는 단계에서 시작한다. 에이전트는 모델 컨텍스트 프로토콜을 통해 도구를 호출하면서 이 토큰을 전달하고, 게이트웨이는 공급자의 공개 키 집합을 조회해 서명과 수신 대상이 트래블봇 공급자에 맞는지 확인한다. 이어 게이트웨이는 요청 대상 테넌트에 연결된 자격증명 공급자를 선택하고 아이덴티티를 통해 해당 테넌트용 토큰 교환을 조정하며, 하위 API는 교환된 토큰을 자체 검증한다. 비즈니스 로직은 사용자별 허용 권한 청구값으로 쓰기 가능 여부를 판단하고, 데이터베이스 기록을 주체 식별자로 분할해 사용자가 자신의 예약만 읽도록 제한함으로써 인증뿐 아니라 실제 데이터 접근에서도 테넌트와 사용자 격리를 유지한다.

🧾 핵심 주장 / 시사점

• 다중 테넌트 보안의 핵심은 에이전트를 신뢰하는 것이 아니라, 원래 사용자·대리 행위자·대상 서비스를 토큰 안에서 분리하고 각 하위 API가 이를 독립적으로 검증하게 만드는 데 있다.
• 수신 대상 결합은 단순한 토큰 형식 변경이 아니라 한 테넌트에서 발급된 자격증명이 다른 테넌트나 서비스로 확산되는 것을 차단하는 최소 권한 경계로 작동한다.
• 표준 기반 교환을 게이트웨이와 신원 계층에 맡기면 에이전트는 하나의 인바운드 토큰으로 도구를 호출하는 단순한 구조를 유지하면서도 테넌트별 권한 부여 정책과 감사 가능성을 확보할 수 있다.

✅ 액션 아이템

• 서비스 계정 기반 하위 API 호출을 중단하고, 사용자 주체 정보를 유지한 대리 토큰 교환 경로로 호출 흐름을 재정의한다.
• 에이전트코어 게이트웨이에서 인바운드 토큰을 검증해 테넌트별 대상을 선택하고, 아이덴티티가 각 테넌트 권한 부여 서버와 표준 교환을 통해 하위 호출 토큰을 발급하도록 연계한다.
• 테넌트마다 권한 부여 서버·수신 대상·접근 정책·검증기를 분리해 배치하고, 하위 API에서 발급자·수신 대상·권한 범위를 독립 검증해 테넌트 간 토큰 재사용을 차단한다.

❓ 열린 질문

• 사용자 주체 식별자는 유지하되 토큰 수신 대상을 서비스별로 바꾸는 범위 축소 규칙은 어떤 기준으로 정해야 하는가?
• 에이전트코어 게이트웨이와 권한 부여 서버 간 토큰 교환이 실패할 때 사용자별 감사 추적은 언제 중단·복구해야 할지 어떻게 판단할 것인가?
• 발급자·수신 대상·권한 범위를 독립 검증할 때 테넌트 간 토큰 재사용을 식별하는 신호는 어떤 지표로 구분해야 하는가?