ServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore Gateway에서 Microsoft Entra ID의 OBO 토큰 교환을 구성하면 AI 에이전트가 사용자의 신원과 권한을 유지하며 ServiceNow REST API를 호출할 수 있다.

📌 핵심 요약

• 사용자 신원이 전달되지 않으면 하위 API는 요청을 애플리케이션의 호출로 처리해 감사 추적과 사용자별 접근 통제, 최소 권한 원칙을 훼손한다. AgentCore Gateway는 요청마다 Microsoft Entra ID와 OBO 토큰 교환을 수행해 ServiceNow용 토큰에 원래 사용자 신원을 유지한다.
• 구성에는 AgentCore Gateway 접근이 가능한 AWS 계정, Microsoft Entra ID 테넌트, ServiceNow 관리 권한과 두 개의 Entra 애플리케이션 등록이 필요하다. 애플리케이션 등록에는 최소 Application Developer 역할이 요구되며, ServiceNow API 커넥터의 user_impersonation 범위와 에이전트의 위임 권한·클라이언트 자격 증명을 구성한다.
• ServiceNow는 API 커넥터의 클라이언트 ID를 audience로 받아들이고, preferred_username 등의 사용자 클레임을 기존 사용자 필드에 매핑해 해당 사용자의 권한을 적용한다. 인증 범위는 Table API 등 필요한 API로 제한하며, Entra의 uti를 jti로 매핑하는 방안은 재전송 방지와 차단 목록 적용을 보강하기 위한 고려 사항이다.
• AgentCore Gateway에서는 Customized provider 기반 OAuth 아웃바운드 인증에 에이전트 자격 증명과 Entra 검색 URL을 입력하고 JWT authorization grant를 선택한다. 네이티브 OBO 지원에는 MCP 버전 2025-11-25로 생성한 게이트웨이가 필요하며, 이전 MCP 버전으로 생성한 게이트웨이에는 네이티브 OBO를 활성화할 수 없다.
• ServiceNow REST 대상을 OpenAPI 스키마로 정의하고, 대상의 Outbound Auth configuration에서 OAuth와 앞서 만든 인증 구성을 선택한다. 예제는 Table API의 인시던트 조회를 다루지만, 제공된 source_body는 이 선택 이후 설명이 끊겨 대상 토큰 교환의 후속 설정과 실행 검증 절차는 확인할 수 없다.

🧩 주요 포인트

1. 에이전트와 ServiceNow가 요구하는 audience가 다름 → OBO 교환으로 대상 API에 맞는 토큰을 발급하면서 사용자별 권한과 감사 추적을 유지한다.
2. 두 개의 Entra 애플리케이션 등록, user_impersonation 위임 권한, ServiceNow 사용자 클레임 매핑이 연결됨 → 토큰 발급과 실제 사용자 권한 적용이 함께 성립해야 한다.
3. 네이티브 OBO는 MCP 버전 2025-11-25가 필수이고 source_body의 후속 설정은 누락됨 → 게이트웨이 생성 버전과 확인 가능한 구성 범위를 구분해 적용해야 한다.

🧠 상세 정리

1. 사용자 신원 전달이 필요한 이유

기업 API를 대신 호출하는 AI 에이전트는 최초 요청자의 신원을 요청 사슬 전체에 걸쳐 유지해야 한다는 것이 글의 출발점이다. 신원 전달이 없으면 하위 서비스는 호출자를 실제 사용자가 아니라 애플리케이션으로 인식하므로, 감사 추적이 깨지고 사용자 수준 접근 통제가 우회되며 최소 권한 원칙도 훼손된다. Amazon Bedrock AgentCore는 다양한 프레임워크와 모델로 에이전트를 구축·연결·최적화하는 플랫폼이며, 이 글은 그 기능인 AgentCore Gateway에 Microsoft Entra ID 기반 OBO 토큰 교환을 설정하는 방법을 설명한다. 교환은 게이트웨이 대상에 구성되며 요청마다 수행되고, 같은 패턴은 OAuth로 보호되는 다른 REST API에도 적용할 수 있다고 제시한다. 운영 환경에서는 Amazon Bedrock Guardrails를 함께 사용해 유해 콘텐츠를 걸러내고 에이전트의 입력과 출력을 검증할 수 있다는 추가 방안도 소개한다.

2. 세 구성 요소와 OBO 요청 흐름

