Borrow the framework that already works
IAM solved this problem for human employees decades ago: the joiner-mover-leaver model. An identity gets created deliberately when someone joins, adjusted when their role changes, and fully retired when they leave. It works because every stage has an owner and a trigger. Agent identities need the exact same structure, and mostly aren't getting it.
Here's what each stage looks like applied to an AI agent instead of an employee.
Joiner: provisioning an agent identity
An agent identity should never be created as a side effect of someone testing an integration. It should be a deliberate decision with four things attached before it goes live:
- An owner. A specific person or team accountable for the agent, not "the platform team" in the abstract.
- A defined purpose. What task is this agent for, specifically enough that you can tell later whether it's still doing that task.
- A scope. The minimum set of tools and data access the task actually requires, not the maximum the connected systems happen to expose.
- An expiry or renewal date. Every credential should have to be actively renewed, not passively persist until someone notices it shouldn't.
Mover: when an agent's role changes
Agents get repurposed constantly. A summarization agent gets a new tool bolted on. A prototype quietly becomes a production dependency. Each of those is a role change, and each one should trigger the same review a human role change would: does the current scope still match the current purpose, and does the owner still make sense?
In practice, this is the stage most organizations skip entirely. The agent's permissions ratchet upward as capabilities get added, and nothing ever gets removed, because removing access requires someone to notice it's no longer needed.
Leaver: retiring an agent identity
When a project ends, when an agent gets replaced by a newer version, or when its expiry date arrives without renewal, the credential should be revoked immediately, not left dormant "in case it's needed again." A dormant agent credential is functionally identical to a former employee's account that was never disabled: no one is using it for legitimate work, and it's pure risk sitting on the shelf.
If you can't currently produce a list of every AI agent identity in your environment, who owns each one, and when it was last reviewed, that's the actual starting point, before any tooling conversation.
Why this can't be a one-time project
Agent sprawl isn't a problem you fix once. New agents get built every sprint, often by people outside the security or IT team entirely. The lifecycle framework only holds if provisioning a new agent identity is as easy as spinning up the agent itself, which means it needs to be built into how your teams already ship agents, not bolted on as a separate compliance step nobody follows.
This is exactly what our AI Agent Governance engagements are built around: a lifecycle process your teams will actually use, not a policy document that sits in a wiki.
Want a real inventory of the agent identities already running in your environment?
Start an assessment today