Govern AI agent access with Okta Cross App Access and Amazon Bedrock AgentCore – Part 2

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Okta Cross App Access(XAA)와 Amazon Bedrock AgentCore를 활용해 도구 연결·토큰 교환·Cedar 정책 평가를 Gateway로 모으고, Amazon EKS의 에이전트까지 같은 접근 통제와 추적 체계에 연결하는 확장 패턴을 설명한다.

📌 핵심 요약

• Part 1의 에이전트 1개·MCP 서버 2개 구조는 직접 연결, 에이전트별 자격 증명 접근 경로, 서버마다 복제된 groups 검사 때문에 확장 부담이 생긴다. Part 2는 Gateway에 대상 등록과 토큰 교환을 맡기고 Cedar 정책을 중앙에서 평가하되, MCP 서버의 사용자 groups·scope 검사는 유지한다.
• 각 에이전트는 자체 Gateway와 자격 증명 공급자를 사용하며, Gateway는 allowedClients로 해당 에이전트의 ID-JAG만 허용한다. 대상의 scope는 ID-JAG의 scope와 같아야 하고, 도구 이름을 고정하는 정적 스키마와 tools/list 페이지네이션 처리가 필요하다.
• Policy in AgentCore는 ENFORCE 모드에서 도구 목록 조회와 호출을 평가하며, permit 정책으로 기본 거부를 유지한다. Cedar는 client_id와 scope를 검사하고 hasTag로 누락된 태그를 방어해야 하며, 정책 연결 전 모든 정책의 ACTIVE 상태를 확인해야 한다. 에이전트 A의 실행 역할에서는 토큰 교환과 비밀정보 접근 권한을 제거한다.
• Amazon EKS의 보고 에이전트 B는 자체 Okta 등록과 xaa:read 권한을 사용한다. EKS Pod Identity 역할은 모델 호출과 자체 로그·추적 기록으로 제한하며, 에이전트는 모델 호출 전에 ID-JAG의 서명·발급자·대상·토큰 유형·만료·client_id를 검증한다.
• AgentCore Observability와 CloudWatch Transaction Search는 Gateway·Policy·Identity·MCP 서버 등의 OpenTelemetry 추적을 모으고, Okta System Log는 Amazon EventBridge를 통해 CloudWatch로 전달된다. 추가 구성은 약 90분이며 예제는 완전한 배포용 솔루션이 아니다. 제공 본문은 추적 표 중간에서 끝나므로, 도입부에 예고된 XAA와 사용자별 OAuth 동의 비교의 상세 내용은 확인할 수 없다.

🧩 주요 포인트

1. 직접 연결과 자격 증명 처리를 Gateway로 이동 → 에이전트별 도구 연결 부담과 실행 역할의 권한을 줄이면서, 에이전트마다 별도 Gateway·자격 증명 공급자를 두는 경계를 유지한다.
2. Cedar의 에이전트·위임 scope 검사와 MCP 서버의 사용자 groups 검사 병행 → 중앙의 도구 접근 정책과 사용자별 권한 판단을 결합하며, 정적 스키마·hasTag·ACTIVE 상태가 정책의 정상 작동 조건이 된다.
3. Amazon EKS 에이전트의 자체 ID-JAG 검증과 공통 OpenTelemetry 추적 → 실행 위치가 달라도 같은 접근 경로를 적용하고 각 통제 단계의 판단을 함께 살펴볼 수 있지만, 제공 본문만으로 OAuth 동의 비교의 결론까지 판단할 수는 없다.

🧠 상세 정리

1. 소규모 위임 구조에서 드러나는 확장 부담

