What Is Agent Lifecycle Management?

Overview

Agent lifecycle management is the practice of governing an AI agent from the moment it's proposed through development, approval, production operation, ongoing change, and eventual retirement. It's less a framework than an answer to one recurring question: how does an enterprise make sure an agent is properly governed at every point in its life, not just the day someone signed off on it?

The reason this matters is that agents don't hold still. Tools change. Prompts get rewritten. The model gets swapped. Permissions expand a little at a time. Owners move teams. A weekend experiment becomes a business-critical workflow that nobody formally approved as one.

Two things have changed since the concept got its name. Regulators now attach specific obligations to specific lifecycle moments, with retention periods and reporting clocks. And vendors have started shipping agent identity objects whose expected lifetime is measured in minutes, which breaks any lifecycle built on the assumption of a quarterly review.

Why It Matters

Consider how quietly scope expands. A data and analytics agent starts with read-only access to a reporting warehouse, then gets write access so it can publish dashboards directly. A procurement assistant begins by drafting purchase requests and later gets wired to submit them to vendors. An HR onboarding agent launches against a sandbox of test records and ends up reading live employee files. None of these changes is inherently wrong. Each is a meaningful shift in risk that should be seen, not absorbed silently.

A lifecycle turns each of these into a governed event, which is what lets the organization keep answering questions that otherwise decay:

• What was this agent originally approved to do, and does that still match what it does?
• Who owns it now, not who built it eighteen months ago?
• What access and credentials does it hold, and was the most recent grant reviewed?
• Is it still in active use, or has it become an idle path into sensitive systems?

NIST's AI Risk Management Framework asks for the same things in its GOVERN function, and the phrasing sets the bar higher than most internal programmes do. GOVERN 1.6 asks that "mechanisms are in place to inventory AI systems", GOVERN 1.5 that "ongoing monitoring and periodic review of the risk management process and its outcomes are planned", and GOVERN 1.7 that "processes and procedures are in place for decommissioning and phasing out AI systems safely". Decommissioning gets its own subcategory, which tells you how often it gets skipped.

The Lifecycle Stages

A practical lifecycle moves through six stages, each with a purpose, an owner and a handoff. How deep the review runs at each should scale with how much access and autonomy the agent holds.

Figure 1 — The six stages and what moves an agent between them. The loop back into Review and Approval is the part most programmes skip, and the part that catches drift before it compounds.

The useful discipline is deciding in advance what each gate produces, because a stage that produces no artefact is a meeting rather than a control.

Table 1 — The six gates, what each one has to produce, and the long-standing access control it maps to.

1-2. Proposal and Development

Everything begins with intent. A finance team wants an agent to reconcile vendor invoices against purchase orders. The goal at this stage is to capture the basics before any code gets written: the problem, the expected business owner, the systems it will touch, and a rough risk tier. A lightweight proposal prevents the most common failure mode in agent programmes, which is agents that exist before anyone decided they should.

Development's defining principle is containment. Experimentation belongs in a low-risk environment with limited, ideally synthetic data and tightly scoped access. The invoice-reconciliation agent works against a sandbox ledger, not the production accounts-payable system. That's what makes fast iteration safe: prompts change, tools get swapped, models get replaced, and a mistake costs a sandbox reset.

The thing to resist is issuing a production credential "just to test the integration". That decision turns a development-stage agent into an unreviewed production one, and no later gate catches it, because from the outside the agent now looks approved.

3. Review and Approval

This is the gate between experiment and production, and it does the heaviest lifting. Review weighs the agent against the dimensions that determine real-world risk:

• Purpose: is what the agent does well-defined and bounded?
• Owner: is there a named, accountable owner who'll answer for its behaviour?
• Permissions: does it have the least access required, and nothing more?
• Credentials: does it have its own scoped identity rather than a borrowed human account?
• Risk: what's the blast radius if it behaves incorrectly, and what stops a high-impact action?

