Okta and AWS show an agent acting for a named user. Their tests show how long revoking it really takes

Most writing about agent identity ends when the token is issued. A new reference design from AWS and Okta goes further: its authors tried to take access away and timed what happened.

The design: two planes, three tokens

The post pairs Okta Cross App Access (XAA) with Amazon Bedrock AgentCore Identity. Okta acts as the governance plane: it decides which agent may act for which user against which application. AgentCore Identity is the execution plane: it holds credentials and mints short-lived tokens.

A request passes through three tokens. The user signs in and gets an ID token. Okta exchanges it for an ID-JAG, a single-use grant valid for five minutes and issued to one specific agent. AgentCore redeems that grant for a resource access token that names both the user and the agent, and carries the user’s groups. The receiving service can therefore tell who asked, which agent acted, and what the user is allowed to do.

The authors tested the edges: a grant issued to a different agent was rejected, as were a grant near expiry, a reused grant and a request for scopes outside the configured connection. Compared with plain OAuth token exchange, XAA adds an actor claim, enforces scopes approved by an administrator and denies users who were never assigned to the agent. The identity steps added about 0.6 seconds to a request that took about 30 seconds end to end.

What revocation actually looks like

Then they removed access, and measured.

How long after revocation can an agent still act?

ImmediatelyOver an hour

1. About 1 secondOkta refuses new requests for a user whose assignment was removed
2. Up to 5 minutesTokens already issued keep working until they expire
3. 86 minutesAn agent deactivation queued in Okta's beta AI agent API

Each number teaches something different. Removing a user works fast for new requests. Tokens in flight keep working for their lifetime, so the token lifetime is the real floor for stopping a delegated action. Okta does not check the user again when a grant is redeemed. And deactivating the agent itself, in a beta API, took 86 minutes to take effect in the authors’ test.

The authors are careful to say these results reflect their configuration, and that the sample code is not for production. That caution is fair. The value is not the exact numbers but the habit of measuring them.

Put the numbers in your incident plan

We argued that stopping an agent is the easy part of an incident only if the plan exists before go-live. This post supplies the inputs such a plan needs:

• Know your three clocks. Time to block new requests, maximum lifetime of issued tokens, and time to disable the agent identity itself. Measure them in your own tenant.
• Set token lifetimes by the damage window you accept. Five minutes is reasonable for reading data. For agents that can move money or change records, shorter lifetimes or a check at the resource are worth the latency.
• Have a faster switch than the identity provider. If deactivating an agent can queue, keep a block at the gateway or the resource server that takes effect immediately.
• Log both names. Tokens that carry the user and the agent make incident review possible. Make sure the receiving systems record both, not only the user.

Part 2 of the series will add AgentCore Gateway with Cedar policies, a second agent on Amazon EKS and a CloudWatch audit trail. Part 1 already makes the main point: delegated identity for agents is not finished when the token is issued. It is finished when you know how fast you can take it back.