Test where an agent token stops working

A support agent has been given access to a customer record system. Its owner leaves the team, so the identity administrator disables the agent and closes the ticket. A worker still holds an access token issued before that change. The customer record tool accepts it, and an action waiting in the queue completes. The ticket and the receiving service disagree about whether access has ended.

This is a constructed scenario, not a report of an incident. It exposes a decision that matters before deployment: how long can an agent still act after the organisation withdraws its authority? A successful disable action at the identity provider does not answer it. The answer lies along the whole path from the issuer to the last service that can cause an effect.

The earlier article on agent identities asks whose authority an agent should carry and how narrowly it should be scoped. This article starts after that choice. Even a well-scoped, short-lived token has a period during which it can be presented, and each tool has its own way of deciding whether to accept it.

Follow the issued token

An identity provider can stop issuing new tokens or reject a refresh request. Neither action necessarily invalidates an access token that a worker has already received. A tool that validates a signed token locally can accept it until its expiry if it has no current revocation signal. A tool that asks an authorisation server whether a token is active has a different boundary, but its answer may be cached.

The final NIST IR 8587 states that immediate global revocation is not always possible with stateless tokens before expiry. It recommends short validity periods, ways to propagate revocation status to relying parties, and clear disclosure of a provider’s revocation methods. Its agent section says to apply the guidance where agents use signed tokens to reach systems, data, tools or APIs. The report is scoped to US federal environments. It offers a useful design question for an enterprise elsewhere, not a general legal duty.

RFC 7662 describes token introspection and explicitly warns that cached active responses can create a window in which a revoked token remains usable. Removing the cache may narrow that window while increasing calls to the authorisation server. Shortening token lifetime has a similar availability and load cost because clients must obtain credentials more often. Neither choice should be made from the identity console alone.

There is also a queue boundary. A job authorised while a token was valid may be picked up after withdrawal. If the receiver accepts an old authorisation result without checking again before the effect, the queue can outlive the permission. This differs from the stale approval problem, where the business record changed after a person approved a particular action. Here the authority to act has ended, even if the record itself is unchanged.

Measure withdrawal at the receiving services

The architecture review should name every place where the agent’s credential can produce an effect: the model gateway, retrieval service, customer system, message sender and any worker that resumes queued tasks. Record which component validates the token, whether it queries current status, whether it caches the answer, and who can change that behaviour. An inventory that stops at the agent or the identity provider misses the enforcement points.

Run a withdrawal drill in a controlled environment with a test identity and a harmless action at each receiving service. Confirm that access succeeds before withdrawal, then disable the identity, revoke the relevant session or token, and repeat the action until every receiver rejects it. Include a job queued before withdrawal but released afterwards. Record the withdrawal timestamp, the last accepted action, the first rejection, and the token’s stated expiry. Do not log the token itself. NIST’s logging guidance calls for token events and context while excluding token values from logs.

Baseline

Each receiving service accepts a harmless test action before withdrawal.

Outcome

The last accepted action and first rejection after withdrawal, recorded for every receiver and queued worker.

Guardrails

No production customer effect, no credential value in logs, and no untested fallback path.

Decision rule

Approve the access design only when the observed acceptance window fits the consequence of the action.

The result may differ by tool. A customer search endpoint might continue to accept a token briefly while a payment or message endpoint rejects it at once. That is a design choice only if the organisation has measured it and connected it to the harm a delayed withdrawal could cause. A common agent credential presented to both services should not silently give them the same risk tolerance.

For a sensitive effect, put the current authorisation check at the receiving boundary, or make the receiver consume a revocation signal and terminate active sessions. Define what happens if that check is unavailable. For a lower-risk operation, a short token lifetime may be acceptable, provided the expiry is tested rather than assumed. Also stop queued work when a delegation ends, or require the worker to obtain fresh authority before executing it. A retry with the same operation ID prevents duplicate effects, but does not restore a withdrawn permission.

Ask suppliers for the end of access

The procurement question is precise: after a customer revokes a token or disables an agent, which of your services can still accept an issued credential, for how long, and by which mechanism will they learn of the withdrawal? Ask whether the answer changes for direct API calls, cached introspection, queued work and sessions already open. Request a test method and the logs that will show each rejection.

A supplier may offer an OAuth revocation endpoint without making every resource server consult it for every request. The presence of an endpoint is therefore evidence of a control surface, not evidence of an end-to-end cutoff. The buyer needs the receiving services’ behaviour. Where a supplier cannot state or test it, the architecture should limit what that integration may do.

What the drill cannot establish

This method does not make stolen tokens harmless. Detection can be late, a token can be used before anybody withdraws it, and a valid agent may take an unwanted action within its scope. Sender-constrained tokens, monitoring and conditional approval address different parts of that problem. The withdrawal drill answers the narrower question of how the system behaves once the organisation decides the agent must stop.

The architect signing off the next agent integration should ask for the last accepted action, not the time a disable ticket was closed. That one observation turns revocation from a promise in an identity diagram into a property of the system that will actually receive the call.