The AI agent lifecycle: onboarding, review and retirement

Six stages

Suspension deserves its own stage rather than being folded into retirement. In practice the common need is to stop an agent while a question is investigated, and teams that have only a delete path either hesitate to use it or lose state they later need.

Onboarding that captures what matters

Everything expensive about agent governance is cheap at onboarding. The owner is present, the purpose is fresh, and the scope is being decided anyway. Make these required fields rather than a later audit:

• A named individual owner. Not a team. A team cannot be accountable and does not trigger offboarding.
• Purpose in one sentence a non-engineer can evaluate. If it cannot be written, the scope is not understood well enough to grant.
• Reach, split read and write. This is the input to risk classification and it is the field most often recorded too coarsely.
• Delegation model. Autonomous, acting for a specific user, or both. Determines what the logs must carry.
• Expiry. Default to a bounded term with renewal on justification. Inverting the default, expiry automatic, extension requiring a reason, does more than any policy document.
• Human-in-the-loop conditions. Which actions require approval. Empty is a valid answer and one worth reviewing.

Six fields, minutes to complete, and none recoverable accurately in twelve months.

Access reviews over a population with no manager

Human access reviews work because a manager attests that a report still needs access. Agents have no manager, and the registered owner frequently does not know what the agent actually does. Asking them to certify produces rubber-stamping, which is worse than no review because it manufactures evidence.

Three review methods that work on this population:

1. Review by usage. Compare granted permissions to permissions exercised over ninety days, and propose removal of the difference. This turns a judgement into a diff, which owners can evaluate honestly. It is the single highest-yield review method for non-human identities.
2. Review by reach. Filter to agents that can write to production or cross a third-party boundary and review only those in depth. Blast radius is a better prioritiser than a uniform interval.
3. Review by exception. Anything that could not meet policy at provisioning, unbounded credential, borrowed identity, no human-in-the-loop on an irreversible action, carries an approver and a review date, and expires rather than persisting.

Whichever method you use, the evidence an assessor wants is not that the review happened but that revocations were executed. A review that decided to remove access and did not is a finding, not a control.

The retirement problem

Creating an agent has a requester and a deadline. Retiring one has neither, and the person who would know it is safe to remove has often moved on. This asymmetry is why agent populations only ever grow.

Four triggers that work, in order of reliability:

• Expiry. The credential ends and renewal requires justification. The only trigger that needs no human initiative, which is why it carries most of the load.
• Disuse. No authentication in a defined window. Suspend first, retire after a further window, so mistakes are recoverable.
• Owner departure. Requires the owner to be an individual and the leaver process to consult the registry. Both are common gaps.
• System decommission. The service the agent supported is gone. Reliable when it fires and easy to miss.

Evidence each stage should leave

Working backwards from what an assessor asks for under ISO/IEC 42001 or an internal audit: a dated registry export with owners and expiry; provisioning records showing scope granted against scope requested; action logs that reconstruct a delegation chain; review records showing reviewer, decision and executed change; and at least one revocation record with a measured effect time.

Five artefacts. If a stage in your lifecycle produces none of them, that stage is a description of intent rather than a control, and it will be treated as such.

Frequently asked questions

What are the stages of the AI agent lifecycle?

Six: proposal, where it is decided whether the agent should exist and what it will reach; provisioning, where identity and scoped authority are issued with an expiry; operation, where actions are logged with the delegation chain; review, where continued existence and reach are reassessed; suspension, where an agent is stopped pending investigation; and retirement, where credentials and downstream grants are permanently removed. Suspension warrants its own stage because teams with only a delete path hesitate to use it.

How do you run an access review for AI agents when there is no manager?

Review by usage rather than by attestation. Compare granted permissions to permissions actually exercised over ninety days and propose removal of the difference, which converts a judgement the owner cannot make into a diff they can evaluate. Supplement with review by reach, prioritising agents that write to production or cross a third-party boundary, and review by exception for anything that could not meet policy at provisioning.

Why do AI agents never get retired?

Because creation has a requester and a deadline while retirement has neither, and the person who would know it is safe to remove has often moved on. The trigger has to be constructed rather than assumed. Expiry is the only trigger requiring no human initiative, which is why credential lifetimes carry most of the retirement load in practice, with disuse thresholds, owner departure and system decommission as secondary triggers.

What should be captured when an agent is onboarded?

A named individual owner rather than a team, a one-sentence purpose a non-engineer can evaluate, reach split into read and write, the delegation model, an expiry with renewal on justification, and any human-in-the-loop conditions. All six take minutes at onboarding and none can be recovered accurately a year later, which is why capture at creation outperforms any retrospective exercise.

What is left behind when an agent is deleted incorrectly?

Downstream artefacts the agent created: third-party OAuth grants, registered webhooks, and API keys it minted. These frequently keep working after the primary identity is removed. Decommissioning has to enumerate what the agent created as well as what it was given, and this is the point at which retirement most often leaves a live remnant.