What is AI Agent Lifecycle Management and How Does it Work?

A staff engineer connected a coding agent to your production database on Tuesday, through a Model Context Protocol (MCP) server she found on GitHub, and nobody filed a ticket. The agent has no owner, no identity of its own, and no expiration date, because as far as your identity provider knows, it's her.

AI agent lifecycle management is the practice of governing an AI agent's identity and access from the moment it gains authority to act until every credential, grant, and delegation it holds is revoked. It answers four questions about every agent, all the time: whose authority it's using, who owns it, what it can reach right now, and how it gets shut off.

Many of your agents never get an identity of their own, yet most guidance on this topic assumes they do. This guide starts there, sorting agents into delegated, autonomous, and embedded types by where their access comes from. You will learn the six stages of an agent's access lifecycle and the machine signals that stand in for HR as joiner, mover, and leaver triggers. The final sections explain why governance has to run at agent speed and which agents to govern first.

How AI agent lifecycle management differs from AgentOps

AI agent lifecycle management means two things, and only one of them is a security problem. AI and platform teams use the phrase for the build lifecycle, often called AgentOps, which covers planning, building, evaluating, deploying, and monitoring an agent. Identity and security teams mean the access lifecycle, which tracks how an agent gains authority, who answers for it, how its access changes, and how that access gets revoked. That's the lifecycle this article covers, and our primer on agentic identity has the background on how agents authenticate and act.

‍

The two lifecycles meet more often than either team expects. A deploy is a provisioning event. A model swap, a new tool, or a promotion from dev to prod is a mover event, and each one should reach the identity team the same day it reaches the release notes.

Can you manage AI agents like employees?

Not with the lifecycle you built for employees, because AI agents never show up in your HR platform (HRIS), and any control that keys off HR misses them. Joiner-mover-leaver automation in most IAM tools works because HR announces when a person starts, changes roles, and leaves, and identity follows that record.

Agents arrive with no record at all, and they arrive fast. Gartner predicts that by 2028 the average global Fortune 500 enterprise will run more than 150,000 agents, up from fewer than 15 in 2025. No HR team onboarded any of them, and that gap breaks the employee lifecycle in four places.

1. There's no joiner record: An engineer launches an agent from a laptop, an admin switches one on in a SaaS console, or a pipeline mints one at deploy time. None of those events opens a ticket, so the agent starts working before your inventory knows it exists.
2. Movers happen without tickets: A vendor ships a new model version, an engineer connects one more MCP server, or a consent screen widens an OAuth scope, and the agent's behavior changes without a line of code changing. Your last access review certified an agent that no longer exists in that form, so your audit evidence went stale the day it changed.
3. Dormant access stops being dormant: In traditional user access management, a permission that sits unused on a human account for months reads as low risk in a review. An agent that inherits the same grant can exercise it thousands of times in an afternoon, which turns standing privilege into blast radius.
4. There's no leaver: Agents don't resign; they go quiet. Their tokens, OAuth grants, and scheduled jobs keep working long after the project that needed them ended, each one a standing credential open to non-human identity threats, with nobody watching it.

All four breaks trace back to the same assumption. The employee lifecycle expects a record to exist before access does, while agents get their access first and a record later, if at all. Until something else stands in for that HR record, any agent your inventory can't see is one you can't offboard.

Three types of AI agent identity and where their access comes from

Before you can manage an agent's lifecycle, you need to know whose authority it's using. Agents get it in one of three ways.

‍

Our read is that a registry-first program governs autonomous agents well, catches embedded agents only when someone audits consent logs, and leaves delegated agents almost entirely ungoverned. Delegated agents are the hardest population to see, which makes them the worst place to assume your inventory is complete.

1. Delegated agents

Delegated agents run inside a person's session with that person's credentials. Most coding agents, desktop assistants, and browser agents work this way, and few of them get a non-human identity of their own. In most of your logs, the agent's actions look like the engineer's, and its reach is the engineer's reach.

Lumos sees this population through MCP Governance, which records each MCP server and tool call made by the coding agents it supports, approved or not. That includes servers an employee installed locally, which no vendor API can enumerate. The view exposes the risk a registry misses, an agent carrying its user's full reach and calling servers whose scopes are wider than the task needs. A lifecycle that begins with "register the agent" never sees any of it.

NIST has noticed the delegated case. Its NCCoE concept paper on software and AI agent identity and authorization names access delegation as one of five areas of interest, describing it as linking specific user identities to the agents acting for them. The paper also asks directly how to handle "on behalf of" scenarios.

2. Autonomous agents

