What happened
AWS’s Part 2 guide extends a Part 1 example in which an Amazon Bedrock AgentCore runtime agent acts for signed-in users through Okta Cross App Access (XAA). The earlier topology had one agent, two MCP servers and authorization checks in each server. AWS argues that the same arrangement becomes difficult to operate across hundreds of agents and thousands of tools: direct connections create a wiring matrix, each agent needs a credential path, and duplicated group checks can drift or become difficult to audit.
The revised design makes Amazon Bedrock AgentCore Gateway the front door. A backend for frontend exchanges a signed-in user’s ID token for an Okta-issued Identity Assertion JWT Authorization Grant, or ID-JAG, for agent A. The agent forwards that grant as the bearer token of its Gateway MCP session. The Gateway’s inbound authorizer checks the issuer, audience, allowed client and scopes. Amazon Bedrock AgentCore Policy then evaluates Cedar policies on every tool listing and tool call before the Gateway invokes a target.
For a permitted call, AgentCore Identity redeems the ID-JAG at Okta for a scoped access token. The target MCP server still evaluates the user’s groups and scope, rather than treating the Gateway policy as the complete authorization decision. AWS says the agent execution role can therefore lose token-exchange and credential-provider secret permissions; the Gateway role holds the exchange permission instead. The guide recommends static tool schemas for targets whose names appear in Cedar policies, and says clients must follow the Gateway’s pagination cursor when listing tools across targets.
AWS also demonstrates a second reporting agent on Amazon EKS with its own Okta registration, Gateway and credential provider. Its resource connection permits only xaa:read; Cedar hides write tools, while the pod’s IAM role can invoke models and write its own logs and traces. Outside the AgentCore runtime, AWS says the agent must validate the ID-JAG before a model call, including its signature, issuer, audience, token type, expiry and client identity. In its test, a grant issued to agent A and sent to agent B on EKS was refused in 98 milliseconds before a model call.
For auditing, AgentCore Runtime, Gateway, Identity and Policy emit OpenTelemetry spans after trace delivery is enabled. The MCP server adds an authz.check span with its user, agent, decision and reason. Okta streams System Log events through Amazon EventBridge to CloudWatch. AWS shows an Amazon CloudWatch Omni query that joins an ID-JAG grant to downstream tool decisions within a five-minute window. In its validation table, Bob using agent B saw four read tools, while write tools were hidden and a write request was denied by default.
AWS estimates that the additions take about 90 minutes to configure. Amazon EKS control-plane cost is listed at $0.10 per hour, plus nodes and the EKS Auto Mode management fee; AgentCore features are charged for use. The walkthrough requires eksctl, kubectl, Docker, Okta Log Streaming and relevant AWS permissions. AWS describes the configurations as conceptual and the sample code as non-production, directing teams to complete security, legal and compliance review before deployment.
What the archive adds
New Runtime’s earlier coverage on 2026-09-30 described an Amazon Quick and Amazon Bedrock AgentCore contract-intelligence case in which agents extract and verify contract fields while analytics handles portfolio and contract questions (earlier coverage). That was a related AgentCore use case, not the same access-governance event. This guide adds a distinct technical pattern for delegated authorization across agents and tools.
Trend signal
This supports the shift toward OAuth-based delegated agent identity: the delegated-agent-identity assumption says OAuth delegation, including token exchange, will remain a main authorization path for MCP and agent access. AWS’s example makes that pattern concrete with ID-JAG grants, agent-specific Gateways and policy enforcement. It does not establish how broadly enterprises will adopt this architecture or whether it will become the preferred implementation.
Why it matters
The design separates three decisions that are easy to blur in an agent integration: whether a grant belongs to this agent, whether that agent may invoke this tool under its delegated scope, and whether the user is authorized for the requested operation. Centralizing the first two checks can reduce duplicated authorization logic and avoid giving every agent a token-exchange path to every downstream resource.
The tracing design offers an equally practical operational model. A team can connect the identity provider’s grant record to the Gateway’s inbound check, the policy decision and the tool server’s eventual allow or deny. That creates a chain for investigating an unexpected agent action without relying solely on an agent transcript or an application-level log. It also makes different authority for the same user through different agents explicit rather than accidental.
The important lesson is not simply to add a Gateway. A centralized enforcement point is useful only if policy changes are owned and tested, target schemas stay stable, and operators can inspect evidence from identity provider through tool server. Teams should also decide which layer owns each denial: a malformed grant, a missing scope, an agent-specific Cedar rule and a user-group restriction are different failures with different remediation paths.
Limits and uncertainty
AWS presents a reference implementation and its own test results, not an independently assessed production deployment or evidence of enterprise-wide adoption. The code is explicitly for non-production use, and the configurations are described as conceptual rather than complete. The timing and latency figures reflect AWS’s tests and do not establish performance across different workloads, regions, identity-provider setups or tool servers.
The architecture also depends on correct operation across several services: Okta grant issuance and log streaming, Gateway configuration, Cedar policy creation, token exchange, MCP server checks and trace delivery. Teams will need to validate failure behavior, policy rollout controls, logging retention, access review and total operating cost in their own environment. A successful demonstration of default deny does not by itself prove that a production policy inventory is complete.
Skill to build now
Map one existing agent-to-tool path as separate authorization decisions this week. Write down the grant issuer and audience, the agent identity, the tool-level policy, the user-level permission check and the audit event each layer emits. Then test one intentionally invalid request: the wrong agent grant, a missing scope or a user without the needed group. The exercise exposes whether a tool call fails at a deliberate boundary and whether an operator can identify that boundary from logs.
Reader takeaway
Treat delegated agent access as a chain of independently verifiable controls, not a token passed from an agent to a tool. AWS’s example places agent identity and tool scope at a Gateway, leaves user authorization with the MCP server, and correlates both with Okta’s records. That division is a useful blueprint for governable multi-agent systems, even though the published implementation is not production-ready.