---
type: "post"
id: "govern-ai-agent-access-with-okta-cross-app-d2ba0c"
slug: "govern-ai-agent-access-with-okta-cross-app-d2ba0c"
title: "Govern AI agent access with Okta Cross App Access and Amazon Bedrock AgentCore"
description: "AWS describes a reference implementation for governing agents that act on a user’s behalf across applications, combining Okta Cross App Access with Amazon Bedrock AgentCore Identity and runtime."
retrieval_nugget: "AWS describes a reference implementation for governing agents that act on a user’s behalf across applications, combining Okta Cross App Access with Amazon Bedrock AgentCore Identity and runtime. The pattern separates authorization decisions from credential handling and reports that revocation blocked new requests in about one second in AWS’s tests."
published_at: "2026-11-07"
updated_at: "2026-11-07"
record_date: "2026-11-07"
date_kind: "published_at"
topics: ["agent-identity","agent-security","governance"]
entities: ["Amazon Bedrock AgentCore","Okta Cross App Access","Okta","Amazon Web Services","Model Context Protocol"]
related_patterns: ["agent-security-moves-to-runtime-boundaries"]
novelty_label: "new_fact"
what_changed: "The story adds an Okta Cross App Access governance pattern for controlling AI agent access with Amazon Bedrock AgentCore."
prior_refs: ["https://newruntime.com/posts/build-a-semantic-layer-for-agentic-ai-on-ec1cc0/","https://newruntime.com/posts/getting-started-with-web-answer-on-amazon-bedrock-7b64a7/"]
source_url: "https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-access-with-okta-cross-app-access-and-amazon-bedrock-agentcore-part-1"
source_urls: ["https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-access-with-okta-cross-app-access-and-amazon-bedrock-agentcore-part-1"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:govern-ai-agent-access-with-okta-cross-app-d2ba0c"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/govern-ai-agent-access-with-okta-cross-app-d2ba0c/","markdown":"https://newruntime.com/posts/govern-ai-agent-access-with-okta-cross-app-d2ba0c.md","json":"https://newruntime.com/posts/govern-ai-agent-access-with-okta-cross-app-d2ba0c.json"}
markdown_url: "https://newruntime.com/posts/govern-ai-agent-access-with-okta-cross-app-d2ba0c.md"
---

# Govern AI agent access with Okta Cross App Access and Amazon Bedrock AgentCore

## Retrieval answer

AWS describes a reference implementation for governing agents that act on a user’s behalf across applications, combining Okta Cross App Access with Amazon Bedrock AgentCore Identity and runtime. The pattern separates authorization decisions from credential handling and reports that revocation blocked new requests in about one second in AWS’s tests.

## Summary

AWS describes a reference implementation for governing agents that act on a user’s behalf across applications, combining Okta Cross App Access with Amazon Bedrock AgentCore Identity and runtime. The pattern separates authorization decisions from credential handling and reports that revocation blocked new requests in about one second in AWS’s tests.

## What happened

AWS’s first installment in a two-part guide builds a task agent on Amazon Bedrock AgentCore runtime that acts for signed-in users through Okta Cross App Access (XAA). Okta is the governance plane: it decides which agent may act for which user against which resource. AgentCore Identity is the execution plane: it redeems Okta’s grant for a resource access token and keeps credentials out of agent code. AWS says the walkthrough takes about an hour and uses Python 3.11, AWS CLI version 2, boto3 1.43, AgentCore CLI 0.31.1 and AgentCore Python SDK 1.24.1, along with an Okta organization supporting XAA and custom authorization servers.

The request flow uses multiple tokens for distinct purposes. A user signs in through the agent’s linked Okta application. The backend exchanges the user’s ID token for an Identity Assertion JWT Authorization Grant (ID-JAG), authenticated as the agent. Okta checks that the agent is active, that the user is assigned to it, and that an administrator connected it to the requested authorization server and scopes. The ID-JAG is single-use and expires in five minutes. AgentCore runtime validates it; AgentCore Identity then redeems it for a five-minute access token naming both the user and agent and carrying the user’s groups. The resource accepts that access token.