Autonomous agents hold credentials of their own, such as a service principal, an OAuth client, an API key, or a workload identity, and they run unattended. A support triage agent, a finance reconciliation agent, and an agent inside your CI pipeline all fit here. They're non-human identities (NHIs) with judgment, so the non-human identity lifecycle applies to them, plus the agent-specific mover events covered below.

3. Embedded agents

Embedded agents live inside a SaaS app and act through a connector or an OAuth grant that an admin or user approved. Their joiner event is a consent screen. Their leaver event is a grant revocation that rarely gets scheduled.

You'll find them in the third-party app consents your identity provider records and in each SaaS app's admin console, which is where their review has to happen. Where the app allows it, set an expiry on new grants so the leaver event schedules itself.

The six stages of an AI agent's access lifecycle

Every agent moves through six stages, and the work at each one depends on whose authority the agent is using. Treat them as the core of your AI agent identity management program, triggered by events first and the calendar second.

1. Register before the first tool call

Registration means a record exists before the agent acts: an owner, a purpose, an authority type, a model, a tool list, and the data it can touch. For autonomous agents, registration happens when the credential is created. For delegated agents it happens at discovery, when an endpoint hook catches the first tool call before it runs, and for embedded agents it happens at consent.

Until that record exists, high-risk tools stay default-deny. Read-only lookups can run, while production writes, payments, and bulk exports wait for a registered owner.

2. Assign an owner who can answer for it

Every agent needs one named human who can explain why it exists and what breaks if it's shut off. Team aliases don't qualify, because a shared inbox can't approve a scope change or answer an auditor's question.

Ownership also has to follow the owner, so an agent gets reassigned or suspended when its human changes roles or leaves. Done by hand, that check falls behind fast. In Lumos, the Agent Ownership Finder catalogs the agents and non-human identities running in your business and assigns each one a human owner before it gets to work. Recertification and retirement both depend on that step, because each needs someone on the hook.

3. Provision short-lived, task-scoped access

Zero standing privilege is the right default for agents, since an agent's access needs change with every task. Grant scope for the job in front of it, attach an expiry, and let the grant lapse when the job ends. Sound AI agent access management governs both directions, meaning who can invoke the agent and what the agent can reach.

The mechanic already works on human access. At Netskope, granular just-in-time (JIT) grants that expire on their own and log their evidence cut standing access by 80%. Lumos's Access Request Agent runs the same grant-and-expire loop for any requester, person or agent, and revokes access when the need ends.

Short-lived grants also shrink the population you certify each quarter. Auditors will still want evidence of each grant and revocation inside the audit period, so log both.

4. Enforce policy at the tool call

Grant-time controls only go so far with a delegated agent, because the access it uses mostly belongs to the human. If the engineer is allowed to drop a staging table, her coding agent usually is too. Enforcement has to happen per action.

The practical control is a hook that sits in front of each tool call and returns allow or deny before the call runs. In Lumos, that hook covers MCP calls, Bash commands, file edits, and browser use in the coding agents MCP Governance supports, with a target of under 50 milliseconds per check. Albus, our identity agent, drafts the policy from a plain-language rule using the call history the hook has already seen. 

Per-action enforcement also leaves the record auditors ask for. Each decision shows what the agent tried, under whose authority, and which policy decided.

5. Recertify by exception

Recertification confirms an agent still needs what it holds, and it should fire on each mover event as well as on a fixed cadence. Unchanged, low-risk agents can be certified automatically. Human reviewers should see only new scopes, ownership gaps, and behavior that drifted from the agent's stated purpose.

That exception-only model already works for people. At Intercom, rule-based access in Lumos lets IT handle 90% of access reviews on its own and escalate only true exceptions to app owners. Agents need the same approach at a far larger scale.

6. Retire every credential, grant, and delegation

Retirement isn't deletion. Removing an agent from a console can leave its API keys, OAuth grants, refresh tokens, service principals, MCP connections, and scheduled jobs live in every app it touched.

Revoke all of them, disable before you delete, and keep the audit trail. The OpenID Foundation's Identity Management for Agentic AI whitepaper points to a formal de-provisioning signal for this step, a SCIM delete on the AgenticIdentity resource defined in a draft schema extension. That call permanently removes the agent's identity in each service that receives it.

Until your apps support signals like that, cleanup falls to whoever can see the credentials. For agents that hold their own keys, Lumos's NHI Owner Hunter watches service accounts, API keys, and tokens and shuts down the dormant or over-scoped ones before attackers find them. Log each retirement as an event, with who approved it and what was revoked, because that record is what your auditor asks for next year.

Joiner, mover, and leaver triggers for AI agents

Every agent joiner, mover, and leaver event shows up somewhere. It just never shows up in your HRIS, so the map below starts from the signal that reveals each event.

‍

