Govern AI agent access with Okta Cross App Access and Amazon Bedrock AgentCore – Part 2
In Part 1 you built one governed agent. Part 2 scales the pattern to an enterprise: Amazon Bedrock AgentCore Gateway becomes the single front door and redeems Okta's grant, Cedar policies bind each tool to the agent, a second agent runs on Amazon EKS, and AgentCore Observability traces every allow and deny beside Okta's log in Amazon CloudWatch.
In Part 2, the focus is on streamlining the governance of AI agent access using Okta Cross App Access and Amazon Bedrock AgentCore. Previously, a task agent was built on Amazon Bedrock AgentCore, which ran on its own runtime and acted for signed-in users through Okta Cross App Access. Okta's system determined which agent could act for which user, and Amazon Bedrock AgentCore's Identity capability redeemed Okta's grant inside the agent.
This post aims to make the changes from Part 1 and create a more scalable solution for enterprises with numerous agents and tools. Instead of having each agent connect directly to multiple Model Context Protocol (MCP) servers, the changes involve creating a single front door - the Amazon Bedrock AgentCore Gateway. This gateway redeems Okta's grant for each target and holds the policy evaluations.
The architecture remains largely the same as in Part 1, with the user signing in and the backend for frontend exchanging the ID token for an Identity Assertion JWT Authorization Grant (ID-JAG) issued to the task agent. The agent then forwards the ID-JAG to its Gateway as the bearer token of its MCP session.
The Gateway's inbound authorizer only accepts ID-JAGs issued by Okta for the resource's authorization server. Policy evaluations in AgentCore check each tool listing and call before the Gateway invokes the target. If the call is permitted by Cedar policies, the Gateway redeems the ID-JAG for each target through Okta's custom authorization server. Calls denied by Cedar do not redeem the ID-JAG.
The MCP server continues to check the user's groups and scope, and each decision is recorded as an authz.check span. Every hop includes OpenTelemetry spans sent to AgentCore Observability, which collects data in CloudWatch, and Okta streams its System Log to CloudWatch through Amazon EventBridge.
A second agent on Amazon Elastic Kubernetes Service (Amazon EKS) is added to demonstrate that the front door doesn't care where an agent runs. Amazon Bedrock AgentCore Observability, when combined with Amazon CloudWatch, gives a centralized place to view every decision, including Okta's.
Prerequisites for this post include the Part 1 solution, eksctl, kubectl, and Docker. The second agent on Amazon EKS, Okta Log Streaming, Okta's System Log in CloudWatch, and the necessary AWS IAM permissions are also required. The additions to the solution should take approximately 90 minutes, with additional costs for Amazon EKS clusters, AgentCore features, and other resources used.
Written by urgent.news from AWS Machine Learning's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.
This story
This is one outlet's version. Read the fullest account.