Part 1은 Amazon Bedrock AgentCore runtime에서 실행되는 작업 에이전트가 Okta Cross App Access(XAA)를 통해 로그인한 사용자를 대신해 동작하는 구조를 구현했다. Okta가 에이전트와 사용자 사이의 위임을 결정하고 AgentCore Identity가 에이전트 내부에서 그 위임을 교환했지만, 구성은 에이전트 1개와 MCP 서버 2개로 의도적으로 작았다. 이를 수백 개의 에이전트와 수천 개의 도구로 늘리면 에이전트가 각 서버의 runtime ARN을 직접 보유하는 방식은 N개 에이전트와 M개 서버의 연결 관리 문제로 커진다. 사용자 대신 동작하는 에이전트마다 토큰 교환 권한과 공급자 비밀정보 접근 경로가 생기고, 서버마다 복제한 groups 검사도 서로 달라지거나 일괄 감사·변경하기 어려워진다. Part 2는 위임 메커니즘을 유지하면서 대상 등록, 토큰 교환, 공통 접근 정책을 Gateway 중심으로 재배치한다.

2. Gateway를 통과하는 위임과 권한 평가 흐름

사용자가 로그인하면 BFF는 Part 1과 동일하게 ID 토큰을 작업 에이전트 A에 발급되는 ID-JAG로 교환하고, 이 토큰으로 AgentCore runtime의 에이전트를 호출한다. 에이전트 A는 ID-JAG를 MCP 세션의 bearer 토큰으로 자체 Gateway에 전달하며, Gateway의 인바운드 인가기는 에이전트 A에 발급된 토큰만 받아들인다. Policy in AgentCore는 대상 호출에 앞서 도구 목록 조회와 개별 도구 호출마다 Cedar 정책을 평가하고, 허용된 호출에 대해서만 Gateway가 AgentCore Identity를 통해 Okta의 사용자 지정 인가 서버에서 ID-JAG를 교환한다. Cedar가 거부한 호출에서는 ID-JAG 교환이 일어나지 않으며, 허용된 요청도 MCP 서버에서 기존 groups와 scope 검사를 거친다. Part 1의 Okta 설정, AgentCore Identity 자격 증명 공급자, MCP 서버는 유지되고, Amazon EKS의 보고 에이전트 B도 자체 Gateway를 통해 같은 흐름에 참여한다.

3. 추가 구성의 준비 조건과 예제의 한계

Part 2를 구성하려면 Part 1의 솔루션에 더해 Amazon EKS의 두 번째 에이전트를 위한 eksctl, kubectl, Docker가 필요하다. Okta System Log를 CloudWatch로 보내기 위한 Okta Log Streaming과 함께, AgentCore Gateway·정책 엔진·EKS 클러스터·CloudWatch 로그 그룹·Amazon EventBridge 규칙을 다룰 IAM 권한도 요구된다. 추가 작업은 약 90분으로 제시되며, EKS 제어 영역 비용은 시간당 0.10달러이고 노드 비용과 EKS Auto Mode 관리 요금이 별도로 붙으며 AgentCore 기능은 사용량에 따라 과금된다. 기반 자료는 GitHub의 AWS 샘플 08-okta-xaa-delegation-chain이지만, 그 밖에 본문에 제시된 코드와 설정은 개념적 패턴을 설명하므로 완전한 배포용 솔루션으로 볼 수 없다. 원문은 비프로덕션용 샘플 코드라는 점을 명시하며 실제 배포 전에 조직의 보안·규제·컴플라이언스 요구를 충족하도록 보안 및 법무 담당자와 검토할 것을 안내한다.

4. Gateway의 ID-JAG 수신과 대상별 토큰 교환

Gateway의 인바운드 인가기는 Okta 조직 인가 서버를 발급자로, 사용자 지정 인가 서버를 대상으로 설정하고 allowedClients로 허용 에이전트를 고정하며, 예제의 허용 scope는 xaa:read와 xaa:write다. 각 MCP 서버는 Gateway 대상으로 등록되고, 아웃바운드 인증에는 Part 1의 JWT_AUTHORIZATION_GRANT 공급자를 통한 TOKEN_EXCHANGE를 사용하되 대상의 scope는 ID-JAG의 scope와 같아야 한다. Cedar에서 참조하는 도구 이름을 고정하려면 listingMode를 DEFAULT로 두고 인라인 mcpToolSchema를 제공해야 하며, 저자들의 테스트에서는 도구 이름을 지정한 정책을 동적으로 목록을 가져오는 대상에 연결할 수도 없었다. Gateway는 대상별로 tools/list를 페이지로 나누므로 클라이언트가 페이지네이션 커서를 따라가지 않으면 뒤쪽 대상의 도구가 누락된다. AgentCore Identity가 교환된 토큰을 보관하므로 단일 사용 ID-JAG 하나로 세션의 모든 도구 호출을 처리할 수 있고, 테스트에서는 5분의 유효기간 안에 두 번째 세션도 열 수 있었다. 공급자 하나는 Okta 에이전트 하나로 인증하므로 에이전트마다 Gateway와 공급자가 필요하며, 기반 샘플은 인터셉터가 두 번의 교환을 직접 수행하는 다른 방식을 사용한다.

