Test where an agent token stops working
Measure when every receiving service rejects an agent’s credential after authority is withdrawn. Include cached checks, active sessions and queued work before accepting the access design.
Trace the interfaces between applications and records before changing a system.
Consider a constructed support-agent scenario. An administrator disables the agent after its owner leaves the team, but a worker retains a previously issued token. The customer-record tool accepts that token and completes a queued action. The identity change has succeeded while the service still permits an effect.
Measure how long the agent can act after the organisation withdraws its authority. The scenario is illustrative, not an incident report. A successful disable action at the identity provider is only one observation. Acceptance needs evidence from the services that can receive the credential and perform work.
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
Identify every receiving boundary where the credential can cause an effect, including retrieval, business systems, message senders and queued workers. For each, record the validation method, revocation signal, cache behaviour and owner. The inventory must reach the enforcement points, rather than stop at the identity provider or agent.
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.
Follow authority to the receiving service
Constructed withdrawal drill with a harmless test action.
Swipe or scroll for the full diagram →
Acceptance window
Record the last acceptance and first rejection, then compare with the operation’s tolerance.
- Issued token
- The worker receives authority before withdrawal. Do not retain the credential value in the trace.
- Authority withdrawn
- Record the identity or token withdrawal timestamp.
- Receiver checks
- Each tool applies its own expiry, introspection, cache or revocation mechanism.
- Queued work checked
- Release a pre-withdrawal job and check authority before an effect.
- Acceptance window
- Record the last acceptance and first rejection, then compare with the operation’s tolerance.
Representative method for this article, not a measured deployment result.
Operational sequence: Issued token, Authority withdrawn, Receiver checks, Queued work checked, Acceptance window. Each step has an accompanying explanation.
Reviewed 2026-10-02
Accept the observed cutoff
- 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.
- Decision owner
- Architecture and operation owners
- Population
- Every receiver and queued worker in the tested access path.
Representative method for this article, not a measured deployment result.
Baseline: Each receiving service accepts a harmless test action before withdrawal. Decision rule: Approve the access design only when the observed acceptance window fits the consequence of the action.
Reviewed 2026-10-02
Set a withdrawal tolerance for each operation against its consequences. Search, payment and message endpoints may need different limits. Record the observed acceptance window at each receiver and assess it against that tolerance. Sharing an agent credential does not justify applying a common risk threshold to every action.
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
Ask the supplier which services can still accept an issued credential after withdrawal, how long they can do so and how they learn about the change. Include direct calls, cached introspection, queued work and existing sessions. Require a controlled test and the records needed to confirm 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 architecture owner should review the last accepted action and first rejection at every relevant boundary. Compare those observations with the agreed tolerance and close or constrain untested paths. That evidence supports the access decision more directly than the completion time of an administrative ticket.