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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Okta Cross App Access(XAA)와 Amazon Bedrock AgentCore를 결합해 AI 에이전트의 사용자 대리 접근을 중앙에서 승인하고, 사용자·에이전트 신원을 담은 단기 토큰으로 실행하는 구성을 설명한다.

📌 핵심 요약

• Okta는 에이전트 등록, 사용자 할당, 리소스 연결과 요청 범위를 평가한다. 저자들의 테스트에서는 사용자 할당 제거 후 약 1초 이내에 새 요청이 거부됐고, 이미 발급된 토큰은 5분 이내에 만료됐다.
• 요청은 사용자 신원을 나타내는 ID 토큰, Okta의 위임 결정을 담은 일회용·5분 유효 ID-JAG, 리소스가 수락하는 5분 유효 액세스 토큰으로 이어진다. 액세스 토큰에는 사용자와 에이전트 신원, 사용자 그룹이 담긴다.
• AgentCore runtime은 Okta의 ID-JAG를 검증하고, AgentCore Identity는 에이전트 코드에 클라이언트 비밀을 노출하지 않고 토큰 교환과 보관을 수행한다. 테스트에서 전체 약 30초 요청에 AgentCore Identity가 추가한 시간은 약 0.6초였다.
• 예제의 리소스 audience는 api://task-manager이며 사용자 그룹과 xaa:read·xaa:write 범위로 도구 권한을 제한한다. ID-JAG 요청에는 사용자 지정 범위가 하나 이상 필요하며, openid·profile 같은 OpenID Connect 범위를 포함하면 거부된다.
• 사용자는 에이전트에 연결된 Okta 앱으로 로그인해야 하며, 각 Okta 에이전트에는 자체 AgentCore Identity 자격 증명 공급자가 필요하다. 두 토큰 교환의 클라이언트가 일치해야 하고, 비밀은 AWS Secrets Manager로 관리한다. 제공 코드는 비프로덕션 예제이며 완전한 배포용 솔루션은 아니다.

🧩 주요 포인트

1. Okta의 위임 승인과 AgentCore Identity의 토큰 실행을 분리함으로써 중앙 정책을 AWS 실행 환경에 연결하지만, 할당 철회 이후에도 이미 발급된 토큰의 5분 유효기간은 남을 수 있다.
2. 사용자·에이전트 신원과 사용자 그룹·xaa:read·xaa:write 범위를 함께 전달하므로, 도구 권한은 사용자 신원뿐 아니라 등록된 에이전트와 위임 범위까지 연결해 판단해야 한다.
3. 연결된 Okta 앱, 에이전트별 자격 증명 공급자, 두 교환의 클라이언트 일치가 위임 체인의 전제다. 약 1초의 차단 시간과 약 0.6초의 추가 지연은 저자들의 테스트 결과이므로 적용 환경에서의 확인이 필요하다.

🧠 상세 정리

1. 사용자 대리 접근의 통제 문제와 측정 결과

티켓을 수정하거나 고객 기록을 읽는 AI 에이전트는 사용자가 접근할 수 있는 애플리케이션에서 그 사용자를 대신해 행동하므로, 어떤 에이전트가 누구를 대신해 어디에 접근할 수 있고 이를 어떻게 중단할지가 핵심 문제다. 원문은 애플리케이션별 OAuth 동의와 공유 서비스 계정만으로 남는 이 문제를 Okta Cross App Access(XAA)의 중앙 정책 평가로 다룬다. 관리자는 에이전트를 등록하고 접근 가능한 애플리케이션을 승인하며, Okta는 사용자 대리 요청마다 정책을 평가한다. 저자들의 테스트에서는 사용자에 대한 에이전트 할당을 제거한 뒤 약 1초 이내에 새 요청이 거부됐지만, 이미 발급된 토큰은 최대 5분 동안 유효할 수 있었다. AgentCore Identity가 전체 약 30초 요청에 추가한 시간은 약 0.6초였으며, 이 수치들은 해당 테스트에서 관찰한 결과로 제시된다.

2. 거버넌스와 실행을 연결하는 세 토큰

이 구성에서 Okta는 어떤 에이전트가 어떤 사용자를 대신해 어느 리소스에 접근할지 결정하는 거버넌스 계층이고, AgentCore Identity는 자격 증명을 보관하고 그 결정을 리소스용 토큰으로 바꾸는 실행 계층이다. 사용자가 연결된 Okta 앱을 통해 로그인하면 BFF가 사용자 ID 토큰을 에이전트 자격으로 교환해 ID-JAG를 받으며, Okta는 에이전트 활성 상태와 사용자 할당, 대상 인가 서버 연결 및 요청 범위를 확인한다. 일회용이며 5분 후 만료되는 ID-JAG는 AgentCore runtime 호출의 bearer 토큰으로 쓰이고, runtime의 JWT 인가기는 Okta가 해당 에이전트에 발급한 ID-JAG만 수락한다. 이후 AgentCore Identity가 리소스의 Okta 사용자 지정 인가 서버에서 이를 교환하면 사용자와 에이전트 신원, 사용자 그룹을 담은 5분 유효 액세스 토큰이 발급된다. 에이전트는 이 토큰으로 MCP 서버를 호출하고, 작업 관리자는 등록된 에이전트가 얻은 토큰인지와 사용자 그룹·범위가 도구 사용을 허용하는지 확인한다.

