How to Offboard an Employee From Your AI Tools
Revoke by blast radius, not alphabetically. The first thirty minutes in order, the three access paths that survive a normal offboarding, and how to find the tools nobody told you about.
To offboard an employee from your AI tools, revoke by blast radius rather than by tool list. Kill anything that can write to production or read customer data first, anything that can spend money second, and read-only assistants last. Working alphabetically through your subscriptions feels organised and leaves the dangerous thing running for three days.
The other half of the job is the part that no checklist catches, because the access that survives a normal offboarding was never granted through an admin console.
The first thirty minutes, in order
Assume you have a leaving date and a normal, non-hostile departure. Same order applies either way; only the urgency changes.
Anything with write access to production or customer data. Coding agents wired into a repository, deployment tooling, anything holding a database connection string. This is the only tier where minutes matter.
Anything that can spend money. API keys with billing attached, agent accounts with budgets, model provider consoles. A forgotten key is a bill, and occasionally a large one.
Anything holding company knowledge. Assistants with your documents indexed, transcription tools sitting in meetings, note-takers with calendar access.
Read-only chat accounts. Last, and mostly for licence hygiene rather than risk.
Where you have single sign-on, disabling the identity handles most of tiers three and four in one action. It very often does not handle tiers one and two, for reasons the next section covers. Formal frameworks put this obligation in writing: account management controls in NIST SP 800-53 require disabling accounts of terminated individuals, and auditors will ask how you evidence it.
The three access paths that survive offboarding
This is where the real exposure sits, and none of it shows up when you look at your admin panel.
Personal API keys created inside team accounts. A developer generates a key from the team's model provider account. The key is a bearer credential in its own right. Deactivating the person's login does not revoke it, because the key does not care who created it. It keeps working, it keeps billing your account, and it will keep working for years unless someone rotates it.
Check every provider console for keys, look at last-used timestamps, and rotate anything you cannot positively attribute to a system that is still running.
OAuth grants pointing the other way. Someone connected their personal AI assistant to the company Drive, or authorised a note-taking tool with their work calendar using a personal account. The grant lives on the account being accessed, not on the leaver's identity, so it survives their departure intact. Review third-party app access in your Google Workspace or Microsoft admin console specifically, not just user accounts.
Local configuration on the departing laptop. Agent config files, .env files, locally cached credentials, a locally running model with your documents in its index. If the device is not being wiped, these leave with it. This is also the case where a coding agent's stored secrets matter, a risk we cover in can an AI coding agent leak your API keys.
Shadow tools are the hard part
Everything above assumes you know which tools the person used. In most small companies you do not, because a meaningful share of AI adoption happens on personal accounts and personal cards, expensed or not.
Three ways to find the unknown ones, in order of how much work they are:
Expenses. Search the last twelve months of card statements and reimbursements for AI vendors. Fast, and it finds the paid ones.
OAuth grant lists. Your identity provider's third-party app list shows what was connected to company data, including things nobody told you about.
Ask, once, without consequences. In the handover conversation: which tools did you use that IT does not know about. Asked neutrally, this gets an honest answer surprisingly often, and it is the only method that finds free-tier tools with no paper trail.
If that exercise turns up more than you expected, the problem is not this leaver. It is covered in shadow AI, and it is worth fixing before the next departure rather than after.
What to do about the chat history
An underrated question, and it splits into two.
Work the company needs. Prompt libraries, drafts, research threads. If it lives in a personal account, it leaves with the person, and asking for it after the fact rarely works. The fix is upstream: shared workspaces rather than individual accounts for anything that constitutes work product.
Data the company must account for. If the person pasted customer records or personnel information into a tool, that data is now in a system you are responsible for, and a departure does not change your obligations under it. Know where it went before the account is closed, because after closure you may lose the ability to look. Retention decisions are covered in how long to keep AI chat logs.
Make the next one boring
The single highest-value artifact is a maintained list of every AI tool in use, who has access, and what it can reach. Not a policy document. A table, one row per tool, four columns: tool, who has access, what data it can reach, who revokes it.
Build it once during an offboarding, when you are already doing the archaeology, and keep it current. It converts a two-day investigation into a twenty-minute checklist, and it is the same table you need when a client asks which subprocessors touch their data.
Two supporting habits make it stick: grant AI tool access through your identity provider wherever the tool supports it, and log grants and revocations somewhere durable, as covered in keeping an audit trail of AI use. The same discipline applies to temporary access, which is why giving a contractor access to your AI tools is the mirror image of this post, and both sit inside the broader picture in our guide to AI risks.
FAQ
Does disabling single sign-on revoke everything?
No. It handles login-based access well and misses API keys, OAuth grants made from personal accounts, and anything cached on the departing device.
How urgent is this for an amicable departure?
The write-access and billing tiers are urgent regardless of how the person left, because the risk there is accident and cost rather than malice. The rest can follow the normal leaver process.
What about a departing contractor rather than an employee?
Same order, tighter timeline, and check for keys more carefully, since contractors are more likely to have generated their own to work around access friction.
Should we recover their prompt library?
Ask during handover, and treat a no as a lesson about where work product lives. Shared workspaces prevent the problem; recovery attempts after the fact usually do not solve it.
How do we prove we did this?
Keep a dated record of what was revoked and by whom. That record is what an auditor, a client security questionnaire, or an incident review will ask for, and reconstructing it later is close to impossible.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
