30 Days Gen AI Risk Trial -Start Now
Skip to main content
Policy in practice · Practical playbook

Close AI access when an employee leaves

AI offboarding must preserve necessary business work while ending the departing employee's access. Review accounts, shared workspaces, connected sources and reusable projects separately; do not assume the primary identity change completes the whole task.

For IT offboarding teams, managers and application administrators

Synthetic example

A team analyst owns a shared AI project

An analyst is leaving after maintaining a shared research workspace and a connection to internal documents. Their manager needs the project context, but other team members still use the workspace.

What you are working with

  • The employee's approved tools and known workspace responsibilities.
  • Shared projects, connections and credentials requiring owner review.
  • The departure timing and a business owner for retained work.

A safer approach

  • Transfer necessary business records through an authorized process.
  • Ask each system owner to review the relevant access relationship.
  • Verify shared-team continuity without retaining the departing person's access.

Expected outcome: The organization can account for retained work and closed access while the remaining team has a verified way to continue its approved tasks.

Put it into practice

Work through the procedure

  1. Map the employee's AI responsibilities

    Use the tool register, manager input and available usage evidence to identify likely accounts and workspaces. Ask about project ownership, shared resources and connections. Keep personal-account boundaries in view; do not collect private credentials or unrelated conversations as a shortcut to discovery.

  2. Preserve the business work that matters

    Have the manager and records owner identify needed outputs and context. Use provider-supported transfer or export methods where available and verify the result. Assign an organizational destination and successor, rather than keeping the departing employee's account open indefinitely because something might be useful.

  3. Coordinate access removal across owners

    Have identity, application and connected-system administrators review their respective controls. Check sessions, workspace membership and credentials as applicable to the provider's current capabilities. Record who verified each action; do not assume a single sign-in change revokes every independent connection or account.

  4. Confirm continuity and close unresolved items

    Ask the successor to open the retained work and complete a harmless representative task. Check available administrative evidence for access removal. List unresolved personal or unknown accounts separately with an owner, and update inventories so future reviews do not still name the departed employee.

Evidence before approval

What to check before proceeding

1. Shared work has an accountable successor

Ready when
The new owner can access necessary records without using the former employee's credentials.
If the check fails
Resolve the transfer through the authorized administrator and manager.

2. Connections have been reviewed individually

Ready when
Each relevant system owner records the access outcome.
If the check fails
Keep the item open instead of treating identity removal as sufficient evidence.

3. The remaining team can work safely

Ready when
A representative approved task succeeds under current ownership and access.
If the check fails
Repair the team's route without restoring unnecessary departing-user access.

Common mistakes to avoid

  • Keeping a departing employee's account active as the permanent owner of a shared AI project.
  • Treating no recently observed AI activity as proof that provider sessions, independent credentials or external sharing no longer exist.
Workforce AI Security

Evaluate this workflow with Aona

Where Aona can help

Aona's supported usage visibility can contribute leads for an offboarding inventory. Deployed data controls can support the organization's policy while users remain in scope, with the actual route and configuration verified.

What to confirm

Aona is not the provider's identity lifecycle or workspace-transfer system. It does not by itself revoke external credentials, close personal accounts or certify that every AI-related access path has ended.

Turning this policy into an operational rollout?

Discuss the teams, devices and AI tools in scope, who will own the policy, and which deployment and evidence requirements need to be met before rollout.

FAQ

Questions about this workflow

It may address one access path. Verify the provider arrangements, shared workspaces and connected credentials involved. The responsible administrators should establish what the identity change actually revokes in that deployment.
Technical evaluation

Turning this policy into an operational rollout?

Discuss the teams, devices and AI tools in scope, who will own the policy, and which deployment and evidence requirements need to be met before rollout.

Offboard Employees From Approved AI Tools | Aona AI