Every organisation has a leaver process for people. It's imperfect and it usually runs late, but it exists. Somebody in HR marks a date, a ticket appears, accounts get disabled, licences come back, devices get collected, and there's a checklist with a name on it.
Now think about the last AI agent your organisation built.
Somebody built it for a project. The project ended, or the workflow changed, or the person who championed it moved teams. What happened to the agent?
In almost every case the honest answer is nothing. It's still there. It still holds its identity, still holds its permissions, still has access to whatever it was pointed at. It just stopped being used, and there is no event in any system anywhere that corresponds to "this agent is finished."
The asymmetry
Human identities have three lifecycle events, and every identity system is built around them: joiner, mover, leaver.
Non-human identities have one. Creation.
There's no HR record, no manager, no last working day, no exit interview. Nothing generates the signal that starts a cleanup, because the signal for a person comes from outside the identity system, from a human process that agents aren't part of.
This isn't new. Service accounts have had exactly this problem for thirty years, and every organisation of any age has a handful nobody dares touch because nobody knows what breaks. What's new is the rate. Registering a service account was a deliberate technical act, performed rarely, by a small number of people who understood what they were doing. Creating an agent is closer to creating a document, and the people doing it aren't thinking about permission scopes.
So a problem that used to accumulate at a few identities per year now accumulates at a few per week, created by people who won't be the ones cleaning up.
Why an abandoned agent is worse than an abandoned account
A dormant human account is a risk. A dormant agent is a slightly different and generally worse one, for three reasons.
Nobody notices when it misbehaves. A compromised employee account eventually produces a confused human: mail they didn't send, files they didn't open, a colleague asking about a strange message. That feedback loop is one of the most effective detection mechanisms any organisation has, and it's entirely absent for an agent. There's nobody to be surprised.
Its access is broad by design. Agents get built to be helpful, and helpfulness is served by breadth. Where an application gets scoped to a purpose, an agent tends to be pointed at a knowledge source and given whatever its identity needs to read it. The pressure on scope points the wrong way from the first design conversation.
Its credentials don't expire the way a person's do. No password reset cycle, no periodic MFA prompt, no manager attesting to continued need in an access review, because access reviews are built around people and agents aren't people.
Put those together and you get a standing, unwatched, broadly-permissioned identity with no owner. That's a good description of what an attacker would build if they could.
The three states nobody distinguishes
Ask for a list of agents and you get names. What matters is which of three states each one is in, and almost nothing surfaces the difference.
Active and used. Doing work, regularly, for people who'd notice if it stopped. Fine.
Active and unused. Still deployed, still holding permissions, still capable of reading everything it was granted, and nobody has invoked it in ninety days. This is the dangerous state, because it looks identical to the first one in every configuration view. Nothing in the platform distinguishes "running" from "used".
Disabled or deleted. Cleaned up. Rare.
The second state is where the whole problem lives, and it's only visible if you're measuring activity rather than configuration. A registry of agents tells you what exists. An activity ranking tells you which of them anyone actually needs, and the two lists are usually very different.
The insider version of this: the most useful single query in agent governance isn't "what agents do we have". It's "which agents have done nothing in ninety days", ranked by how much they can reach. That's a short list, it's actionable, and nobody argues about removing something nobody has used in a quarter.
What an agent leaver process looks like
The good news is that this is a solvable process problem, and it borrows almost entirely from what you already do for people.
Give every agent an owner at creation. A named human, not a team. The single highest-value control here, and the cheapest. An identity with no owner has no one to answer questions about it, and every later step depends on there being someone to ask.
Give it a review date, not a permanent existence. Six months is reasonable. On that date somebody confirms it's still needed. The default on no response should be disabled rather than continued, which is the same inversion that makes remediation windows work: doing nothing produces the safe outcome rather than the convenient one.
Measure use, not deployment. Track invocations and data access per agent. Dormancy is the trigger for review, and it's the one signal that reliably separates the second state from the first.
Tie it to the human leaver process. When somebody leaves, the checklist asks about their devices and their licences. It should also ask what they built. An agent whose creator left the company six months ago is the clearest possible candidate for review, and today nothing connects those two facts.
Watch behaviour while it exists. An agent's baseline is unusually tight, because unlike a person it does roughly the same volume of the same work every day. That makes deviation unusually meaningful. "The finance agent read four times its usual number of files today" is a strong signal precisely because agents are boring.
The same problem, wearing four other hats
Worth naming, because fixing this for agents alone leaves most of the surface untouched. The identical lifecycle gap applies to:
- Service accounts, the original version of the problem.
- OAuth application grants, where a user consented once, years ago, and the application still holds its access.
- Guest accounts, invited for a project that ended and retained forever, because access arrives through group membership rather than through the project.
- Sharing links, which are a grant with no identity attached and no expiry unless somebody set one.
All four share the shape: created deliberately, never revisited, invisible in reviews built around employees. If you're building a process for agents, build it wide enough to cover the other four, because they're the same conversation and the same query.
How 1Security does it
Agents are a first-class resource type, unified across the ecosystems Microsoft spreads them over: declarative Copilot agents, Entra Agent ID agents with their own identity, and third-party SaaS agents using Copilot behind the scenes. Where the same agent appears in more than one place it becomes a single record.
Dormancy is measured rather than assumed. Activities include an unused cut for agents alongside users, apps, sites, files, groups, emails and devices, ranked by how long they've been idle over windows up to all-time, so "agents nobody has used in ninety days" is a card on a board rather than a research project. The same cut exists for apps, users and devices, which is the wider surface described above.
Reach is quantified per agent: how many files, sites, users and emails it can access, and which sensitive information types sit inside that reach. That's what turns a dormancy list into a priority list, since an unused agent that can reach nothing is a tidiness issue and an unused agent that can reach a finance library is not.
Behaviour is baselined per entity, so an agent deviating from its own history opens an anomaly episode against itself rather than against a tenant-wide threshold. And the remediation side closes the loop: disabling an unused application or reclaiming a dormant licence is a suggested automation with a live count of what it currently matches, staged behind a review window so nothing gets switched off by surprise.
Frequently asked questions
Isn't deleting an unused agent risky? Disabling is the reversible first step, and it's the right one. Watch for a month. If nothing breaks and nobody complains, delete. The review window pattern applies here as well as anywhere: stage the change, let people object, proceed by default.
How do we find agents nobody remembers creating? Start from the identity side, which needs no extra licensing for Entra-backed agents, then sort by last activity. The ones with no owner and no recent use surface immediately. Declarative Copilot agents need Agent 365 to enumerate, which is a Microsoft API limitation rather than a product one.
What if the creator has left? That's the highest-priority case and the reason to tie this to the human leaver process. An agent whose owner has gone has no one to attest to it, which means the review has no possible outcome other than disable-and-see.
Do access reviews cover this already? Almost never. Access reviews are built around people and the resources people access. Non-human identities usually fall outside their scope entirely, which is exactly why they accumulate.