5. Cedar의 기본 거부와 위임 scope 경계

Gateway에는 Policy in AgentCore 엔진을 ENFORCE 모드로 연결하고 permit 정책만 작성해, 일치하는 허용이 없으면 접근이 거부되도록 한다. Cedar는 JWT 클레임을 태그로 노출하는데 누락된 태그를 읽는 정책은 오류로 건너뛰므로, permit이 생략되면 권한이 생기지 않지만 forbid가 생략되면 차단도 적용되지 않는다는 차이를 고려해야 한다. 따라서 각 태그 접근 앞에 hasTag를 두고, 예제에서는 client_id가 지정한 에이전트와 같은지 확인한 뒤 쓰기 도구에 xaa:write를 요구한다. scope는 공백으로 구분된 문자열이므로 네 가지 일치 조건으로 전체 항목을 검사해 xaa:write-admin 같은 값이 xaa:write 권한으로 인정되지 않게 하며, 읽기 도구에는 같은 방식으로 xaa:read 정책을 적용한다. 연결 전 모든 정책이 ACTIVE인지 확인해야 하는데, 정책 생성에 실패한 엔진을 연결하면 Gateway가 모든 호출을 거부하기 때문이다. 이 계층은 도구를 에이전트와 위임 scope에 연결하며, 사용자별 권한은 계속 MCP 서버가 groups 클레임으로 판단한다.

6. 에이전트 A의 호출 경로와 실행 권한 변경

에이전트 A는 더 이상 AgentCore Identity를 직접 호출하지 않고, 허용 목록에 포함된 인바운드 Authorization 헤더에서 ID-JAG를 가져와 Gateway의 MCP 클라이언트로 전달한다. 기존에 각 MCP 서버로 향하던 호출 경로가 Gateway URL로 모이며, 대상마다 필요한 ID-JAG 교환은 Gateway가 수행한다. 이에 맞춰 에이전트 실행 역할에서 Part 1의 AgentCore Identity 관련 권한 구문을 제거하며, 원문은 이것이 해당 역할에 필요한 유일한 변경이라고 설명한다. 토큰 교환 권한은 Gateway 역할이 보유하므로 에이전트 역할에는 토큰 교환이나 비밀정보 접근 권한이 남지 않는다. 다만 runtime 인가기의 allowedClients 설정은 유지해야 하며, 이러한 변경은 에이전트의 실행 권한을 줄이면서 기존의 에이전트 식별 경계를 계속 적용하는 구조를 만든다.

7. Amazon EKS에서 실행되는 두 번째 에이전트

보고 에이전트 B는 같은 코드를 Amazon EKS에서 실행하지만 자체 Okta 등록, Gateway, 자격 증명 공급자를 사용하고, 리소스 연결은 xaa:read만 허용한다. EKS Pod Identity는 모델 호출과 자체 로그·추적 기록만 가능한 IAM 역할을 pod에 제공하며, 추적 내보내기에는 AWS Distro for OpenTelemetry(ADOT) SDK를 사용하고 Pod Identity 구성은 agents-on-eks 샘플을 참고한다. AgentCore runtime 밖의 pod 앞에는 인가기가 없으므로 에이전트가 모델 호출 전에 ID-JAG의 서명, 발급자, 대상, oauth-id-jag+jwt 토큰 유형, 만료 여부, 자체 client_id를 직접 검증해야 한다. Part 1의 에이전트 검사를 MCP 서버에 유지했다면 REGISTERED_AGENTS에도 에이전트 B의 클라이언트 ID를 추가해야 한다. 저자들은 EKS Auto Mode의 범용 노드 풀이 amd64만 실행하므로 다중 아키텍처 이미지를 빌드하고, AgentCore Python SDK가 기본적으로 localhost에 바인딩되므로 DOCKER_CONTAINER=true를 설정해야 했다고 설명한다.