AWS’s example gives the resource custom scopes `xaa:read` and `xaa:write`, while user-specific authority is carried in a `groups` claim. Its task manager checks both that a registered agent obtained the token and that the user’s group and scope allow the requested tool action. AWS also advises limiting the agent’s IAM role to its own workload identity, credential provider and secret. The runtime’s JWT authorizer should check the allowed client as well as issuer, audience and scopes; AWS reports that without the client check, a different agent’s grant reached the runtime, while adding it caused a refusal with HTTP 401.

In AWS’s tests, removing a user’s assignment led Okta to refuse new requests for that user within about one second, while already issued tokens expired within five minutes. AgentCore Identity added about 0.6 seconds to a request taking about 30 seconds end to end. For ten requests, its first call redeemed the grant in about half a second; a second MCP-server call returned the same token in a median of 58 milliseconds. AWS says each new ID-JAG produced a new token, so each request could reflect Okta’s latest decision. The post says its snippets and configurations demonstrate the pattern conceptually rather than providing a complete deployable solution; the sample code is for non-production use.

## What the archive adds

New Runtime’s earlier coverage described an Amazon Bedrock AgentCore reference design for agents working across multiple teams’ data without unrestricted access to their accounts ([earlier coverage, 2026-10-01](https://newruntime.com/posts/building-an-ai-powered-contract-intelligence-platform-with-7ab3d6/)). This AWS guide is a new fact on the broader question of delegated agent access: it specifies an Okta-mediated token chain and reports revocation and latency measurements. The earlier note is related by the cross-account governance problem, not by the same implementation.

## Trend signal

This supports the view that delegated agent identity depends on explicit authorization and revocation mechanisms, rather than treating an agent as a shared service account. It is consistent with New Runtime’s assumption that OAuth-based delegation, including token exchange and revocation, will remain a principal way to authorize agent access ([Delegated agent identity](https://newruntime.com/shifts/delegated-agent-identity/)). This implementation is a concrete example, not evidence that the approach is dominant across the market.

## Why now

AWS frames the guide around a gap in per-application OAuth consent and shared service accounts: neither readily answers which agent may act for which user, in which application, and how that authority is stopped. The two-part structure also points toward a follow-up implementation behind AgentCore Gateway, with Cedar policies, an EKS-hosted agent and CloudWatch audit data.

## Why it matters

An agent acting with a user’s permissions creates a control problem that ordinary workload credentials do not solve: the system needs to preserve both the agent’s identity and the user’s authority. The guide’s design puts policy decisions in the identity provider and token custody in a separate execution service. That division gives teams clear places to review assignment, scope, credential storage and resource-side enforcement.

The reported revocation behavior is especially relevant to systems where user access changes during an agent’s lifetime. A short-lived token bounds the window for already-issued authority, while checking a fresh grant for each request can make subsequent calls respond to updated policy. The approach is not turnkey: teams must configure linked applications, grant policies, IAM boundaries and checks in each resource. Still, it offers a useful architecture to evaluate before agents gain access to customer records, tickets or other permissioned systems.

## Limits and uncertainty

The measurements are AWS’s results from its own tests, not an independent benchmark or evidence of behavior across production workloads. Latency depends on the tested configuration, and the post does not establish how the design performs under concurrency or at larger scale. The walkthrough explicitly describes its snippets and configurations as conceptual and its code as non-production sample code, so teams must validate security, compliance and operational behavior in their own environments. The guide is the first part of a series; the second part is described as extending governance through AgentCore Gateway, Cedar policies and audit logging.

## Skill to build now

Map one agent workflow as an authorization chain before connecting it to a real resource. Identify the user sign-in token, the grant that binds user and agent, the resource token, and which component validates each one. Then write a resource-side check that requires both the registered agent identity and the user’s group or scope. AWS’s example makes the boundary explicit: a valid token alone should not imply permission to perform every action.

## Reader takeaway

Treat delegated agent access as an identity and runtime design problem, not a prompt instruction. AWS’s example separates policy approval, credential custody and resource enforcement, with short-lived tokens and a reported rapid response to revoked assignments. Its measurements are useful starting points, but the sample remains a pattern to test and harden rather than deploy unchanged.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Agent Identity](https://newruntime.com/topics/agent-identity.md): Explore the agent-identity topic hub.
- topic hub: [Agent Security](https://newruntime.com/topics/agent-security.md): Explore the agent-security topic hub.
- topic hub: [Governance](https://newruntime.com/topics/governance.md): Explore the governance topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)