When an Employee Leaves: Offboarding People from an Enterprise AI Platform

Identity teams have offboarding solved for the systems they have owned for twenty years. Disable the account, revoke the tokens, reclaim the licence, transfer the mailbox, collect the laptop. The checklist is mature because every one of those steps was learned from an incident.

An enterprise AI platform is new enough that most of those steps have no equivalent yet — and the platform is unusual in that people do not merely use it, they build things inside it. Over a year an employee accumulates agents, workflows, prompt libraries, ingested documents, retrieval permissions, tool connections, saved contexts, and a conversation history that may itself be a business record. Disabling their login addresses one of those.

Separate the person from what the person built

The useful mental model is that an AI platform holds three different kinds of thing belonging to a departing employee, and each has a different disposition.

Access — what they could reach. SSO, group membership, retrieval entitlements, tool scopes, API keys they generated. This should terminate with the account, and the important work is verifying that it actually did, including anywhere entitlement was cached.

Assets — what they created that others depend on. Agents, workflows, shared prompts, curated collections, evaluation sets, integrations. These need reassignment or retirement, and the decision belongs to the receiving team rather than to IT.

Records — what the platform holds about their work. Conversation history, generated documents, approvals they gave, decisions they influenced, audit entries naming them. These are governed by retention policy, and the strong default is that audit trails do not get deleted because a person left; a record of who approved what must survive their departure to be worth anything.

Conflating these is where offboarding goes wrong in both directions — deleting an agent a department relied on, or leaving live retrieval access to a corpus for someone who has left.

The leaver checklist

Work through it in this order, because the later steps depend on the earlier ones being visible.

• Inventory before you disable. Once the account is gone, finding what it owned gets harder. Produce the list of agents, workflows, scheduled jobs, integrations, API credentials, and ingested sources attributed to the identity first.
• Terminate interactive access, including any personal API keys or tokens, and confirm that cached entitlement, session state, and semantic cache entries do not continue to serve results under the old rights.
• Stop or reassign anything that runs on a schedule. A nightly agent whose creator has left is the classic orphan: still executing, still holding tool permissions, accountable to nobody.
• Reassign shared assets to a named owner, with the receiving owner acknowledging the prompt, the tools, and the permissions they are inheriting — not just the name on the record.
• Review what they ingested. Documents an individual added to a shared retrieval corpus stay there. Confirm the corpus still has a justification and an owner for that content.
• Apply retention rules to their history rather than a blanket delete or a blanket keep, and record which rule was applied.
• Preserve the audit trail intact, including the identity references, so past approvals and decisions remain reconstructable.
• Re-test the boundary. Confirm that a query as the departed identity fails, and that content they could uniquely reach is no longer returned to their former colleagues if it should not be.

The mover case is the one that bites

Leavers are conspicuous — someone raises a ticket. People who change roles are not, and they are where entitlement quietly accumulates: the analyst who moves from finance to procurement and keeps both sets of retrieval permissions, because nothing in the process removes the first.

In a permission-aware private RAG deployment this matters more than it does in a document management system, because retrieval composes entitlements silently. An assistant answering a question with everything the user is technically allowed to see will happily blend two roles’ worth of material into one confident answer, and nothing in the interaction signals that it happened.

Treat a role change as a leaver event for the old role. Re-derive entitlements from the new role rather than adding to the existing set, and put the same verification step at the end.

Design so offboarding is possible at all

Some of this is process, but the parts that hurt are architectural, and they are decided long before anyone resigns.

Derive entitlements from groups, not from individuals. Every per-person grant is a future offboarding failure. Retrieval filters that resolve group membership at query time survive personnel changes; snapshots of “who could see what” taken at ingestion time do not.

Give agents their own identities. An agent that runs as the person who built it inherits their access and breaks when they leave. A separate, least-privilege identity with an explicit owner is both safer while they are there and far simpler when they go.

Make ownership a required field. Any asset that can outlive its creator — agent, workflow, integration, collection — should be un-creatable without a named owning team, so orphan detection is a query rather than an investigation.

Keep an attribution index. The ability to ask “what does this identity own, hold, or appear in?” across the platform is the single capability that makes AI offboarding routine rather than archaeological.

Why this is easier inside your own boundary

When the platform runs in your own infrastructure, offboarding is a controlled operation over stores you can enumerate: the identity provider, the retrieval indexes, the object store, the databases, the logs, the caches. You can prove that a permission is gone by inspecting the system that enforces it, and you can apply your existing retention and legal-hold regime to AI content rather than negotiating a separate one.

That also makes deletion defensible. Being able to demonstrate that a departed employee’s private content was removed from the index, the embeddings, and the derived caches — and that the audit record was deliberately retained — is a much stronger position than an assurance that a third-party service has done so.

How VDF AI supports the identity lifecycle

In a VDF AI Solution deployment, the relevant capabilities are ownership metadata on agents and workflows, group-derived retrieval entitlements resolved at query time, separate agent identities with scoped tool permissions, and an audit trail that survives account termination. When evaluating any platform, ask for the offboarding demonstration specifically: disable a test identity, then show what stopped, what changed owner, what remained by retention rule, and what a colleague can now retrieve.