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

Governing AI Agent Access with Okta Cross‑App Access and Amazon Bedrock AgentCore – Part 1

Artificial‑intelligence agents are increasingly embedded in business applications, acting on behalf of users to update tickets, retrieve records, or trigger workflows. While this brings productivity, it also raises a critical security question: which agent may act for which user, in which application, and how can that be revoked instantly?

In this first part of a two‑part series we walk through a reference implementation that ties Okta Cross‑App Access (XAA) – the identity‑provider side of the governance plane – to Amazon Bedrock AgentCore – the execution plane that runs the agents. The result is a three‑token chain that enforces per‑user, per‑agent policies, provides short‑lived credentials, and reacts to policy changes in near‑real time.

---

1. Architecture Overview

The solution consists of three logical layers:

1. Governance (Okta XAA) – Okta stores the mapping of agents to users and resources. When an agent requests to act for a user, Okta validates the assignment, the agent’s activation status, and any scope or group constraints.
2. Execution (AgentCore Identity) – After Okta approves the request, AgentCore Identity exchanges the Okta grant for an AWS‑internal access token that the agent can use to call downstream services. The token is stored in a secure vault and never exposed to the agent code.
3. Runtime (AgentCore Runtime) – The agent code runs inside the AgentCore runtime, receives the short‑lived token, and invokes the target Model Context Protocol (MCP) services.

Each request therefore carries three tokens:

• ID token – identifies the signed‑in user (issued by the front‑end OIDC flow).
• Identity Assertion JWT Authorization Grant (ID‑JAG) – Okta’s decision that the agent may act for the user, single‑use, 5‑minute expiry.
• Access token – AWS‑internal token that binds the agent’s workload identity to the user and is used for actual resource calls.

The diagram below (conceptual) shows the flow:

1. User signs in via a BFF (backend‑for‑frontend) using OIDC.
2. BFF exchanges the user’s ID token for an ID‑JAG from Okta, authenticating as the agent.
3. AgentCore Runtime validates the ID‑JAG, then asks AgentCore Identity for an access token.
4. AgentCore Identity redeems the ID‑JAG at Okta’s custom authorization server, receiving a 5‑minute access token that includes the user’s groups.
5. The agent calls the MCP services with this token; the services verify the agent registration and group‑based scope.

Performance testing showed that policy revocation in Okta propagates within ~1 second, and previously issued ID‑JAGs naturally expire after 5 minutes, providing a tight window for remediation.

---

2. Prerequisites & Setup

| Requirement | Example Used | |-------------|--------------| | AWS account with Bedrock AgentCore access (Claude model) | US‑West‑2 (Oregon) | | Okta organization with Cross‑App Access and API Access Management enabled | Free‑plan Integrator | | Development tools | Python 3.11, AWS CLI v2, `boto3`, AgentCore CLI 0.31.1, AgentCore Python SDK 1.24.1 | | IAM permissions | Ability to create AgentCore resources and IAM roles |

The walkthrough assumes about one hour of hands‑on time. All code snippets are illustrative; they are not production‑ready and should be reviewed by security and compliance teams before deployment.

---

3. Registering the Agent in Okta

1. Create a custom authorization server for the target resource (e.g., a task‑manager API). Set the audience to `api://task-manager` and define custom scopes `xaa:read` and `xaa:write`. Add a groups claim filtered to names that start with `xaa-` – this claim carries the user’s authority.
2. Register the AI agent via Directory > AI Agents → Register AI agent → Register manually. Generate a client secret; the agent and its linked OIDC app share the same client ID.
3. Connect the agent to the authorization server on the Resource connections tab and limit the scopes to the custom ones created earlier. Okta will reject any ID‑JAG request that includes standard OIDC scopes (e.g., `openid`), ensuring the agent only receives the intended permissions.
4. Create a policy that allows the agent to request the custom scopes for users who belong to the appropriate `xaa-` groups. This policy is the core of the governance plane – when an admin removes a user from the group, subsequent token exchanges fail within seconds.

---

4. Building the AgentCore Runtime Component

The sample repository `08-okta-xaa-delegation-chain` provides a baseline. The key steps are:

1. Define the runtime manifest to include a JWT authorizer that only accepts ID‑JAGs issued to the registered client ID.
2. Implement the agent code (Python) that:

- Receives the ID‑JAG from the BFF. - Calls `AgentCoreIdentity.gettoken(idjag)` to obtain the short‑lived AWS token. - Invokes the MCP endpoint with the token in the `Authorization: Bearer <token>` header.

1. Configure AgentCore Identity with the Okta custom authorization server URL, client ID, and secret. The identity service will handle the RFC 7523 JWT grant exchange automatically.
2. Deploy the runtime using the AgentCore CLI (`agentcore deploy runtime …`). The deployment creates an AWS Lambda‑style container that runs the agent code under a dedicated IAM role.

During testing, the additional latency introduced by AgentCore Identity was ~0.6 seconds on a request that otherwise took about 30 seconds end‑to‑end – a modest overhead for the security guarantees gained.

---

5. Observations & Best Practices

• Single‑use grants: Enforce the ID‑JAG as a one‑time token; reuse attempts are rejected, limiting replay attacks.
• Short expiry: Keep the ID‑JAG lifetime at 5 minutes and the final access token at the same window. This balances usability with rapid revocation.
• Group‑based scopes: Leverage Okta’s groups claim to encode fine‑grained permissions (e.g., `xaa-read‑tickets`). Updating group membership instantly changes what an agent can do.
• Monitoring: Emit CloudWatch metrics from AgentCore Runtime for each grant validation and token exchange. Alert on spikes in denied requests, which may indicate policy misconfiguration or abuse.
• Separation of duties: Keep the identity vault (AgentCore Identity) isolated from the agent code; the agent never sees raw credentials, only the opaque access token.

---

6. What’s Next?

Part 2 of this series extends the pattern to AgentCore Gateway with Cedar policies, demonstrates a multi‑region deployment on Amazon EKS, and shows how to capture an audit trail in Amazon CloudWatch Logs. Together, the two parts provide a complete, production‑grade blueprint for governing AI agents across an enterprise.

---

Takeaway: By coupling Okta’s Cross‑App Access governance with Amazon Bedrock AgentCore’s identity and runtime capabilities, you can enforce per‑user, per‑agent policies, achieve near‑instant revocation, and keep credential handling secure—all while adding only minimal latency to your AI‑driven workflows.