Most organisations govern AI agents at one moment, the go-live review, and then lose track of them as models are swapped, tools are added, owners move on and agents quietly stop being used. AI agent lifecycle management is the set of stages, decision gates and owners that carry an agent from the first request to its retirement, so that every material change is reviewed and nothing outlives its purpose. This guide is the hub for that lifecycle on NHI Mgmt Group: it defines the stages and gates, who decides at each one, what counts as a material change, and how to measure whether the lifecycle is working. The detailed work at each stage lives in dedicated pages, linked rather than repeated here: onboarding requests, deployment controls, credential rotation, recertification and decommissioning. It is written for AI governance leads, IAM and platform teams, and security architects designing an operating model for agents.
Key takeaways
- Govern the agent, not the launch. An agent changes more after go-live than before it: the lifecycle needs gates at change, review and retirement as well as at approval.
- Eight stages, five gates. Request, design and build, approve, deploy, operate, change, recertify and retire, with a recorded decision at intake, go-live, material change, recertification and retirement.
- A named human sponsor at every stage. Accountability fails when the creator leaves; sponsorship must transfer automatically, and an agent with no sponsor should be suspended.
- Define material change in advance. A new tool, broader scope, new data class, model change or higher autonomy should reopen the approval gate; prompt wording fixes usually should not.
- Expiry by default. Give every agent and every access assignment an end date, so that inaction leads to retirement rather than to an orphaned agent.
The lifecycle at a glance
The NIST AI RMF Playbook frames the governance side of this: GOVERN 1.6 calls for an inventory of AI systems with a named team responsible for it, GOVERN 1.7 for decommissioning policies, and MANAGE 2.4 for assigned responsibilities and mechanisms to supersede, disengage or deactivate AI systems whose outcomes are inconsistent with intended use. The table turns that into stages for agents specifically.
| Stage | Purpose | Gate and decision | Decided by | Detail on |
|---|---|---|---|---|
| 1. Request | Capture purpose, owner, tools, data classes, credential type and expiry before anything is built | Intake gate: proceed, redesign or reject; assign risk tier | AI governance lead | AI Agent Onboarding Request Template |
| 2. Design and build | Threat model, least-privilege design, credential pattern, approval points | None; design review feeds gate 3 | Agent owner, security architect | AI Agent Threat Modelling Guide |
| 3. Approve | Confirm controls exist and are tested | Go-live gate: approve, approve with conditions, or reject | Approvers set by risk tier | AI Agent Deployment Checklist |
| 4. Deploy | Create identity, register, issue credentials, enable monitoring | None; registration is a precondition | Platform team | AI agent registry |
| 5. Operate | Monitor behaviour, rotate credentials, respond to alerts | Kill switch criteria (not a gate, a standing authority) | Agent owner, SOC | Agent Controls and Monitoring Guide |
| 6. Change | Review material changes before they reach production | Change gate: standard, normal or re-approval | Change board or delegated approver | This guide, below |
| 7. Recertify | Confirm the agent is still needed, owned and right-sized | Review gate: keep, reduce, or retire | Sponsor, resource owners | Agent Identity Recertification |
| 8. Retire | Remove every grant, tool, trigger and data store | Retirement sign-off | Sponsor, security team | AI Agent Decommissioning Checklist |
Credential issue, rotation and revocation run underneath stages 4 to 8 on their own cadence; see the AI Agent Credential Lifecycle and Rotation Guide. The generic workflow for non-human identities, which this agent lifecycle extends, is in the NHI Lifecycle Automation Guide.
Roles and accountability
Agents need two kinds of owner: someone accountable for why the agent exists, and someone responsible for how it is configured. Platforms are starting to model this directly. Microsoft Entra Agent ID, for example, requires at least one sponsor (business accountability) for every agent identity and blueprint, with an optional owner (technical administration) and manager. Sponsors can disable or soft-delete an agent but cannot re-enable or restore one; owners can. Whatever the platform, define the roles in your operating model first and map them onto platform roles second.
| Activity | Sponsor | Agent owner | AI governance lead | Security team | Resource or data owner |
|---|---|---|---|---|---|
| Raise request and justify purpose | A | R | C | I | C |
| Assign risk tier at intake | C | C | A/R | C | I |
| Go-live approval | A | R | C | R (Tier 2 and above) | R for systems written to |
| Material change approval | A | R | C | C | C |
| Recertification decision | A/R | C | I | I | R for access to their resource |
| Emergency stop | I | R | I | A/R | I |
| Retirement sign-off | A | R | I | R | I |
R responsible, A accountable, C consulted, I informed. The emergency stop sits with security because waiting for a sponsor in an incident costs time; see the AI Agent Kill Switch and Containment Guide.
- Sponsor succession: when a sponsor changes role or leaves, transfer sponsorship before their account is disabled. Microsoft Entra ID Governance documents Lifecycle Workflows tasks that can move sponsorship to the departing sponsor's manager and notify co-sponsors; elsewhere, add the sponsor's agents to the leaver checklist in your joiner, mover and leaver process.
- Orphan rule: an agent with no valid sponsor for [10 working days] is suspended, and retired at the next recertification if no one claims it. OWASP's Non-Human Identities Top 10 lists orphaned identities, whose owner has left with no successor, as a cause of NHI1 Improper Offboarding.
Designing the gates
A gate is useful only if it has defined inputs, a small set of possible outcomes and a record. Keep the number of gates fixed and vary the depth by risk tier, rather than inventing extra reviews for risky agents.
| Gate | Inputs | Possible outcomes | Record kept |
|---|---|---|---|
| Intake | Onboarding request, use-case approval, proposed tools and data classes | Proceed with tier, redesign, reject, redirect to an existing agent | Request and decision in the registry |
| Go-live | Completed deployment checklist, test and red team results, permission matrix | Approve, approve with dated conditions, reject | Approval, conditions and expiry date |
| Material change | Change description, diff of tools, scopes, data and model, re-run of affected tests | Standard change, normal change, full re-approval | Change ticket linked to the registry record |
| Recertification | Usage evidence, granted versus used permissions, incidents, sponsor attestation | Keep, reduce access, retire | Review decision and next review date |
| Retirement | Completed decommissioning checklist and verification results | Signed off, blocked (with owner and date) | Retired status and evidence pack |
Tie the depth to the agent's risk tier. A read-only Tier 1 agent can pass go-live with owner and reviewer sign-off; a Tier 3 agent that moves money, sends external communications or changes access needs the full set of approvers. The tier definitions and per-tier checks are in the deployment checklist; the action-level approvals that run inside the operate stage are covered in the AI Agent Action Approvals and Spending Limits Guide.
Change control: what counts as material
Change is the stage most lifecycle programmes leave undefined, and it is where agents drift furthest from what was approved. Agents can change through configuration alone, with no code release, so change control must watch the agent's configuration, not just its repository. Agree the classification below before the first agent goes live, and publish it to builders.
| Change | Typical class | Why |
|---|---|---|
| New tool, plugin, skill or MCP server | Re-approval | Adds actions the agent can take; reopens tool misuse and supply chain risk |
| Broader OAuth scope, new role or new data class | Re-approval | Changes the blast radius on which the tier was set |
| Higher autonomy (removing a human approval step, adding a schedule) | Re-approval | Removes a compensating control |
| Model or model version change | Normal change with regression tests | Behaviour, refusal patterns and tool-calling accuracy can shift |
| New user population or external exposure | Normal change; re-approval if external | Changes who can reach the agent and inject instructions |
| System prompt or instruction rewrite | Normal change | Can weaken guardrails written in instructions |
| Prompt wording fix, label change, narrower scope | Standard change | Reduces or does not change capability |
Two practical controls make this enforceable. First, record a configuration fingerprint (tools, scopes, model, autonomy settings) in the registry at approval and alert on any difference. Second, deny registration of new tool connections outside the change process at the gateway or policy layer, so an unapproved tool fails closed. Gradual expansion of access between reviews is covered in Agent Permission Drift, and configuration tampering as an attack in MITRE ATLAS AML.T0081 Modify AI Agent Configuration.
Expiry, recertification and retirement triggers
The single most effective lifecycle control is an end date. If an agent and its access expire unless someone acts, abandoned agents retire themselves; if they persist unless someone acts, they accumulate. Microsoft Entra ID Governance access packages show the pattern: when an agent identity's assignment has an expiry date, its sponsor is notified as the date approaches, may request an extension that can trigger fresh approval, and if the sponsor does nothing the assignment expires and the agent loses access.
- Time-based: recertify on a cadence by tier, for example [quarterly] for Tier 3, [six-monthly] for Tier 2 and [annually] for Tier 1. These are NHI Mgmt Group suggestions, not values from a standard.
- Event-based: sponsor leaves, material change, incident involving the agent, vendor breach notice for a tool or model provider, or no activity for [90 days].
- Outcome-based: MANAGE 2.4 in the NIST AI RMF ties deactivation to outcomes inconsistent with intended use, so repeated guardrail violations or failed evaluations should open a retirement decision, not just a ticket.
The review mechanics, evidence and platform options are in Agent Identity Recertification, and the retirement run sheet in the AI Agent Decommissioning Checklist. The 2026 Vercel Context.ai OAuth breach shows the cost of the missing end date: a broad OAuth grant to an AI application, connected by one employee and never reviewed, remained valid long after anyone needed it and became the attacker's way in.
Implementing the lifecycle
- Inventory first. Find the agents you already have, across agent platforms, low-code builders and SaaS copilots, and create registry records for them. Use the platform guides such as How to inventory AI agents in Microsoft 365 and the Shadow AI Discovery Guide.
- Assign sponsors and expiry dates to existing agents. Treat every unowned agent as a recertification case; retire those no one claims.
- Publish the change classification and the risk tiers, so builders know which changes reopen approval.
- Make the registry the control point. Credentials are issued and tool connections allowed only for registered, approved, unexpired agents. Start in report-only mode, alerting on unregistered agents, then enforce once the inventory is reconciled.
- Wire triggers to tickets. HR leaver events, failed recertifications, inactivity and configuration drift should open the right gate automatically.
- Pilot with one platform and one business unit, measure gate cycle times, then extend. Roll back an enforcement step by returning it to report-only mode rather than removing it.
Decision guidance
| Question | Option A | Option B | Choose A when |
|---|---|---|---|
| Where does the lifecycle live? | Extend existing IGA and change management | Dedicated agent registry and workflow | Most agents run on platforms your IGA already governs and agent numbers are modest |
| Who approves changes? | Central change board | Delegated approvers per business unit with central policy | Fewer than a few dozen agents, or most agents are Tier 3 |
| Expiry model | Fixed term per agent (for example 12 months) | Expiry per access assignment | Platforms cannot expire individual grants; otherwise expire assignments too |
| Vendor agents | Same lifecycle as in-house agents | Third-party risk process with agent checks added | The vendor agent holds delegated access inside your tenant |
Small organisations can run the whole lifecycle with a registry spreadsheet, one approver group and a quarterly review meeting, provided every agent has a sponsor and an end date. Large organisations need the registry integrated with identity providers and agent platforms so that gates are enforced, not just recorded, and a federated model in which business units approve within central policy. For the governance model above the lifecycle see the Agent Governance and Risk Guide.
Detection and measurement
Monitor the lifecycle itself, not just agent behaviour. Useful signals are registry records whose configuration fingerprint differs from the approved one, agent identities authenticating with no registry record, sponsors whose accounts are disabled, assignments past their end date that are still active, and any authentication by a retired agent identity.
- Coverage: percentage of discovered agents with a registry record, sponsor and expiry date (target 100 per cent).
- Change discipline: material changes detected by drift monitoring that had no change ticket, per quarter (target zero).
- Review health: percentage of recertifications completed on time, and percentage that reduced access or retired the agent.
- Orphans: number of agents without a valid sponsor for more than [10 working days].
- Retirement speed: median days from retirement decision to signed-off decommission.
- Gate cycle time: median days from request to go-live by tier, so governance does not push builders to shadow agents.
Framework mapping
| Lifecycle element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Other |
|---|---|---|---|
| Stages and gates | SA-3 System Development Life Cycle | ID.AM-08 | NIST AI RMF GOVERN 1.7, MANAGE 4.1 |
| Roles and sponsorship | AC-2 Account Management | GV.RR-02 | OWASP NHI1:2025 Improper Offboarding |
| Registry | CM-8 System Component Inventory, PM-5 System Inventory | ID.AM-02 | NIST AI RMF GOVERN 1.6 |
| Change control | CM-3 Configuration Change Control, CM-4 Impact Analyses | PR.PS-01 | OWASP ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse |
| Identity and credentials | IA-4 Identifier Management, IA-5 Authenticator Management | PR.AA-01 | ATT&CK T1078.004 Cloud Accounts |
| Recertification and expiry | AC-2(3) Disable Accounts, AC-6(7) Review of User Privileges | PR.AA-05 | OWASP ASI10 Rogue Agents |
| Lifecycle monitoring | AC-2 | DE.CM-03 | NIST AI RMF MANAGE 2.4 |
Common failure patterns
- Go-live is the only gate: the agent approved in spring is not the agent running in autumn, after three new tools and a model change that no one reviewed.
- Creator as permanent owner: the developer who built the agent is recorded as owner by default, moves team, and the agent becomes orphaned with live access.
- No end date: pilots become permanent because nothing forces a decision, and broad grants stay valid long after use stops.
- Change control watches code only: tool connections, scopes and autonomy settings change in a platform console with no release, so the change process never sees them.
- Retirement equals switching off: the runtime is stopped but delegated grants, schedules and memory stores remain, ready to be reused or stolen.
- Governance too slow to use: a long approval queue pushes teams to build unregistered agents, which then sit outside every later gate.
Practitioner checklist
- Publish the eight stages and five gates, with the decision owner and record for each.
- Require a named sponsor and an expiry date for every agent, including vendor agents with access to your tenant.
- Automate sponsor transfer on leaver and mover events, and suspend agents left without a sponsor.
- Agree and publish the material change classification before the next agent goes live.
- Store an approved configuration fingerprint in the registry and alert on drift.
- Set recertification cadence by risk tier and add event triggers for incidents, inactivity and sponsor changes.
- Make retirement a gate with a checklist and verification, not a runtime stop.
- Report the six lifecycle metrics to the AI governance forum each quarter.
Standards and references
- NIST: AI RMF Playbook, Govern (GOVERN 1.6 and 1.7)
- NIST: AI RMF Playbook, Manage (MANAGE 2.4 and 4.1)
- OWASP: Non-Human Identities Top 10, NHI1:2025 Improper Offboarding
- OWASP: Secure Agent Playbook, agentic AI risk assessment (Top 10 for Agentic Applications)
- Microsoft: Owners, sponsors and managers for agent identities
- Microsoft: Governing agent identities with access packages
Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide, AI Agent Registry vs CMDB vs IGA, Agentic AI Security Policy Template, AI Agent Autonomy Levels Framework.