The biggest ideas from
all in one place.
read the recap
Offboarding usually ends when the ticket closes. Nobody checks that it worked. In a September 2026 Sagiss survey of 1,000 former employees, 79% said at least one work account kept working after their last day.
That made me curious about what happens after the ticket closes, and what it costs a business when nobody checks. So, I built one and pointed it at our own tenant. It ran an employee offboarding audit on 14 leavers across seven systems and found 21 open items, including live access for four people. That check is what most organisations are missing from their employee offboarding process.
I spent an evening going through r/sysadmin threads about employee offboarding in organisations, and one post has stayed with me ever since.
Someone writes that an admin has left, and that he was “a gatekeeper for a bunch of critical systems” who documented nothing. The person asking on Reddit has been handed the job of working out what he ran and wants to know if there’s a tool for it or if they’re stuck reading every document one by one.
The top reply, from a senior sysadmin, says to switch the leaver’s account back on, reset the password and dig through his recents and bookmarks for a trail of his day. Further down, someone suggests rebuilding every affected system from scratch and says they’ve done exactly that twice, at two different companies. Which tells you what people think of the alternative.
The other threads tell similar stories. One new starter found service account passwords in plaintext inside the PowerShell files that run the automated tasks. My favourite, if that’s the word, is the person who found out that an old admin had set up important business reports to run automatically. All anyone knew was that a new file appeared in a shared folder every day, with the date as its name. They only found out about it when the files stopped.
That’s the gap I wanted to look at. Every company offboards people, but employee offboarding is a checklist, run once, by one person, on the day of exit. Nobody goes back a week later to check that it all worked, and the checklist can’t see anything that isn’t written on it, such as an account the leaver set up for a project or a key saved inside a script.
An employee offboarding audit is a check, run after the checklist is closed, that access was really removed in every system, including the ones nobody lists: service accounts, API keys and tokens.
I built an offboarding AI Coworker, the Offboarding Auditor, with a job description of checking what offboarding left behind and pointed it at our own account.
I kept the ask deliberately broad, because I wanted to see what it did with an open question rather than a neat one. The ticket (DWINC-15406, if you're watching the run) asked it to explore all the recently offboarded employees, identify their usage and service accounts, detect any API keys or secrets in use, and give me a full audit. Then I asked it to split the findings by group or workspace owner, so somebody could go and remove things.
For every leaver, it checked seven systems:
That last one is the one I care about most. (Tokens and consent grants hide plenty on their own; we looked at the OAuth side separately.)
It checked all 14 leavers in all seven systems, so nothing was skipped. That matters, because a check that covers only part of the picture but reports “all clear” is worse than no check at all.
Five people were completely offboarded: all seven systems confirmed closed, nothing outstanding. For those five, the process worked exactly as it was supposed to.
Five more were mostly done but had something outstanding, such as a device not returned, a seat not reclaimed or a delegation still sitting there. Ten open items between them. Annoying, and it costs money, but not frightening.
The last four still had something live: an account, an entitlement or a credential that still worked. Eleven items between them.
Add it up and you get fourteen people, twenty-one open items, and four people who could, in some sense, still get in.
I want to be careful here. This is our own lab tenant with seeded leaver data, not a customer environment and not a horror story about anyone. Only five of the 14 came out completely clean, which is just over a third. For those five, the checklist worked. The other nine weren’t missed because someone was careless. Offboarding happens once, and nobody checks it afterwards.
One more thing in the report, which I nearly missed. Look at the employee IDs: EMP0008, EMP0076, EMP0043, then STK-SYD-1120, then 0012, then RAM-CPH-3777, and two rows that just say “Not recorded.” Two of the fourteen people who left don't have an employee ID on file. You can't reliably reconcile a leaver against seven systems if you can't say with confidence who they were. That's a joining-the-data-up problem sitting underneath the offboarding problem and making it worse.
Every one of those twenty-one items is a finding attached to an owner, waiting for a person. I'd argue that's the right design rather than a limitation, because killing a credential you haven't properly identified is how you take down the thing it was quietly holding up. That unknown admin's reporting script would have died a lot faster if something had auto-revoked its key. The Coworker does the tedious, easy-to-skip part, the checking and the sorting by owner. The call on what's safe to remove stays with the people who know what each key is holding up, which is the part you govern through access governance. We keep landing on this pattern: in a software inventory sweep, the most useful finding was the one the Coworker refused to fix.
Here is what it can’t do. This was our own tenant with test leavers, so treat it as a demo, not a benchmark. It can only check the systems it’s connected to, so a gap outside those seven wouldn’t show up, and the report would still say complete. It also shows that access exists, not whether anyone used it. That’s the next question, and a harder one.
Employee offboarding automation handles the leaving. The account is disabled within minutes of HR hitting save. What it doesn’t do is check afterwards, and that’s where the leftovers sit: service accounts someone made for a project in 2022, keys in a repo, a delegation nobody remembers granting.
An audit shows what automation can’t. You see which leavers are fully closed, which aren’t, and who owns each open item. Once your team acts on the list, the cost of unreturned devices and unreclaimed seats stops, and so does the risk from credentials that still work.
Checking is boring. There’s no deadline, nobody chases it, and nobody sees a cost when it’s skipped. So, it gets skipped. That makes it the right job for an offboarding AI Coworker, which can run it every week while your team gets on with work that needs people. A read-only Coworker that checked 890 configuration items against AWS and Entra found ghost servers owned by people who had left. Offboarding has the same blind spot.
If you automate offboarding but nobody checks it afterwards, that’s where I’d point an AI Coworker first. You’ll know which leavers are fully closed and what’s still open.
Faq answer paragraph
Faq answer paragraph
