Deleting an agent from a catalogue is not the same as stopping its authority. The catalogue may forget the name while a connector still holds a credential, a downstream service still recognises a grant and a queued job is waiting patiently to become somebody’s problem.
Agent identity needs an ending. It also needs a controlled middle: changes of owner, purpose, environment and permitted actions. If the lifecycle only describes how to create an identity, it is an onboarding form pretending to be governance.
My test is practical. When we retire an agent, can we show which future actions it can no longer perform, when that becomes true and who deals with effects already committed? A green status labelled disabled does not answer any of those questions by itself.
One agent, several things to stop
Consider a fictional supplier-onboarding assistant called Intake. Its business owner is moving to another team. Intake has an identity in a registry, an OAuth grant for a document service, a refresh token in a connector and a queue of supplier invitations. Some invitations have already been sent. The team intends to retire it, not transfer its duties automatically.
There are several distinct objects here. The identity record says what the workload is and who is accountable for it. Credentials let a component demonstrate identity or present access. Grants describe permitted access. Running and queued work represent execution. Sent invitations are business effects. Changing one object does not necessarily change all the others.
NIST’s agent identity design tenets, published on 27 October 2026, propose a lifecycle distinct from human identities and short-lived, revocable authorisation. This is a design discussion, not a new certification or binding standard. The useful product implication is that an agent’s lifecycle cannot simply be borrowed from the employment status of the person who first configured it.
For Intake, removing the old owner’s account might break one route while leaving another untouched. Conversely, revoking a shared credential could disrupt unrelated workloads. A maintained agent identity record should expose those dependencies before the retirement ticket becomes urgent.
Ownership transfer is a new decision
A change of owner is not a search-and-replace operation on a name. The incoming owner needs to accept the purpose, remaining authority, unresolved exceptions and operating obligations. They may be happy to own document collection while rejecting the ability to send invitations without review.
I would preserve the old ownership interval and create a new effective interval, rather than rewrite the historical record. An action taken last Tuesday should remain attributable to the arrangement that existed last Tuesday. This is a proposed recordkeeping design, not a claim that one universal agent-identity schema already specifies it.
The transfer also needs an explicit decision about credentials and grants. Rotate or reissue where the security model requires it, reassess access and confirm the new operational contact. Do not quietly expand permissions because the replacement owner has a more senior title. Their personal authority and the workload’s authority are different things.
For our retirement scenario, the new team declines ownership. That is a valid outcome. Intake should not remain active merely because its shutdown is less convenient than forwarding another calendar invitation.
A revocation response is not the whole evidence
OAuth token revocation defines how a client can ask an authorisation server to invalidate a token. The specification recognises propagation delay, and related-token or grant revocation depends on server policy. A successful response also covers the case of an invalid token. It is not proof that every downstream business route has been exercised and denied.
The next question is how the resource learns that access has ended. Token introspection can provide current token state, but cached responses introduce a freshness trade-off. Shortening or removing a cache can reduce stale decisions while increasing dependency on the authorisation service. Locally validated credentials need an explicitly designed way to reflect revocation or a documented exposure until expiry.
There is no single universal switch hiding underneath these mechanisms. AWS’s role-session revocation documentation gives a concrete example: its described procedure denies permissions for sessions issued before a specified time. Later sessions are outside that cutoff. Stopping existing sessions and preventing new issuance therefore need separate attention. That is a provider-specific example, not a description of every identity system.
Measure the last possible action
For Intake, define a retirement time and a proposed acceptance target for each sensitive endpoint. The target is an internal requirement to be justified by risk, not a number borrowed from a protocol. Then attempt harmless test operations using credentials issued before retirement and through every supported connector path.
Record when the retirement decision was accepted, when each enforcement point applied it and the last time a test request was accepted. A rejected call against one endpoint does not establish rejection at another. If one path cannot be tested, label that gap rather than averaging it into a comforting percentage.
Also test new credential acquisition. A workload whose old token is revoked but which can immediately obtain a fresh one has not been retired. Disable the relevant issuance or delegation route according to the actual platform, then verify the result. The distinction sounds obvious until a dashboard presents both operations under one button.
This article is about lifecycle closure, not how a paused task resumes. The separate checkpoint-permission article covers that execution problem. Here the question is broader: after retirement, what remains able to create work, receive authority or reach a tool?
Queued work needs an owner too
Intake’s pending invitations need an explicit disposition. Cancel those that are no longer authorised, quarantine those that require review and identify any downstream service that has already accepted work on its own terms. Stopping the originating process may not cancel a job already handed to another system.
Already-sent invitations are different again. Credential revocation cannot unsend them. If the business needs withdrawal or correction, that is a separate compensating action with its own authority and evidence. We should not promise rollback when the system can only prevent the next request.
The trade-off is between immediate containment and orderly completion. A suspected compromise may justify stopping sensitive work quickly, even if operations become inconvenient. Planned retirement may allow a controlled drain of low-risk work under explicit, time-bounded authority. Those are different policies. Neither should emerge accidentally from whichever queue happened to empty first.
Keep enough evidence to reconstruct the transition without retaining unnecessary secrets. Safe identifiers, policy versions, decision times, test results and the disposition of outstanding work are more useful than a folder full of raw tokens. The evidence-portability approach helps preserve the relationships when systems change later.
An agent is retired when its remaining authority and unfinished effects have been accounted for. The name disappearing from the interface is merely the easiest part to screenshot.