3. 실습 범위와 예제의 한계

Part 1은 AgentCore runtime에서 로그인한 사용자를 대신해 동작하는 작업 에이전트를 만들고, 필요한 AgentCore Identity 구성과 도구의 사용자 권한 적용, 각 검사가 거부하는 요청 및 통제 반영 속도를 다룬다. 실습에는 AgentCore와 Amazon Bedrock의 Anthropic Claude 모델에 접근 가능한 AWS 계정, XAA와 API Access Management를 지원하는 Okta 조직, AgentCore 리소스와 IAM 역할 생성 권한이 필요하다. 저자들은 US West(Oregon), Okta Integrator Free Plan, Python 3.11, AWS CLI 2, boto3 1.43, AgentCore CLI 0.31.1과 Python SDK 1.24.1을 사용했으며, 예상 실습 시간은 약 1시간이고 사용량에 따른 요금이 발생한다. 기반은 GitHub의 08-okta-xaa-delegation-chain 샘플이지만, 본문 코드와 설정은 개념적 패턴을 보여주는 비프로덕션 예제로서 완전한 배포용 솔루션은 아니며 배포 전 조직의 보안·규제·컴플라이언스 요구사항을 검토하도록 안내한다. Part 2에서는 같은 거버넌스를 AgentCore Gateway 뒤에 배치하고 Cedar 정책, Amazon EKS의 두 번째 에이전트, Amazon CloudWatch 감사 추적을 추가할 예정이라고 설명한다.

4. 리소스 인가 서버와 범위 구성

Okta 구성은 리소스용 사용자 지정 인가 서버, 에이전트, 둘 사이의 연결, 에이전트의 grant를 허용하는 정책으로 이루어지며 관리 콘솔에서 설정한다. 예제에서는 리소스 audience를 api://task-manager로 지정하고 xaa:read와 xaa:write라는 사용자 지정 범위를 만든다. ID-JAG 요청은 사용자 지정 범위를 하나 이상 포함해야 하며, openid나 profile 같은 OpenID Connect 범위를 함께 요청하면 Okta가 invalid_scope로 거부한다. 액세스 토큰에는 이름이 xaa-로 시작하는 그룹만 담는 groups 클레임을 추가해 사용자의 권한 정보를 도구까지 전달한다. 또한 인가 서버 정책에서 에이전트의 JWT Bearer grant를 허용하고 액세스 토큰 수명을 5분으로 설정해야 하며, grant 허용이 빠지면 두 번째 교환이 no_matching_policy로 실패하고 토큰 수명은 철회된 위임이 계속 작동할 수 있는 시간을 제한한다.

5. 에이전트 등록과 로그인 앱의 결합

관리자는 Okta Admin Console의 Directory와 AI Agents 메뉴에서 에이전트를 수동 등록하고, 필요하면 소유자를 지정한 뒤 연결된 OpenID Connect 앱을 생성한다. Client registration에서 Client secret을 선택해 비밀을 발급하고 에이전트를 활성화하며, 에이전트 등록이 연결 앱을 생성하므로 별도의 앱 통합 마법사는 필요하지 않다. 에이전트와 연결 앱은 하나의 클라이언트 ID를 공유하고 사용자도 반드시 그 앱으로 로그인해야 하며, 다른 앱에서 발급된 ID 토큰은 해당 에이전트에 대한 위임 등록이 없다는 오류로 교환이 실패한다. Resource connections에서는 필요한 범위로 제한해 리소스 인가 서버를 연결하고, 에이전트를 통해 행동할 사용자나 그룹을 할당한다. 연결 앱의 로그인 정책도 해당 사용자의 등록된 인증 수단을 허용해야 하며, 원문은 테스트 조직의 그룹별 정책과 별개로 실제 사용자에게는 다중 요소 인증을 포함한 조직 정책을 적용하도록 설명한다.

6. BFF의 첫 번째 토큰 교환

웹 프런트엔드의 BFF는 각 요청에서 Okta 조직 인가 서버의 /oauth2/v1/token 엔드포인트로 사용자 ID 토큰을 보내고, RFC 8693 토큰 교환을 통해 ID-JAG 발급을 요청한다. 이때 BFF는 에이전트의 클라이언트 ID와 비밀로 인증하며, 요청에는 ID 토큰이라는 subject token 유형, ID-JAG라는 요청 토큰 유형, 대상 사용자 지정 인가 서버의 audience와 필요한 사용자 지정 범위를 지정한다. 예시 요청은 xaa:read와 xaa:write를 사용하지만, 앞선 구성 원칙대로 리소스에 필요한 범위만 요청해야 한다. 원문은 08-okta-xaa-delegation-chain 샘플이 인가 서버와 JWT Bearer 정책 생성을 스크립트로 제공하고, 06-okta-xaa의 agent/xaa_client.py가 같은 교환을 Python으로 보여준다고 안내한다. BFF가 에이전트 자격으로 인증하는 만큼 클라이언트 비밀은 코드나 설정 파일에 두지 않고 AWS Secrets Manager에 저장하도록 명시한다.