전체 구조는 Microsoft Entra ID의 OAuth 애플리케이션 등록으로 보호되는 AI 에이전트, AgentCore Gateway로 구현한 MCP 서버, Entra ID와 연결된 인바운드 OAuth 통합을 사용하는 ServiceNow REST API로 구성된다. 사용자는 에이전트를 호출할 JWT를 얻고, 에이전트는 자신의 애플리케이션 등록을 대상으로 하는 JWT로 게이트웨이에 인증한다. 이 토큰의 audience는 에이전트 클라이언트 ID이지만 ServiceNow는 API 커넥터 클라이언트 ID를 audience로 요구하므로 그대로 사용할 수 없다. 게이트웨이는 수신 토큰과 에이전트의 클라이언트 자격 증명, 대상 범위, requested_token_use: on_behalf_of 매개변수를 Entra 토큰 엔드포인트에 전달한다. Entra는 호출 사용자의 위임 동의를 검증한 뒤 원래 사용자 클레임을 유지한 ServiceNow용 토큰을 발급하며, ServiceNow는 사용자 클레임을 기존 사용자에 연결해 그 사용자의 권한을 적용한다.

3. 사전 조건과 ServiceNow API 커넥터 등록

구성을 시작하려면 AgentCore Gateway에 접근할 수 있는 AWS 계정, 애플리케이션 등록 권한이 있는 Microsoft Entra ID 테넌트, 인바운드 OAuth 통합을 설정할 수 있는 ServiceNow 관리 권한이 필요하다. Entra에서 애플리케이션을 등록하는 계정에는 최소 Application Developer 역할이 요구되며, ServiceNow 인스턴스가 없다면 개인 개발자 인스턴스인 PDI를 생성할 수 있다고 안내한다. Entra 애플리케이션은 AI 에이전트와 ServiceNow API 커넥터를 각각 나타내는 두 개를 준비한다. 먼저 ServiceNow API 커넥터용 애플리케이션을 등록하고 Overview에서 Application (client) ID를 기록한다. 이어 Manage의 Expose an API에서 기본 Application ID URI를 사용해 user_impersonation이라는 범위를 추가하며, 이 범위가 OBO 토큰 교환에서 요청하는 대상이 된다.

4. 에이전트 등록과 위임 권한 연결

ServiceNow API 커넥터 다음에는 AI 에이전트를 나타내는 Entra 애플리케이션을 별도로 등록하고, ServiceNowAgent의 Application (client) ID를 기록한다. 이 등록에는 클라이언트 비밀을 생성해야 하며, AgentCore Gateway는 에이전트의 클라이언트 ID와 비밀을 OBO 교환을 수행하는 자격 증명으로 사용한다. 이어 에이전트 애플리케이션에 ServiceNow API 커넥터 애플리케이션을 호출할 API 권한을 부여해 위임 호출 관계를 구성한다. 여기서 API 커넥터 등록은 교환 후 토큰의 대상과 노출 범위를 제공하고, 에이전트 등록은 게이트웨이에 들어오는 토큰의 대상이자 교환 요청에 사용하는 자격 증명의 주체가 된다. 글은 이 Entra 구성이 두 애플리케이션 사이의 표준 OBO 통합에서 필요한 설정과 같으며, 그 밖의 별도 Entra 변경은 필요하지 않다고 설명한다.

5. ServiceNow의 OIDC 통합과 사용자 식별

ServiceNow 관리 콘솔에서는 System OAuth > Inbound Integrations로 이동해 OIDC 지원 ID 공급자가 발급한 타사 ID 토큰을 사용하는 새 인바운드 통합을 만든다. 이때 클라이언트 ID에는 에이전트 등록의 값이 아니라 Entra에서 만든 ServiceNow API 커넥터 등록의 값을 지정한다. 같은 화면에서 OIDC 공급자 구성을 만들고 Entra 테넌트의 OIDC 메타데이터 URL을 입력한 다음, 사용자 클레임을 적절한 ServiceNow 사용자 필드에 매핑한다. 예를 들어 Entra가 preferred_username에 사용자 이메일을 담는 경우 이를 ServiceNow의 Email 필드와 연결한다. 설정이 끝나면 ServiceNow는 API 커넥터 클라이언트 ID를 audience로 갖는 토큰을 받아들이고 preferred_username을 통해 호출 사용자를 확인하므로, 이 클레임이 기존 사용자와 연결되는 것이 사용자별 권한 적용의 핵심이다.

6. 토큰 재사용 방어와 API 접근 범위

ServiceNow의 OIDC 공급자 설정에서는 Entra 토큰에 JTI가 포함되지 않는 경우 JTI 검증을 해제하도록 안내하지만, 토큰 식별자를 활용한 보호 방안도 함께 제시한다. Entra가 발급하는 토큰에는 JTI에 해당하는 내부 클레임인 uti가 있으므로, 이를 jti 클레임에 매핑하는 방안을 고려하면 재전송 방지와 차단 목록 적용을 보강할 수 있다는 설명이다. 이는 원문이 제시하는 고려 사항이며 모든 환경에서 반드시 적용해야 하는 확정된 절차로 서술되지는 않는다. 이어 같은 통합 화면에서 APIConnector 같은 인증 범위를 만들고, 허용 대상을 Table API 또는 에이전트가 실제로 접근해야 하는 ServiceNow API로 제한한다. 사용자 신원을 올바르게 해석하는 설정과 호출 가능한 API를 제한하는 설정을 함께 구성함으로써, 사용자를 식별하면서 필요한 범위의 API 접근을 제공하는 구조를 완성한다.