Two of those have external anchors worth citing in a review template. On the owner question, the EU AI Act requires deployers of high-risk systems to "assign human oversight to natural persons who have the necessary competence, training and authority", which is a higher bar than a name in a spreadsheet. On the credential question, SP 800-53 AC-2 asks organizations to "assign account managers" and to require approvals "for requests to create accounts".

Approval is the moment the agent gets registered and permitted to operate under defined conditions, and those conditions are the point. An agent approved to draft messages is not the same agent once it can send them. The approval record becomes the baseline every future change is measured against, which is only true if the scope is written down in a form a diff can be taken against.

4. Production

Production isn't a destination. It's a stage with ongoing obligations, and for high-risk systems several of them are statutory.

Providers must "establish and document a post-market monitoring system" under Article 72 of the AI Act, and that system has to "actively and systematically collect, document and analyse relevant data" on performance throughout the system's lifetime. Deployers have the retention duty: Article 26(6) requires keeping the logs a high-risk system automatically generates "for a period appropriate to the intended purpose ... of at least six months", while Article 18 keeps the provider's technical and quality-management documentation for "a period ending 10 years after the high-risk AI system has been placed on the market or put into service". A programme that picks one retention setting for both gets one of them wrong.

The dates moved, so check your plan against the current text. After the Digital Omnibus amendments entered into force on 27 July 2026, the European Commission's framework page puts Annex III high-risk use cases at "2 December 2027" and product-embedded Annex I systems at "2 August 2028".

We think periodic review is the part teams skip and the part that pays off most. A quarterly check asking whether each production agent is still in use, still owned, and still inside its approved scope is what prevents drift from becoming a discovered incident. AC-2(4) has the cheap way to make that review possible: "automatically audit account creation, modification, enabling, disabling, and removal actions", so the review reads a log rather than interviewing people.

5. Change Management

Agents change constantly, and change is where governed systems slip back into ungoverned ones. Updates to an agent's tools, permissions, model, prompt or behaviour should be reviewed against the original approval, not applied silently.

A marketing agent approved to draft campaign copy and pull engagement metrics is a different risk profile the day someone connects it to the system that publishes posts and spends ad budget. The change may be reasonable. The problem is it happening with no review, no sign-off, and no updated record.

There is now a legal edge to this that didn't exist when most change processes were written. Article 25(1) of the AI Act says a deployer is "considered to be a provider" of a high-risk system if it puts its own name on the system, makes a substantial modification, or modifies the intended purpose so the system becomes high-risk. Article 3(23) defines substantial modification as a change "not foreseen or planned in the initial conformity assessment carried out by the provider". Swapping the model, granting a write scope, or pointing the agent at a new business process can meet that description, and the consequence is inheriting the provider's obligations.

# A reviewable change record, not a silent edit
agent: campaign-assistant
change_type: permission_grant
before:
  scope: [analytics.read, content.draft]
after:
  scope: [analytics.read, content.draft, content.publish, adspend.write]
requested_by: marketing-ops
reviewed_by: platform-governance
substantial_modification_assessed: true   # Art. 3(23) check, recorded either way
status: approved_with_spend_cap

6. Decommissioning

The final stage is the most neglected, and the order of operations matters more than people expect. Google's own IAM guidance is blunt about the first step: "Before deleting a service account, disable the service account to make sure it isn't necessary. Disabled service accounts can be re-enabled if they are still in use." Disable is reversible. Delete is where the surprises live.

Figure 2 — Decommissioning in the order that lets you back out. Revocation at the provider is a separate act from deleting the local identity.

Two traps are worth naming. The first is assuming a recreated identity inherits what the old one had: Google warns that "role bindings that existed for a deleted service account do not apply to a new service account that uses the same email address", and recommends "using a new, unique name for every service account". The second is treating deletion as revocation. Removing a credential from your own store does not invalidate a grant held at the identity provider.

