AWS published two engineering posts measuring what happens when an identity administrator pulls an AI agent’s access, using Okta Cross App Access with Amazon Bedrock AgentCore. In its tests, new requests stopped in about 1 second, and tokens already issued kept working for up to 5 minutes.
What AWS measured
The two posts describe one test system. An agent is registered in Okta as an identity, an Okta administrator approves which applications it may reach, and Okta evaluates that policy each time the agent asks to act for a user. AgentCore Identity then turns Okta’s decision into a short-lived access token that the target application accepts. Part 1 builds a task agent on AgentCore runtime with two Model Context Protocol servers. Part 2 moves the same controls behind AgentCore Gateway and adds a second agent on Amazon EKS.
AWS tested what each administrator action does to the next request and to tokens already in circulation. After an administrator removed a user’s assignment to the agent, Okta refused new requests for that user within about 1 second. Deleting the agent’s resource connection was refused immediately. In both cases, tokens already issued kept working until they expired, which AWS puts at up to 5 minutes because it set the access token lifetime to 5 minutes. Deactivating the agent behaved differently: AWS says its test Okta org queued that operation for 86 minutes before new requests were refused.
Where the controls leave a gap
AWS also reports a limit in the chain. Okta does not re-check the user when a grant is redeemed. In one test, Okta’s custom authorization server issued an access token 3 seconds after a user was removed, because the grant behind it had been minted before the removal. Each grant is single use and expires in 5 minutes, so the exposure is bounded, but it is a window a committee should know exists.
The posts list failures that AWS found while building the sample. A write check that accepted tokens with no group claim let a test user who belonged to no group create tasks. Before a registered-agent check was added, a plain token-exchange token issued to a service app created a task for another user. An agent runtime without a client allowlist admitted a second agent’s grant with an HTTP 200 and failed later, while the same runtime with the allowlist returned a 401. The AgentCore Python SDK also hid a workload token from the request headers where the first version looked for it, so the code fell back to a second workload identity on all 21 requests AWS checked.
AWS labels the code sample code for non-production use. The numbers come from AWS’s own test org, with Okta’s Integrator Free Plan, so they describe the mechanism and are not a benchmark of a production deployment.
Cost of the checks
The latency is small next to the model calls. AWS says AgentCore Identity adds about 0.6 seconds to a request that takes about 30 seconds end to end. Median figures from five runs: 216 milliseconds to exchange an ID token for a grant at Okta, and 508 milliseconds for AgentCore Identity to redeem the grant, including Okta’s response. A second tool call in the same request returned the stored token in a median of 58 milliseconds.
What Part 2 changes at scale
Part 1 wires each agent directly to each server and repeats the group check inside every server. Part 2 argues that this stops working at hundreds of agents and thousands of tools, and replaces it with one Gateway endpoint, one default-deny Cedar policy set evaluated before a tool runs, and an audit path in which Okta’s System Log events reach CloudWatch about 1 second after Okta publishes them. AWS also compares Cross App Access with per-user OAuth consent. For a GitHub target in its test, a stored user grant outlived a suspension in Okta and stayed until the grant was disconnected through the consent portal’s API. AWS’s advice is to choose per target application.
What it means for the buying committee
Revocation speed is a property that vendors rarely quote. The AWS tests give a committee a format for asking: how long after an administrator acts does a new request fail, how long do issued tokens live, and which actions queue behind a vendor’s own processing. The 86-minute queue on agent deactivation is the figure to check against an incident plan that relies on deactivating an agent.
Token lifetime is a policy choice the buyer makes. AWS set 5 minutes, and the posts say that setting bounds how long a revoked delegation keeps working. A shorter lifetime narrows that window and adds more calls to the identity provider, so the committee should set it with the identity team and the application owner together.
Policy placement matters as the agent count grows. AWS’s own comparison shows the same rule copied into many servers drifting, and its Gateway design puts that rule in one place that can be audited. Spend controls follow a similar pattern at other vendors. We reported on AWS’s per-session spend cap set outside the model, and on Salesforce’s spend limits and kill switch in Agent Fabric. In each case the control sits outside the model that the agent runs on.
Actions for CIOs and Chief AI Officers
Ask every agent vendor for its revocation timeline in writing, covering assignment removal, connection removal and deactivation, with both the time for new requests and the lifetime of issued tokens. Request the same table for each target application, because AWS found the two lanes revoke differently. Set the access token lifetime deliberately, and record it next to the incident runbook. Require a client allowlist on every agent endpoint, and a registered-agent check on every tool server that sits behind one. Test with a user who belongs to no group before go-live, since that case produced the clearest failure in AWS’s own build.
Source: AWS Machine Learning Blog
