When an employee is removed from an AI platform organization, revoke their organization membership, interactive login access, active sessions, personal credentials, delegated permissions, privileged roles, and access to AI resources, data, infrastructure, billing, and administrative systems. Shared credentials and production workload identities require ownership transfer and dependency review rather than indiscriminate deletion.
The Short Answer: Revoke Human Access Across Every Control Layer
AI platform offboarding is not complete when a user account disappears from the platform directory. The employee may still have an active browser session, a personal API key, a cloud role, an SSH key, repository access, or permission to administer a connected model-serving environment.
The offboarding event should therefore trigger coordinated action across four control layers:
- Identity: Remove organization membership, directory assignments, local accounts, and alternative login methods.
- Sessions and credentials: Invalidate active sessions and revoke employee-owned tokens, keys, certificates, and cloud credentials.
- AI platform resources: Remove permissions for model endpoints, gateways, datasets, vector stores, model registries, telemetry, billing, and administrative settings.
- Connected infrastructure: Remove access to cloud consoles, GPU infrastructure, clusters, repositories, CI/CD systems, secrets stores, observability tools, and vendor portals.
Privileged and interactive human access should generally be addressed as soon as the authoritative removal event occurs. Automation can reduce delays, but the event source and propagation mechanism will vary across organizations and technology stacks.
Immediate revocation checklist
For the departing employee, revoke or disable the following where applicable:
- AI platform organization and workspace membership
- Identity-provider or directory assignments used to reach the platform
- Local platform accounts and secondary login methods
- Browser, desktop, mobile, and CLI sessions
- Refresh tokens and remembered-device access
- Employee-owned API keys and personal access tokens
- Personal SSH keys, client certificates, and cloud credentials
- Delegated permissions and temporary access grants
- Administrator, billing, security, and infrastructure roles
- Access to model endpoints, inference gateways, and routing policies
- Access to prompt libraries, evaluations, model configurations, and registries
- Access to datasets, object stores, vector stores, and proprietary context
- Access to telemetry, logs, dashboards, and usage data
- Access to code repositories, CI/CD systems, ticketing tools, and vendor portals
- Secrets-vault access and permission to retrieve shared credentials
Account deletion alone is insufficient if any of these access paths remain valid.
Control matrix: access type, default action, and continuity check
| Access category | Examples | Default action | Timing | Continuity check |
|---|---|---|---|---|
| Organization identity | Organization membership, workspace membership, directory assignment | Remove the employee and associated human permissions | At the authoritative removal event | Confirm the user no longer appears in active membership or assignment records |
| Interactive sessions | Browser sessions, CLI sessions, refresh tokens, remembered devices | Invalidate where supported | Immediately, especially for privileged users | Test that existing sessions can no longer reach protected resources |
| Personal credentials | API keys, personal access tokens, SSH keys, certificates, cloud credentials | Revoke credentials owned by the employee | Immediately or according to the risk of continued access | Search connected systems for credentials issued to or registered by the employee |
| AI resource permissions | Model endpoints, gateways, registries, datasets, vector stores, telemetry, billing | Remove direct and inherited human permissions | With account removal | Check workspace, project, resource, and administrator-level assignments |
| Connected-system access | Cloud consoles, clusters, CI/CD, repositories, observability, ticketing, vendor portals | Revoke the employee's accounts, roles, and sessions | Coordinated with core identity removal | Confirm that downstream applications received or applied the removal event |
| Workload and shared identities | Service accounts, automation tokens, deployment identities, shared secrets | Review, transfer ownership, and rotate when necessary; do not delete automatically without dependency analysis | Begin immediately, change according to operational risk | Validate production dependencies, accountable ownership, secret exposure, and recovery paths |
The final row is intentionally different. A service account is not a human account simply because a departing employee created or maintained it. Disabling a production identity without checking dependencies can interrupt inference endpoints, deployment automation, monitoring, or scheduled jobs.
Remove Organization Membership, Login Paths, and Active Sessions
Identity-layer revocation closes the employee's direct paths into the AI platform. It should be treated separately from application permissions and infrastructure access because removing one layer does not necessarily remove the others.
Organization and identity-provider assignments
Remove the employee from the AI platform organization, workspaces, projects, teams, and groups. Where access is assigned through a central directory or identity provider, remove the assignment that permits login to the platform.
The authoritative removal signal may originate in an HR system, corporate directory, identity platform, or manual administrative process. Whatever the source, organizations should determine:
- Which event is authoritative for termination or role removal?
- How quickly does that event reach the AI platform?
- Does group removal also eliminate direct resource assignments?
- What happens if a downstream system is unavailable when the event occurs?
- How are failed or delayed deprovisioning actions detected and retried?
These questions matter in multi-tenant environments because an individual may belong to several organizations, projects, or customer workspaces. Removal from one tenant should eliminate access to that tenant without unintentionally changing an unrelated workload identity or another valid organizational relationship.
Local accounts and alternative login methods
Central identity removal does not necessarily disable local accounts. Look for platform-native usernames, emergency accounts, secondary email addresses, linked developer identities, command-line credentials, and other login paths established outside the primary directory.
An effective process inventories these alternative paths before offboarding occurs. Otherwise, a central account may be disabled while a local password or secondary identity continues to provide access.
Emergency or break-glass accounts need separate governance. They should not be assigned as an employee's everyday identity, and a departure should prompt a review of whether the person knew, stored, or could retrieve the relevant credentials. Changes should follow the organization's continuity procedure so that emergency access remains available to authorized personnel.
Browser sessions, CLI sessions, refresh tokens, and remembered devices
Removing organization membership should be paired with session invalidation where the systems in the organization's stack support it. Review:
- Active web and desktop sessions
- CLI authentication sessions
- Mobile application sessions
- Refresh tokens capable of obtaining new access tokens
- Remembered-browser or trusted-device grants
- Cached credentials in developer tools
- Temporary credentials issued before the removal event
Session duration affects the residual-access window. A disabled login may stop new authentication while an existing session remains usable until expiration. Organizations should evaluate whether their identity, AI platform, and infrastructure systems can terminate sessions promptly and whether those actions cover both user interfaces and programmatic tools.
Revoke Employee-Owned Keys, Tokens, and Credentials
Personal credentials should be attributable to an individual owner and revocable without disrupting unrelated workloads. Common examples include model API keys, personal access tokens, repository tokens, SSH keys, client certificates, database credentials, cloud access keys, and credentials stored in local development environments.
For each credential category, determine whether the employee could use it independently of their interactive account. Removing a user from an organization may not invalidate a copied API key or cloud credential unless the credential itself is revoked.
The offboarding process should also examine secrets-vault permissions. Removing access to a vault prevents future retrieval, but it does not invalidate secrets the employee previously viewed or stored elsewhere. Rotate a shared secret when exposure and operational risk justify the change, then update dependent applications through a controlled rollout.
Avoid treating every credential associated with the employee as personal. Use ownership and runtime behavior to distinguish among:
- Personal credentials: Issued to the employee for individual use; normally revoke.
- Delegated credentials: Issued for a bounded task or temporary role; revoke the grant and related tokens.
- Shared credentials: Used by more than one person or application; transfer accountability and rotate when appropriate.
- Workload identities: Used by services, agents, pipelines, or inference infrastructure; retain or replace only after dependency review.
This classification supports both access control and operational continuity.
Remove AI Resource Roles and Delegated Permissions
Application-layer access can survive identity changes when permissions are assigned directly, inherited through groups, delegated by another administrator, or stored in a separate project-level control system.
Review permissions for resources such as:
- Model endpoints and managed model APIs
- Inference gateways and routing policies
- Model registries and deployment configurations
- Prompt templates, evaluation suites, and experiment assets
- Fine-tuning or adaptation artifacts where used
- Datasets, vector stores, object storage, and proprietary context
- Usage telemetry, traces, logs, and observability dashboards
- Quotas, budgets, billing records, and payment settings
- User administration, policy configuration, and tenant settings
Pay particular attention to inherited access. Removing a direct role will not close access obtained through a team, group, cloud role, repository organization, or delegated administrator relationship.
Administrative and billing roles deserve high urgency because they can affect other users, platform policy, resource consumption, or financial controls. The same principle applies to permissions that allow a user to create credentials, invite members, change routing rules, deploy models, alter logging, or expose an endpoint.
Revoke Access to Connected Infrastructure and Operational Systems
An AI platform commonly depends on systems outside its own organization boundary. Offboarding should follow those dependency paths rather than stopping at the application account.
Connected access may include:
- Cloud consoles and project subscriptions
- GPU hosts, schedulers, clusters, and orchestration environments
- Virtual machines, bastion hosts, and remote administration tools
- Code repositories and package registries
- CI/CD pipelines and deployment systems
- Secrets managers and configuration stores
- Data warehouses, object storage, and databases
- Monitoring, logging, alerting, and incident-response tools
- Ticketing, documentation, and collaboration systems
- Domain, DNS, networking, and certificate-management consoles
- External model, infrastructure, and software vendor portals
The correct action depends on how access is granted. Remove personal accounts and roles directly. Remove the employee from groups that grant inherited access. Revoke personal tokens issued by connected systems. For shared or machine credentials, identify dependencies and transfer ownership before rotating or replacing them.
This is especially important in private LLM serving environments, where platform operations may span model routing, GPU scheduling, deployment automation, telemetry, and cloud or on-premises infrastructure. The employee's application account may represent only one of several control points.
Preserve Continuity When Transferring Workload Ownership
Offboarding must remove human access without breaking production services. Before changing service accounts, automation credentials, or shared configurations, assign a new accountable owner and document the dependent workloads.
Ownership transfer may be necessary for:
- Inference endpoints and routing configurations
- Scheduled evaluation or data-processing jobs
- Deployment pipelines and repository protections
- Dashboards, alerts, and on-call rules
- Model registry entries and release approvals
- Cloud projects and infrastructure resources
- Vendor accounts and support cases
- Budget alerts, usage reports, and billing workflows
A practical continuity review asks who can maintain the resource after departure, where its secrets are stored, what systems depend on it, how it can be recovered, and whether the employee had access to credentials that now require rotation.
Do not leave production resources owned only by a deactivated identity. At the same time, do not delete an automation or service identity solely because the employee originally created it. Transfer ownership, rotate potentially exposed secrets, validate dependencies, and monitor the resulting changes.
Verify That Revocation Actually Took Effect
An offboarding workflow should produce a verifiable result rather than relying only on a completed task ticket. Use the logs, access reviews, membership records, credential inventories, and administrative records available across the organization's stack.
Verification should answer four questions:
- Identity: Can the former employee still authenticate through any central or local login path?
- Application: Do direct, inherited, delegated, or privileged AI platform permissions remain?
- Credentials: Are any employee-owned keys, tokens, certificates, or cloud credentials still valid?
- Infrastructure: Does the individual retain access to connected cloud, cluster, repository, secrets, deployment, or operational systems?
Teams should also review activity around the removal window. The objective is to identify unexpected access, recently created credentials, ownership changes, or delayed downstream revocation. This review helps catch control gaps, but it should not be treated as a substitute for timely deprovisioning.
For higher-risk departures, organizations may choose a staged sequence: restrict privileged access, terminate active sessions, revoke personal credentials, remove general membership, transfer operational ownership, rotate exposed shared secrets, and verify downstream systems. The exact order should reflect the employee's role, access level, and potential operational impact.
Evaluating Offboarding Controls for a Private LLM Environment
When evaluating an AI platform, map responsibility across the identity provider, AI application, model access layer, private infrastructure, and operational tooling. No single control plane should be assumed to remove every external account, token, session, or cloud permission.
Useful evaluation questions include:
- What system provides the authoritative employee-removal event?
- Which human access paths can be revoked through policy, and which require separate administration?
- How are personal API credentials distinguished from workload credentials?
- Can ownership of endpoints, automations, dashboards, and configurations be transferred cleanly?
- Which permissions exist at organization, workspace, project, resource, and infrastructure levels?
- How can administrators verify that downstream access was removed?
- What happens to a running workload when its human owner is deactivated?
- Which controls remain the customer's responsibility in managed API and private deployment models?
Token Forge Cloud offers Managed Model APIs as an API-first path for teams evaluating managed model access before moving toward private serving capacity. Token Forge Cloud Private LLM Inference focuses on private deployment and serving-layer optimization, including areas such as private routing, policy-aware access, telemetry, quantization, and GPU scheduling.
Those serving-layer controls are relevant to defining enterprise AI boundaries, but serving-layer control does not by itself establish employee lifecycle automation. Organizations should explicitly map offboarding responsibilities across their identity systems, Token Forge Cloud environment, cloud or on-premises infrastructure, and connected operational tools.
Next Step
A sound AI offboarding design removes human access quickly while protecting the availability of production workloads. Evaluate the complete chain—from identity and sessions to API credentials, model resources, private infrastructure, and workload ownership—rather than treating account deletion as the final control.
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.