Then leave the audit trail alone. The agent goes; the logs stay for whatever the retention rule demands. Clean decommissioning is what keeps the population honest: every credential that exists maps to an agent someone is still responsible for. Offboarding earns separate treatment rather than a bullet list here.

When the Lifecycle Is Minutes

The six-stage model assumes an agent that lives long enough to be reviewed. A growing share of agents don't. Microsoft's own framing of why agent identities exist rather than reusing service principals is explicit about the timescale: service principals "carry the expectation of long-term stability, known ownership, and managed lifecycle", whereas an agent "might exist for minutes during a specific task, or might be created and destroyed thousands of times per day as part of an automated workflow".

You cannot run a quarterly review on something that lived for ninety seconds. What you can govern is the template it was minted from. Entra's model introduces four object types, an agent identity blueprint, a blueprint principal, an agent identity and an agent user, with permissions inherited from the blueprint, so the review lands on the blueprint and the instances inherit the outcome. The stated goal is retiring agents "without leaving orphaned credentials or permission assignments behind".

The other mechanism worth copying is expiry as a default. Access packages assigned to an agent identity carry an end date; as it approaches the sponsor is notified and can request an extension, and if the sponsor does nothing "the access package assignment automatically expires on its end date, and the agent identity loses access". That inverts the usual failure. Access lapses unless someone argues for it, rather than persisting until someone remembers to remove it.

Table 2 — Three lifecycle shapes. Applying the first row's cadence to the third row's agents is how programmes end up reviewing nothing.

The Record That Travels

Lifecycle management doesn't need heavyweight process to work. The programmes that hold up treat the lifecycle as metadata that travels with the agent, captured once and updated as it moves between stages.

agent: invoice-reconciler
stage: production
owner: finance-ap-team
sponsor_successor: manager_of_record     # who inherits if the owner leaves
approved_scope: [erp.invoices.read, erp.po.read]
last_review: 2026-05-12
next_review: 2026-08-12
last_used: 2026-07-01T04:12:00Z          # the field that finds idle agents
credentials: scoped-service-identity-4471
log_retention: 6mo                        # deployer floor for a high-risk system

Two fields do more work than the rest. last_used is how you find the idle agent that still holds live access, which is the condition AC-2(3) tells you to disable. sponsor_successor is how the record survives an offboarding. Microsoft's agent registry surfaces the failure that field prevents as a first-class tile, "Agents without owners", arising because "shared agents can become ownerless when you delete the user who created them from the organization". The remediation offered at that point is blocking or deleting the agent, which shows how few options remain.

Make the record queryable and the governance questions become lookups rather than projects. The same registry exports more than thirty fields per agent, including status, date created, last modified, version, owner and platform, and exposes the inventory through an API. That is the bar: a list you can filter by review date, by owner, and by last use.

The key shift is to stop treating approval as an event and start treating it as a state that has to be maintained. An agent isn't approved forever. It's approved as of its last review, for the scope it currently holds.

Where Fabriq Fits

Agentic Fabriq covers the middle of this lifecycle. Agents are registered, scoped and then activated with a one-time secret and an in-console test, which gives the transition into production an artefact rather than a conversation. Access is default-deny across org, team and member, and an agent's effective tool list is the intersection of the user's scopes and the agent's, so narrowing a user's access narrows every agent acting for them. Credentials sit in a vault, get attached server-side at the moment of the call, and refresh automatically with last-used tracking.

It does not reach into the provider on your behalf. Clearing a vault copy is not revoking a grant upstream, so provider-side revocation stays on your decommissioning checklist as its own step.

Frequently Asked Questions

What are the stages of the AI agent lifecycle? Proposal, development, review and approval, production, change management, and decommissioning. The stage count matters less than the rule that every transition produces an artefact and that scope-expanding changes route back through the approval gate.

How is this different from MLOps or model lifecycle management? Model lifecycle management governs a trained artefact: versions, evaluation, rollout. Agent lifecycle management governs an identity with access, so the questions are scope, credentials, ownership and revocation. The same agent can outlive several models.