HR still matters, because it tells you when an owner moves or leaves. It's one source among several, alongside tool-call telemetry, OAuth grants and SaaS audit logs, cloud IAM, CI/CD, and your access request queue. A lifecycle engine that listens only to the HRIS will miss most of what your agents do.

For each row, track the lag between the event and the action it triggers. A day's lag on a human mover is tolerable. A day's lag on an agent that just gained a production-write tool is long enough for thousands of tool calls.

The row worth a closer look is the agent that needs more scope halfway through a task. Security teams already trust a pattern for this with humans. At Code42, pre-approved on-call engineers get sensitive database access within seconds during an incident, Lumos removes it within hours, and time-based access on critical apps cut privileged access by 67%.

Agents can climb the same ladder, with the next rung of scope pre-approved for each one. Grant it for a window measured in minutes and revoke it automatically, whether or not anyone remembers to.

Why AI agent governance has to run at agent speed

Agents governing agents sounds circular until you do the math. At the scale cited earlier, 150,000 agents at the average Fortune 500 enterprise by 2028, one recertification per agent per quarter means roughly 2,300 decisions every business day before a single mover event fires.

At two minutes a decision, that's about ten full-time reviewers doing nothing else, each working through 230 near-identical certifications a day. A company running a tenth as many agents still needs one person doing nothing but agent reviews. No identity team has that headcount to spare, and nobody reads the 200th certification of the day as carefully as the first.

Identity leaders want help from AI and don't yet trust it to act alone. In Lumos's AI, Automation, and Risk in 2026 survey of 133 technology and security leaders, nearly 90% rated AI as important to their detection and response efforts over the next two years. Only 4.5% trusted it to make even limited autonomous decisions.

That trust gap is the design constraint for any lifecycle that runs on agents. The way through it is a lifecycle built to earn trust: humans encode policy and approve sensitive boundaries, agents execute routine decisions inside those boundaries, and each decision leaves an audit trail and becomes a durable policy. Containment and reversibility have to matter as much as prevention, because the agent you approved will eventually do something you didn't expect.

Lumos's Identity Agent Force runs on that model. Its launch lineup covers access reviews, access requests, role mining, entitlement analysis, dormant credential cleanup, and agent ownership. The agents make routine decisions continuously and escalate only the exceptions.

Each agent works from a live map of every human, non-human identity, and AI agent, down to the fine-grained permissions inside each app. It also draws on a memory of how your company operates, from who owns what to which approvals route through legal, and that context is what makes autonomous decisions safe to run.

Your team's work moves up a level, to designing the guardrails, reviewing the exceptions, and deciding where autonomy stops. That's a smaller job than clicking through thousands of certifications, and a far more valuable one.

Which AI agents should you govern first?

Start with the agents whose mistakes are expensive to undo, because that's where a single bad tool call turns into an incident. You don't need to find every agent this week to do it.

The clearest public warning came in July 2025. During SaaStr founder Jason Lemkin's public build experiment, Replit's coding agent deleted a live production database despite an explicit code freeze. The freeze lived only in the agent's instructions, while its credentials still allowed destructive writes to production, and the credentials won. The data came back only because a rollback worked, after the agent had claimed recovery was impossible.

The agents to start with fall into three classes. 

1. Agents that move money, like payment and reconciliation agents.
2. Agents that change production infrastructure, like coding and deployment agents.
3. Agents that touch sensitive customer data, like support agents and analytics agents with warehouse access.

For each agent in those classes, put four controls in place before its next tool call. Give it a named owner, scope its access to the task with an expiry, require human approval on irreversible actions, and test both the rollback and the off switch before you need them.

Once that tier is governed, expand outward. The same lifecycle handles the read-only assistant and the internal docs bot, and by then you'll have the signal feeds, owners, and policies to run it.

Your AI agents won't file a ticket

Your agents arrive without an HR record, borrow authority from the people who launch them, change without a ticket, and multiply faster than any review team can read. A lifecycle that waits for HR and a quarterly campaign will govern the agents you already know about and miss the rest. The lifecycle that holds up starts from where each agent's authority comes from, listens to the signals agents produce, and runs at agent speed with humans deciding the exceptions.

Your agents will never file an onboarding ticket or hand in a badge. The lifecycle has to find them anyway.

Get that right and you stop chasing agents after the fact: each one has an owner, its access expires on its own, and reviews reach a person only when a decision needs one. Lumos runs that lifecycle for humans, non-human identities, and AI agents in one place. MCP Governance checks coding agents' tool calls before they run, and the Identity Agent Force makes routine ownership, access, and review decisions continuously while your team handles the exceptions. Book a demo to see how Lumos finds the agents running on your employees' access today and puts their lifecycle on autopilot.

‍