In my last piece I asked two things about every agent and automation in a firm: who is its named owner, and what happens when that person leaves. The second half is where most firms get stuck, and it is not new. Anyone who has run a privileged-access programme in a large organisation will recognise what follows.
How ownership drifts
In a large, long-lived estate, account ownership often sits in one system and HR data in another. Unless the two are joined, a leaver or a mover changes nothing on the account side. The record still names the person.
A common rule is that ownership passes to the leaver’s line manager. Sensible on paper. In practice, ownership travels upwards. Over time, accounts built for technicians and troubleshooters can end up owned by senior executives who will never use them and should not hold them.
One safeguard is a stop: once ownership reaches a certain level of seniority, it goes no further, and the account passes to the identity and access management team. That halts the drift, but it does not solve the problem. The team still has to work out who the right owner is, and often it cannot. Keeping it going takes people doing manual remediation, account by account, for as long as the gap is there.
That leaves two problems. Stale records pointing at people who have gone, and owners who inherited accounts without knowing what they are for. The second is harder to fix. A manager running several teams often has no idea why a given account exists, so they do the safe thing, which is nothing. They will not delete it, and often cannot say who should take it instead.
Where it surfaces
Most of the time it surfaces in an ordinary access request. Someone needs to use a privileged account, and the request goes to the account’s owner. If that owner left two years ago, or inherited the account without knowing what it does, the request either sits there or gets waved through. Neither is control, and it happens every week, not once.
Privileged-access tools add a twist. Most group accounts into containers, a safe or a folder, and the container has its own owner. When the person who owns the container is not the person who owns each account in it, requests go to someone who cannot judge them. The tidy version is simple: each account has one owner, and its container belongs to the same person.
Recertification has the same weakness. Once or twice a year, owners are asked whether their accounts are still needed and who should be able to use them. An owner who does not know what an account does will keep it, because removing it might break something live. The review gets signed, and nothing has really been reviewed.
A smaller firm, the same mechanism
A firm of 500 people does not have a global organisation’s estate: fewer platforms, fewer legacy systems, fewer accounts. I am not going to claim the problem is the same size.
The mechanism does not depend on size, though. An owner field names a person. People leave, move and get promoted. If nothing links HR events to account ownership, the records drift, and they drift in one direction: towards people with more seniority and less idea what the account does. In a smaller firm, the line manager may be the CTO after a single step.
The standards assume that link exists. OWASP’s Top 10 for non-human identities puts improper offboarding first, and describes the case where “the original owner departs, but the associated NHIs remain active without a new designated owner”. Its advice includes integrating HR systems with identity tools, and recertifying accounts regularly to confirm they “have valid owners”.
Agents join the queue
AI agents are the newest accounts in this picture. Microsoft’s Entra Agent ID requires at least one sponsor for every agent identity, someone from the business who answers for it, and its documentation says sponsorship “should be maintained to ensure succession when an employee who’s a sponsor moves or leaves”.
That is the right instinct, and it is the same problem under a new name. Once agents are part of how a team works, and are shared between teams, the person who sponsored one will move on and the agent will stay.
Even where HR is linked to identity, the standard leaver steps act on the person, not on what they owned. Microsoft’s leaver workflows, part of its identity governance licences, can disable the person’s account, remove them from groups, end their sessions and email their manager. There is no built-in step for the service accounts, groups or applications they owned. The one thing the workflows can pass on is the sponsorship of an AI agent, and they pass it to the leaver’s manager: the same line-manager rule as before, now automated.
The difference matters. A personal admin account should go when the person goes; that is ordinary leaver work. A shared or service account should stay, but its owner has to change to someone still in the firm, and that is the step the tools leave out.
Who should sign
When an account has no owner and someone has to decide whether to keep or remove it, who signs? The natural answer is the owner of the application the account serves. They are the one accepting that their system can be used by an account whose purpose is unclear.
That only works if you know which application it is. A local account on one server is easy to place. A domain account sitting in the directory may be used by several applications, or by none that anyone can name. Large firms build their own logic to tie accounts back to applications, and vendors now sell tools that do the same. Neither is an exact science. In a smaller firm the map may be simpler. It is still worth drawing. Where the link is clear, the application owner signs. Where it is not, the first job is finding out what actually uses the account.
What should not happen is the identity team signing because nobody else will. It can describe the risk, but it does not own the system. Nor should it fall to whoever happens to sit at the top of the inherited chain.
Four questions for Monday
- Does your leaver or mover process change anything on the accounts a person owns, or does it stop at their own login?
- When ownership does change, who takes the account over, and is there a level where that stops?
- Could each owner say what their accounts are for, which applications use them, and who should be allowed to use them?
- When an account has no owner, who signs: the application owner, or nobody?
If the honest answer to question two is “their manager, and nothing stops it”, ownership in your firm is moving upwards.
Where I am on this
I spent years leading privileged access initiatives at a global bank, including a migration off a legacy PAM platform. At that scale the problem is impossible to miss. I am now talking to people in smaller firms to see how it looks with a smaller estate. If you have had to answer question two, I would like to hear how it went.
First published on LinkedIn on 21 October 2026. Discuss it there, or write to hello@aevixadvisory.com.