How often should agents be reviewed? Pick a frequency and write it down, which is what NIST's GOVERN 1.5 asks for, "including determining the frequency of periodic review". Quarterly is a reasonable default for long-lived agents, on every scope change regardless, and per blueprint rather than per instance for agents minted at machine speed.

What happens if we skip decommissioning? You accumulate credentials with no owner, which is the exact condition AC-2(3) says to disable accounts for, "no longer associated with a user or individual", and the one an attacker prefers, because nobody watches a path nobody remembers.

Does a permission change need re-approval? If it expands access or autonomy, yes. Under the AI Act it may need more than that: a substantial modification to a high-risk system can move you into the provider's obligations under Article 25(1), so record the assessment even when the answer is no.

How long do we have to keep agent logs? For a high-risk system, a deployer keeps the automatically generated logs for at least six months under Article 26(6), and a provider keeps technical and quality-management documentation for ten years after the system was placed on the market under Article 18. Sector rules can run longer.

Who owns an agent after its creator leaves? Whoever your successor rule names, and the rule has to fire without a human remembering. Entra transfers sponsorship of agent identities to the departing sponsor's manager for exactly this reason. Without such a rule, the agent becomes ownerless and the only remaining actions are blocking or deleting it.

Is disabling an agent the same as deleting it? No, and the difference is the point. Disabling is reversible and safe to do first. Deleting is not, and a recreated identity with the same name does not inherit the old one's role bindings.

Conclusion

Agent lifecycle management doesn't ask enterprises to choose between speed and control. It lets them move quickly precisely because they never lose track of what their agents do, who owns them, and whether they should still be running.

The version that works is small. Six gates, each producing one artefact. A baseline you can diff a change against. A last_used field and a review date you can sort by. A successor rule that fires on offboarding. And a decommissioning order that disables before it deletes and revokes upstream before declaring the job done.

Sources

All URLs read 2026-09-29.

• NIST AI Risk Management Framework 1.0 (AI 100-1) — GOVERN 1.5 on planned periodic review, GOVERN 1.6 on inventory mechanisms, GOVERN 1.7 on safe decommissioning, MANAGE 2.4 on deactivating systems performing inconsistently with intended use.
• NIST SP 800-53 Rev. 5, control AC-2 — assigning account managers, approvals to create accounts, monitoring and periodic account review, AC-2(3) disable criteria, AC-2(4) automated auditing of account lifecycle actions.
• EU AI Act Article 18, Documentation Keeping — the ten-year retention of technical and quality-management documentation.
• EU AI Act Article 25, Responsibilities Along the AI Value Chain — the conditions under which a deployer is considered a provider, including substantial modification.
• EU AI Act Article 3, Definitions — the definition of "substantial modification" a change-management gate has to test against.
• EU AI Act Article 26, Obligations of Deployers — assigning oversight to people with "competence, training and authority", and the six-month log retention floor.
• EU AI Act Article 72, Post-Market Monitoring by Providers — the documented monitoring system and the duty to collect and analyse performance data across the system's lifetime.
• European Commission, AI Act regulatory framework — the Digital Omnibus amendments in force 27 July 2026, moving Annex III to 2 December 2027 and Annex I to 2 August 2028.
• What are agent identities? Microsoft Entra — why agent identities differ from service principals, agents existing for minutes or being destroyed thousands of times a day, and retiring without orphaned credentials.
• Governing agent identities, Microsoft Entra ID Governance — the four object types, sponsors accountable for lifecycle and access, access-package expiry behaviour, and automatic sponsorship transfer on departure.
• Agent Registry in the Microsoft 365 admin center — the "Agents without owners" and "Unmanaged agents" tiles, the exportable per-agent fields, and the inventory API.
• Service accounts overview, Google Cloud IAM — disabling before deleting, re-enabling a disabled account, and role bindings not carrying over to a recreated account with the same address.