AWS published the second part of its guide on governing AI agent access through Okta Cross App Access and Amazon Bedrock AgentCore, shifting token checks from individual MCP servers to a central AgentCore Gateway. The setup adds Cedar policies, a second agent on Amazon EKS, and joint audit in CloudWatch, with about 90 minutes needed for the additions. The pattern matters because enterprises running hundreds of agents cannot maintain authorization logic inside every tool.
Gateway, policy and audit replace per-server checks
Part 1 used one task agent on AgentCore runtime, two MCP servers, and authorization code written into each server. Okta decided which agent could act for which user, while AgentCore Identity redeemed the Okta grant inside the agent. The post keeps the Okta configuration, Identity credential provider, and MCP servers unchanged and builds on AWS sample 08-okta-xaa-delegation-chain on GitHub. Snippets in the post are conceptual and marked as sample code for non-production use.
AgentCore Gateway becomes the single front door and redeems the Okta grant for each target through TOKEN_EXCHANGE with the existing credential provider. Its inbound authorizer uses Okta org authorization server as issuer, a custom authorization server as audience, and allowedClients pinned to one agent. Each MCP server becomes a Gateway target, with scopes required to equal the ID-JAG scopes. Agent A now forwards its inbound ID-JAG to the Gateway instead of calling Identity itself.
Three implementation details affect reliability of the Gateway targets. Targets need a static tool schema with listingMode set to DEFAULT and inline mcpToolSchema, so tool names referenced by Cedar policies stay fixed. Gateway pages tools/list by target, so clients must follow the pagination cursor or tools from later targets disappear. Identity keeps the token from the Gateway exchange, allowing one single-use ID-JAG to serve every tool call in a session and, in tests, a second session within its 5-minute life.
What centralized agent access control means
For companies operating several agents, the change removes token-exchange and secret permissions from agent execution roles and concentrates them in the Gateway role. Each agent receives its own Gateway and credential provider because a provider authenticates as one Okta agent. A reporting agent B runs the same code on EKS with its own Okta registration, Gateway, provider, and xaa: read-only resource connection. EKS Pod Identity limits the pod to model invocation and its own logs and traces.
Policy enforcement uses an AgentCore Policy engine attached to the Gateway in ENFORCE mode with permit-only Cedar policies. Cedar exposes JWT claims as tags, binds tools to the agent and delegated scope, and requires hasTag guards because a policy reading a missing tag is skipped. Scope matching treats xaa: write as a whole entry, so xaa: write-admin does not match, while a parallel policy permits read tools with xaa: read. Engines with failed policy creation leave the Gateway denying every call, so policies must show ACTIVE status.
Observability links Runtime, Gateway, Identity, and Policy spans with application spans through Transaction Search and trace delivery to CloudWatch. Okta System Log is brought into CloudWatch Omni as traces. default, allowing one query to join an ID-JAG grant to later allow and deny decisions. For user Alice, the example shows a grant of xaa: read xaa: write, then a create_task denial after 16.7 seconds followed by a list_tasks allowance. ADOT setup requires botocore for region discovery and signing, plus OTEL_PYTHON_DISABLED_INSTRUMENTATIONS tuning so BFF trace context reaches the agent.
