Scaling AI agent governance with AWS Bedrock AgentCore and Okta

Amazon Web Services has released the second part of a technical guide detailing how to scale secure AI agent operations. Published on November 6, 2026, the article explains how to replace direct agent-to-tool connections with a centralized gateway architecture. This approach uses Amazon Bedrock AgentCore, Okta Cross App Access, and Cedar policy engines to manage permissions across hundreds of agents and tools.

What happened

In the first part of this series, engineers built a single task agent that acted on behalf of signed-in users. That initial setup relied on a small topology where the agent held runtime addresses for Model Context Protocol (MCP) servers and performed token exchanges directly. While functional for proof-of-concept scenarios, this method creates a complex wiring matrix as systems grow. Each new tool requires updates to every agent that needs access, and every agent must hold credentials for every resource it might reach.

The new guide addresses these scaling limitations by introducing Amazon Bedrock AgentCore Gateway as a single front door. Instead of agents calling tools directly, they route requests through the Gateway. This component handles identity redemption and enforces access policies before any tool is invoked. The update also introduces a second agent running on Amazon Elastic Kubernetes Service (Amazon EKS) to demonstrate that the governance model works regardless of where the agent is hosted. This shift moves security logic from individual servers to a centralized policy engine, reducing code duplication and audit complexity.

How it works

The architecture centers on the AgentCore Gateway, which accepts an Identity Assertion JWT Authorization Grant (ID-JAG) from the agent. This token proves the user has authorized the agent to act. The Gateway’s inbound authorizer validates that the token was issued specifically for that agent by Okta. Once validated, the Gateway consults a policy engine powered by Cedar. These policies define exactly which tools an agent can use based on its identity and the scopes granted by the user. If the policy permits the action, the Gateway uses AgentCore Identity to exchange the ID-JAG for a scoped access token from Okta.

This process ensures that agents never handle secret credentials or perform token exchanges themselves. The agent’s execution role no longer requires permissions for token exchange or secret reading. Instead, the Gateway holds these privileges. The MCP servers still perform final checks on user groups, but the primary authorization decision happens at the Gateway. This separation allows organizations to update access rules in one place rather than modifying code across thousands of servers. All decisions are logged as OpenTelemetry spans, providing a complete audit trail.

Key details

• Centralized Gateway: Agents connect to a single Gateway endpoint instead of managing direct connections to multiple MCP servers, simplifying network topology.
• Cedar Policy Engine: Access control is defined using Cedar policies that bind specific tools to agents and scopes, enforcing a default-deny stance.
• Token Exchange Offloading: The Gateway redeems Okta grants for access tokens, removing the need for agents to hold credential permissions or secrets.
• Multi-Environment Support: The solution supports agents running on both Bedrock AgentCore runtime and Amazon EKS, using consistent identity verification methods.
• Unified Observability: AgentCore Observability collects traces from the Gateway, Policy, and Identity components, which can be joined with Okta System Logs in Amazon CloudWatch.
• Static Tool Schemas: Targets must use static tool schemas to ensure policy references remain stable, as dynamic listings can complicate policy enforcement.

Why it matters

For software teams building enterprise AI applications, security scalability is a major bottleneck. Managing permissions for dozens of agents and hundreds of tools quickly becomes unmanageable if each agent maintains its own connection logic. By centralizing authorization, organizations can reduce the risk of configuration drift. Security teams can audit and update policies in a single location, ensuring that changes apply consistently across all agents. This model also minimizes the attack surface, as agents no longer store sensitive credentials or have broad permissions to exchange tokens.

The integration with observability tools provides critical visibility into agent behavior. In regulated industries, proving who authorized an action and when is essential. The ability to join Okta grant events with detailed execution traces in CloudWatch allows engineers to reconstruct the full context of any agent action. This level of transparency helps teams debug permission issues and satisfy compliance requirements without building custom logging infrastructure from scratch.

What you can do

• Review the sample code: Examine the AWS sample 08-okta-xaa-delegation-chain on GitHub to understand the baseline architecture before adding Gateway components.
• Implement the Gateway: Configure an AgentCore Gateway with an inbound authorizer that validates ID-JAGs from your Okta authorization server.
• Define Cedar policies: Write permit-only policies that map agent client IDs and scopes to specific tool actions, ensuring a default-deny posture.
• Set up observability: Enable CloudWatch Transaction Search and configure Okta Log Streaming to EventBridge to create a unified audit view.
• Test multi-environment agents: Deploy a secondary agent on Amazon EKS to verify that the Gateway correctly handles identities from outside the Bedrock runtime.
• Validate token scopes: Ensure that the scopes requested by the Gateway match those in the ID-JAG to prevent token exchange failures.