The Employee Left. His AI Agent Stayed.

The offboarding worked perfectly. That's the part I keep chewing on.

Someone left a company we work with. Standard departure, nothing dramatic. HR triggered the process, IT killed the accounts, the laptop came back, the door pass stopped working. Email dead the same afternoon. Single sign-on revoked. Somebody ticked the boxes on a checklist that had been refined over years and it was, by every measure that organisation used, a clean exit.

Except he'd built an agent. It ran on a schedule, it touched real systems, and it was still running after he'd gone. It had never appeared on the checklist, because the checklist was written for people, and the agent wasn't one.

Nobody noticed for a while.

I'm not going to walk through what happened next, partly because it isn't mine to tell and partly because the interesting part is upstream of the damage anyway. What I'll say is that once it surfaced, the conversation turned to whose responsibility it had been. IT had revoked every account HR told them about. HR had run the process as written. The team said it was an internal tool, not a system, and they'd assumed it died with his login. Three defensible answers, all accurate, adding up to nobody.

Finger-pointing has never once restored data, unwound an action, or un-sent anything.

The offboarding process wasn't broken, it was just aimed at the wrong thing

The mechanical bit is worth understanding, because a lot of people assume this is handled and it isn't.

When you deprovision a human, you're mostly switching off a login. SSO stops issuing tokens, the directory flags the account inactive, downstream apps get told the user is gone. That covers nearly everything a departing employee could touch, because a person's access runs through the thing they log in with.

An agent doesn't log in. It holds credentials of its own: an API key, a service account, an OAuth token minted once and never expiring, a connection someone authorised in a moment of enthusiasm eighteen months ago. Those live in a different place with a different lifecycle. A personal access token a departing engineer generated sits in a secrets table minding its own business, and deprovisioning the user doesn't touch it unless somebody deliberately wired those two things together. In most organisations I've looked at, nobody has.

So the agent doesn't get orphaned in the sense of losing its access. It gets orphaned in the sense of losing its human. The access is fine. The access is great, actually. It's the supervision that evaporated.

Ask that organisation the week before whether it had offboarded him properly and it would have said yes, with evidence.

This is the number one risk on the list, and I don't think most people know there's a list

If it's any consolation to anyone reading this with a sinking feeling: this isn't a niche failure that one unlucky organisation walked into.

OWASP publishes a Non-Human Identities Top 10, first put out for 2025. Non-human identity is the umbrella term for service accounts, API keys, bots, and now agents. It ranks how this category of thing goes wrong, in the same spirit as the web application Top 10 most developers have heard of.

Improper Offboarding is number one. NHI1.

Not number seven, tucked below the exotic stuff. First. And the entry names precisely the shape I've described: the case where "the original owner departs, but the associated NHIs remain active without a new designated owner". The industry word for that is orphaned, and the Cloud Security Alliance research OWASP cites puts orphaned identities behind 32% of non-human identity incidents.

That same outfit has since surveyed how this is going in the agent era, in a poll of 418 IT and security professionals that a vendor selling agent-identity security paid for and helped write the questions for, so weigh it accordingly. Only 21% of organisations had a formal process for decommissioning an agent. And 82% found agents running in their environment they hadn't known about, while 68% believed they had strong visibility.

I don't think this is mostly negligence, either. These agents get built by capable people solving a real problem quickly, using access they legitimately already had. Nobody files a request to stand up a new system, because it doesn't feel like standing up a new system. It feels like writing a script. The gap opens precisely because the work is easy and useful, which is also why telling people to stop doing it is a losing strategy.

What I'd actually change

We've started treating this as a build-time question at Magnified rather than a departure-time one, because departure-time is too late by definition. Every agent we set up for a client gets a named human attached before it does anything, and that name goes into the same document listing the credential and what it can reach. Five minutes at the point of creation. Reconstructing it afterwards, across a client's accumulated pile of automations, has taken us the better part of a week, and we still weren't certain we'd found everything.

So: every agent gets a named owner, recorded somewhere a leaver's manager will actually look. Not the team. A person. Teams don't get offboarded, so pointing at a team is the same as pointing at nobody.

Then the offboarding checklist gains a line asking what non-human things this person owned, and the exit doesn't complete until each one is switched off or reassigned to a named replacement who has agreed to it. Reassignment matters as much as revocation. Plenty of these agents are doing genuinely useful work, and killing them indiscriminately just teaches people to hide the next one.

The same applies when a vendor contract ends, and I say that as a vendor. When an engagement with us finishes, the client should be revoking our agents' access the same day they revoke our logins, and if they don't get round to it, we should be telling them. An agency that leaves live credentials behind in a former client's stack is carrying a risk it can no longer manage and has no business holding.

If that sounds abstract, consider Salesloft's Drift integration in August 2025. Attackers got into Salesloft's development environment and stole the OAuth tokens connecting Drift to its customers' Salesforce instances. Google's threat intelligence team put the affected organisations at more than 700, including Cloudflare, Palo Alto Networks, Proofpoint and Zscaler. Not small shops with no security team. Every one had a live third-party integration holding real access to their customer data, revocable at any point by whoever inside owned that decision, which is precisely the job nobody had been given.

Microsoft, to its credit, has built almost exactly the mechanism I've described. Entra Agent ID lets you assign a sponsor to an agent identity, a named human accountable for its access and lifecycle, and its documentation says that if a sponsor leaves, sponsorship transfers automatically to their manager. Access packages can carry expiry dates, so inaction makes access lapse rather than persist. Somebody there had clearly watched the same failure I did. The catch is that it wants Microsoft 365 E7, or an Agent 365 licence alongside Entra P1 or M365 E3, and most of the organisations I deal with are not buying an identity governance suite this year. Which is fine. A spreadsheet with two columns and a name in each row would have prevented the thing I watched happen. The tooling is the nice version. The list is the necessary one.

The regulator got there first, which is unusual

Singapore's IMDA launched a Model AI Governance Framework for Agentic AI in January 2026, updated that May. One of its four dimensions is making humans meaningfully accountable, and its position is that "humans are ultimately accountable" for what agents do. That's the principle the case I saw violated, written down by a regulator months before I watched it happen.

Steady lah IMDA! 👏

The limits are worth stating plainly: it's principles-based, doesn't name individual accountable persons or prescribe a deprovisioning routine, and IMDA's May 2026 discussion paper on legal responsibility for AI agents weighs fault-based against strict liability without landing on either. The law hasn't decided who pays yet. MAS is further along for the firms it regulates, and its proposed AI risk guidelines carry a line worth reading twice: relying on third-party AI doesn't reduce the institution's own accountability. If that becomes the standard in finance, the "it was the vendor's agent" defence has a short shelf life.

Accountability isn't a policy document saying humans are accountable. It's a specific named person who could be asked what a specific agent did last Tuesday and would have an answer. If an agent is running and nobody can name that person in under a minute, the accountability exists on paper only.

Every organisation running agents should be able to answer one question this week: if the person who built this left tomorrow, what would switch off, and who would find out?