7. AgentCore Identity 공급자와 비밀 관리

AgentCore Identity는 워크로드 신원, OAuth2 자격 증명 공급자, 토큰 저장소를 사용하며, 에이전트 코드는 클라이언트 비밀을 보거나 Okta 토큰 엔드포인트를 직접 호출하지 않는다. 자격 증명 공급자는 리소스의 사용자 지정 인가 서버를 가리키고 에이전트 자격으로 인증하며, on-behalf-of grant를 JWT_AUTHORIZATION_GRANT로 설정해 ID-JAG를 assertion으로 보내는 RFC 7523 교환을 수행한다. Okta는 두 교환을 ID-JAG에 명시된 클라이언트에 결합하므로 에이전트마다 별도 공급자가 필요하고, 다른 에이전트 자격으로 교환한 테스트에서는 클라이언트 ID가 일치해야 한다는 오류가 발생했다. 기본적으로 비밀은 서비스가 관리하는 AWS Secrets Manager 비밀에 저장되며 update-oauth2-credential-provider로 교체할 수 있고, 조직이 관리하는 비밀의 ARN을 참조하면 공급자 수정 없이 비밀을 교체할 수 있다. 원문은 공유 비밀을 피하려는 경우의 대안으로 Private Key JWT 인증도 안내하며, 공급자가 얻은 액세스 토큰은 AgentCore Identity의 토큰 저장소에 보관된다.

8. runtime이 관리하는 사용자·워크로드 결합

AgentCore runtime은 각 에이전트 runtime의 워크로드 신원을 생성하고 관리하므로, 이 구성에서 해당 신원을 직접 만드는 주체는 에이전트 개발자가 아니라 runtime이다. 요청이 runtime의 JWT 인가기를 통과하면 runtime은 워크로드 신원과 인바운드 토큰의 발급자·주체를 결합한 워크로드 액세스 토큰을 AgentCore Identity에서 받아 에이전트 코드에 전달한다. 이 토큰은 AWS 내부에서 에이전트 워크로드와 사용자의 관계를 묶는 용도이며, Okta나 리소스에는 노출되지 않으므로 앞서 설명한 세 토큰에는 포함되지 않는다. 에이전트가 AgentCore Identity에 리소스용 액세스 토큰을 요청하면 Identity는 이 결합 뒤의 ID-JAG를 교환의 assertion으로 사용한다. 제공된 source_body는 이 설명 직후 문장 중간에서 끝나므로, 이후 호출 코드나 추가 권한 검사 구현의 구체적인 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 위임 철회는 새 요청 차단과 기존 토큰 만료라는 두 시간축으로 작동한다. 따라서 약 1초의 새 요청 거부 결과만으로 이미 발급된 토큰까지 즉시 무효화된다고 해석할 수 없다.
• 중앙의 위임 승인과 도구의 사용자 그룹·범위 검사는 서로 다른 역할을 맡는다. Okta의 승인 결과를 전달받더라도 리소스에서 등록된 에이전트와 사용자의 도구 권한을 확인하는 단계가 필요하다.
• 연결 앱과 에이전트별 공급자의 클라이언트 일치는 위임 체인의 핵심 제약이다. 자격 증명을 코드 밖으로 옮기는 것과 함께 이 신원 연결을 정확히 구성해야 토큰 교환이 성립한다.

✅ 액션 아이템

• Okta의 사용자 할당·리소스 연결에 따른 새 요청 차단과 기존 토큰의 5분 만료 동작을 적용 환경에서 검증.
• api://task-manager의 도구 권한을 사용자 그룹과 xaa:read·xaa:write로 제한하고, ID-JAG 요청의 OpenID Connect 범위 제외 여부 확인.
• 연결된 Okta 앱과 에이전트별 AgentCore Identity 자격 증명 공급자의 클라이언트 일치를 확인하고, 비밀을 AWS Secrets Manager로 관리.

❓ 열린 질문

• 사용자 할당 제거 후 이미 발급된 토큰이 최대 5분 동안 유효할 수 있는 조건을 적용 환경에서 수용할 수 있는가?
• 적용 환경에서도 Okta의 새 요청 차단이 약 1초 이내에 반영되고 AgentCore Identity의 추가 지연이 약 0.6초 수준으로 나타나는가?
• 사용자 그룹과 xaa:read·xaa:write 범위가 각 도구에서 허용할 사용자 대리 작업을 충분히 구분하는가?