Offboarding AI team members: an access-revocation case study
A retrospective on the full offboarding chain for departing AI team members, covering seats, SSO identity, workspace roles, API keys, third-party integrations, automations, and the billing verification that completes the process.
The scenario: a team member departs, and the instinct is to remove their login or change a shared password. In our experience, this is the minimum, not the complete offboarding—the departing member may still hold product seats, SSO identity, workspace roles, API keys, third-party integrations, and owned automations that continue to function after their login is gone.
The offboarding chain: an administrator first inventories the member's products, workspaces, API projects, and authorizations. Then disable the identity and revoke personal tokens immediately; rotate any shared keys the member had access to. Check repositories, CI/CD pipelines, cloud platforms, and servers for stored credentials the member may have added. Before deleting the account, transfer ownership of bots, prompts, knowledge bases, files, and projects under the organization's retention policy.
The assets that most often get orphaned: scheduled automations the member created, webhooks pointing to their personal endpoints, and third-party app authorizations that still have active tokens. Each of these can continue to make API calls or access data after the member is gone. Transfer or revoke them explicitly, and document what was transferred to whom.
The final step is billing verification: does the seat reduction take effect immediately or next cycle, is there a minimum-seat or annual commitment, and is a separate personal subscription still renewing under the member's email? Record the executor, timestamp, revoked items, transfers, and exceptions in an offboarding log. The limitation: some third-party integrations have their own offboarding flows that must be triggered separately, and missing one can leave a live credential active for months.