Who collects the keys when an AI agent retires?
Think about the last time a good engineer left your company. Someone collected the laptop and the badge. IT revoked their logins before the end of the day. Their manager reassigned the open tickets, and HR filed their records somewhere they’ll stay for years, in case anyone ever challenges a decision they made.
Now think about the last time an AI agent left. Someone probably deleted it from the dashboard. I’ve started describing agents as vendor employees who never sleep and never get offboarded.
That difference matters because the agent did real work while it was here. It held credentials and made decisions someone may ask about years from now. Deleting it removes the name from the screen and leaves all of that behind. So take the exit checklist you already run for people and go through it one step at a time, asking what the agent version looks like.
Access outlives the agent
When a person leaves, IT has a list. Usually it’s a checklist built up over years of people leaving: laptop, badge, email, Slack, the company card, that one design tool only three people use. The identity provider shows the apps connected to their account, and one switch turns most of that access off.
An agent rarely comes with that list. It might hold a service account in the CRM and a token it shares with two other automations someone set up last year. The shared token is the one that causes trouble at retirement, because nobody can say which permissions belong to the agent and which belong to the things still running.
OWASP ranks improper offboarding as the top risk for non-human identities like these.
Turning the agent off in its own platform is like taking back the badge and forgetting about the server-room key you had cut for it. The better answer is keys that expire on their own. Where the architecture allows it, give agents short-lived credentials scoped to one action, so there’s nothing left to collect. Whatever standing access remains has to be traced through the identity and API layers and tested after shutdown, because an agent can disappear from the inventory months before its credentials leave the permissions list.
The work it leaves running
A departing engineer’s open tickets go through someone’s hands before the last day, usually in a rushed handover call where someone says ‘it’s all in the doc.’ The manager decides who picks up what.
An agent’s queue is harder to see. It may have scheduled a job for next week or passed half a task to another agent. Before shutdown, someone has to find that work and sort it by whether it can be undone, which is quick for a half-written draft and slow for a payment the agent already sent for processing.
The work that worries me most is the kind nobody queued. Every team has someone who quietly keeps a small but important thing running. You usually discover what it was when they go on holiday. Agents do this too.
Say one keeps a customer record current, and a renewal system reads that record every Monday. Delete the agent, and on some Tuesday morning a renewal quote goes out built on a record nobody has touched in weeks.
Decisions outlive the model
HR holds on to an employee’s records for years after they leave. Nobody expects to need them. They keep them because a decision that person made might be challenged long after they’re gone.
Agents make decisions that get challenged too. Picture one that spent 18 months helping decide eligibility for a lending product before a more accurate model replaced it. Two years later, a customer’s lawyer asks why the old agent denied her application.
The denial itself is on record. The reasons sit in what was true that day: which model and prompt version ran, the data it saw, the tools it called and the policy in force. A snapshot of the agent’s final configuration describes its last day, and the denial happened on some other day.
Routine cleanup throws away exactly that context. Prompts get overwritten, and ogs expire under retention rules built for operations, long before a lawyer asks a question two years later. An agent can have its access revoked cleanly and its work handed over properly, and still leave you unable to defend a single decision it made.
The retirement record
Every offboarding ends with a signature and a date. For agents, I’d make that record answer two questions, each with a timestamp: when was the agent’s identity disabled, and when did anything last act under it? If the second time is later than the first, the agent is still working for you, whatever the dashboard says.
It’s the equivalent of a former employee still badging into the office months after their farewell.
The record should also name who owned the agent and where the evidence for its decisions now lives. Its working memory needs a decision too. Cached results and vector database entries can hold customer data, and some of it has to be kept for audit while the rest can go the same day.
The cheapest place to start that record is the agent’s first day. Give every agent a named owner and a review date when it goes live, the same way a new hire gets a manager and a probation review.
At Sprinto, that’s how customers bring AI systems into their compliance program. Each one sits in a registry with a named owner. When it’s time to retire one, the delete button is switched off. The system moves through a formal offboarding stage that can require the owner’s sign-off and a decision on its data, and every step is logged as evidence for the auditor.
Why this gets harder every month
More software will get written and shipped in the next two years than in the last 40, and a growing share of it will be agents. People now build them on internal tools without realizing they’re writing code.
HR can offboard people by hand because every hire went through HR in the first place. Agents get created by anyone with access to the right tool, with no engineering release and nobody in HR to notice. Retiring a dozen of them by hand is manageable. At a few hundred it falls apart.
For agents, a system has to do the job HR does for people. It runs on its own and brings in a person when a decision is needed. That system should control what each agent can access, the same way companies control employee logins.
The same system should know each agent by what it does, whatever model it happens to run, and keep a versioned history of how that agent behaved. That history is what lets you explain a decision from 18 months ago even after the model is gone.
A system like that is the only way I can see to keep up once agents number in the hundreds, and the time to put it in place is now, while the systems are still simple enough to trace.
Every agent you deploy will have a last day. Decide now who collects the keys.
