AWS and Okta test which AI agent may act for which user

Amazon Web Services has published a two-part, measured test of how a company can decide which AI agent may act for which user, using Okta Cross App Access (XAA) for the decision and Amazon Bedrock AgentCore to carry it out. Both posts appeared on the AWS Machine Learning Blog on 6 November 2026. They are vendor-published with sample code, not a customer deployment, and AWS says the code is for non-production use. The numbers are from AWS's Okta test organisation.

The design: Okta decides, AgentCore executes

The agent is registered in Okta, an administrator approves the applications it may reach, and Okta evaluates policy each time the agent asks to act for a user. A request carries three tokens: the user's ID token, an Okta-issued grant called an ID-JAG (single-use, valid 5 minutes) and the access token the resource accepts. AgentCore Identity redeems the grant for a 5-minute access token that names both the user and the agent. The agent's own code never sees the credentials.

AWS says this adds about 0.6 seconds to a request that takes about 30 seconds end to end, mostly model and tool calls. In its medians of five runs, swapping the ID token for a grant at Okta took 216 ms and redeeming it through AgentCore Identity took 508 ms.

What happens when you revoke access

AWS measured what each Okta administrator action does to the next request and to tokens already issued.

• Delete the agent's resource connection: new requests are refused immediately; issued tokens work until they expire, up to 5 minutes.
• Remove a user's assignment to the agent: new requests are refused within about 1 second, even with an ID token the user already held; issued tokens last up to 5 minutes.
• Deactivate the agent: refused only after Okta runs the operation, which AWS's test org queued for 86 minutes with no cancel option.

One gap is called out directly. Okta does not re-check the user when a grant is redeemed. AWS's custom authorization server issued an access token 3 seconds after a user was removed, for a grant minted before the removal. AWS's advice is to mint a fresh grant for every request and treat the resource connection as the kill switch.

Why plain token exchange was not enough

AWS compared XAA with standard RFC 8693 token exchange against the same Okta server and user. Plain exchange carried the user's identity but not their authority: the token had no agent claim, the scopes widened from read to read and write, a user outside the writers group still received a token, and a user who had been unassigned could still exchange an earlier token. XAA returned only approved scopes and refused the others. AWS notes that Okta's guide shows an agent claim on exchanged tokens, which its test did not receive.

Part 2: one front door for many agents

The second post moves the same governance behind an AgentCore Gateway. Agents reach a single endpoint, the Gateway redeems the grant, and a default-deny Cedar policy set decides which tools each agent may see. A second agent on Amazon EKS got four tools instead of six because Cedar hid the write tools, and its attempt to create a task was refused with 'No policy applies to the request (denied by default)'. One agent's grant presented to the other agent was refused in 98 milliseconds, before any model call.

What the post leaves out

The tests use one Okta organisation, three users and a small topology. The post names no production deployment or operating cost. It also covers only targets whose authorization server accepts an ID-JAG. For applications such as GitHub that rely on per-user consent, AWS found that an earlier token kept working after the user was suspended in Okta, until it expired after 1 hour.

What to do with it

If you are giving agents access to internal systems, ask your identity vendor the same four questions AWS measured: how fast a removed user is refused, how long issued tokens live, what the kill switch is, and whether the user's group is re-checked at redemption.