8. 각 통제 단계의 판단을 추적으로 연결

Transaction Search와 추적 전송을 활성화하면 Runtime, Gateway, Identity, Policy는 코드 변경 없이 각 구간의 OpenTelemetry span을 내보내고, 자체 서비스는 ADOT로 추적을 추가한다. CloudWatch Transaction Search가 이를 수집하면 AgentCore 콘솔은 에이전트 추적으로 읽고, CloudWatch Omni는 같은 span을 traces.default로 읽어 Okta 이벤트와 함께 조회할 수 있으며, Okta System Log는 Amazon EventBridge를 통해 CloudWatch로 전달된다. 본문 표는 AgentCore.Gateway.InboundAuth가 해당 에이전트에 발급된 ID-JAG인지, AgentCore.Policy.AuthorizeAction이 도구의 Cedar 판단을, AgentCore.Identity.GetWorkloadAccessToken이 에이전트 워크로드 신원과 사용자의 연결을 기록한다고 설명한다. 이어 AgentCore.Identity.GetResourceOauth2Token은 Okta에서 범위가 제한된 접근 토큰으로 교환하는 과정을, AgentCore.Gateway.InvokeTool은 도구 호출과 결과를 기록하며, MCP 서버의 authz.check는 사용자 groups·에이전트·판단·사유를 기록하는 항목으로 제시된다. 다만 제공 본문은 이 표의 마지막 설명 도중 끝나며, 도입부에서 예고한 Okta 위임을 수용하지 못하는 애플리케이션의 사용자별 OAuth 동의 비교는 상세 내용이 포함되어 있지 않다.

🧾 핵심 주장 / 시사점

• Gateway로의 중앙화는 도구 연결과 토큰 교환의 책임을 옮기는 변화이며, MCP 서버의 사용자별 권한 검사는 계속 필요하다.
• Cedar 정책의 정확성은 허용 규칙뿐 아니라 태그 누락 처리, scope 전체 항목 일치, 도구 이름의 고정 여부에도 달려 있다.
• Amazon EKS에서도 같은 Gateway 경로를 사용할 수 있지만, runtime 밖에서는 에이전트가 ID-JAG를 직접 검증해야 하므로 실행 환경에 따른 책임 차이가 남는다.

✅ 액션 아이템

• 에이전트별 Gateway·자격 증명 공급자 분리, allowedClients, ID-JAG와 대상의 scope 일치, 정적 스키마와 tools/list 페이지네이션 처리를 점검한다.
• Cedar의 ENFORCE·permit·hasTag·ACTIVE 상태와 MCP 서버의 groups·scope 검사 유지를 확인하고, 에이전트 A의 토큰 교환·비밀정보 접근 권한 제거를 검증한다.
• Amazon EKS 에이전트 B의 ID-JAG 검증과 EKS Pod Identity 권한 제한을 확인하고, AgentCore Observability·CloudWatch Transaction Search·Okta System Log의 추적 연결을 점검한다.

❓ 열린 질문

• 에이전트별 Gateway에서 allowedClients, ID-JAG와 대상의 scope 일치, 정적 스키마와 tools/list 페이지네이션 처리가 모두 충족되는가?
• Cedar 정책의 hasTag와 ACTIVE 상태, MCP 서버의 groups·scope 검사는 각각 의도한 접근 경계를 적용하는가?
• 제공 본문에 상세 내용이 없는 XAA와 사용자별 OAuth 동의 비교에서는 어떤 적용 조건과 제약을 제시하는가?