7. AgentCore Gateway의 아웃바운드 인증과 버전 조건

Entra와 ServiceNow 설정을 마친 뒤 AgentCore의 Build > Identity > Add Outbound Auth > Add OAuth client에서 아웃바운드 인증 구성을 생성하고 Customized provider를 선택한다. 여기에 에이전트 애플리케이션 등록의 클라이언트 ID와 클라이언트 비밀, Entra 검색 URL을 입력하고 Additional configurations에서 JWT authorization grant를 선택해 JWT 기반 교환에 사용할 인증 구성을 만든다. 다음으로 Build > Gateways > Create gateway에서 새 게이트웨이를 생성할 때 추가 구성에서 MCP 버전 2025-11-25를 선택해야 한다. 글은 이 버전이 네이티브 OBO 지원에 필수이며, 이전 MCP 버전으로 생성한 게이트웨이에서는 네이티브 OBO를 활성화할 수 없다고 명시한다. 인바운드 신원 설정에는 기존 ID 공급자 구성을 사용하고, JWT Authorization Configuration에 앞서 기록한 ServiceNowAgent의 애플리케이션 ID를 추가한다.

8. ServiceNow REST 대상 정의와 제공 자료의 범위

게이트웨이에는 ServiceNow REST 엔드포인트를 가리키는 대상을 추가하고 OpenAPI 스키마를 인라인으로 정의하며, 예제의 서버 URL은 자신의 PDI 주소로 바꾸도록 안내한다. 예제는 ListIncidents라는 도구를 노출하는 경우를 설명하고, 실제 스키마에는 Table API의 /incident GET 경로와 getIncidents 작업 식별자를 정의한다. 조회 매개변수는 기본값 10의 sysparm_limit, 필터 문자열인 sysparm_query, 반환 필드를 지정하는 sysparm_fields이며, 응답에는 인시던트 식별자·번호·설명·심각도·상태·생성 시각 등이 포함된다. 인증은 JWT 형식의 bearerAuth로 선언하고, 대상의 Outbound Auth configuration에서는 OAuth를 선택한 뒤 앞서 만든 아웃바운드 인증 구성을 연결한다. 제공된 source_body는 그다음 설명을 시작하는 부분에서 끊기므로, 이후 대상별 토큰 교환 옵션이나 에이전트 실행 방법, 실제 검증 결과까지 제시된 것으로 해석할 수는 없다.

🧾 핵심 주장 / 시사점

• OBO의 핵심은 ServiceNow가 요구하는 audience에 맞춰 토큰을 바꾸면서도 최초 사용자의 신원을 유지하는 데 있다. 대상 API의 토큰 요건과 사용자별 접근 통제를 함께 충족하는 구조다.
• Entra에서 토큰을 발급받는 것만으로 사용자 권한 적용이 완성되지는 않는다. ServiceNow에서 preferred_username 등의 클레임이 기존 사용자에 연결되고, 필요한 API로 인증 범위가 제한되어야 한다.
• 이 구성은 게이트웨이 생성 시 선택하는 MCP 버전에 제약을 받는다. 또한 제공 자료가 대상 인증 선택 이후 끊겨 있어, 설명된 구성과 실제 종단 간 동작 검증을 구분해야 한다.

✅ 액션 아이템

• Microsoft Entra ID의 두 애플리케이션 등록, user_impersonation 위임 권한, 에이전트 클라이언트 자격 증명 구성 확인.
• ServiceNow의 preferred_username 사용자 매핑과 Table API 등 필요한 API로의 인증 범위 제한 확인.
• AgentCore Gateway의 MCP 버전 2025-11-25 충족 여부와 source_body에서 누락된 대상 토큰 교환 후속 설정 확인.

❓ 열린 질문

• ServiceNow에서 preferred_username은 어떤 기존 사용자 필드에 매핑되며 해당 사용자의 권한이 적용되는가?
• 사용할 AgentCore Gateway는 네이티브 OBO를 지원하는 MCP 버전 2025-11-25로 생성되었는가?
• source_body가 끊긴 지점 이후 ServiceNow 대상의 토큰 교환에는 어떤 추가 설정과 실행 검증 절차가 필요한가?