They should treat AI tools like any other access path that can retain data or permissions after a user leaves. That means inventorying connected AI services, checking OAuth grants and shared content, and verifying revocation at the data and token level. If the tool can still reach corporate information, offboarding is not complete.
Why This Matters for Security Teams
SaaS offboarding is no longer just a helpdesk checklist. When users work with AI tools, a departing employee can leave behind OAuth grants, shared workspaces, embedded connectors, cached prompts, and exported data that still point back into corporate systems. That creates a second offboarding problem: revoking the person’s account does not automatically revoke the AI tool’s access path. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that access and asset inventory must be tied to ongoing protection, not just account status. NHIMG research shows why this matters at scale: in The 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remained active after offboarding, which is exactly the kind of residual access AI workflows can preserve if they are not explicitly reviewed.
The practical risk is simple: an AI tool can continue acting on stale trust long after the user is gone. That may mean reading shared files, summarising internal content, or calling APIs with a token that was never revoked. Security teams often miss this because the access is indirect, hidden behind integrations rather than visible in the user directory. In practice, many security teams encounter AI-enabled offboarding gaps only after a former employee’s connected tool has already retained access to sensitive data, rather than through intentional revocation testing.
How It Works in Practice
A sound offboarding process treats AI tools as part of the user’s access graph. Start by inventorying every SaaS application, browser extension, chatbot, and workflow automation service the person used, then trace any connected OAuth grants, API keys, service accounts, file shares, and delegation rules. The goal is not only to disable the human account, but to cut off the AI-mediated paths that can still read, write, or export corporate information. That is consistent with the lifecycle discipline described in NHIMG’s NHI Lifecycle Management Guide and the broader control themes in Top 10 NHI Issues.
Operationally, the response should include:
- Revoking third-party OAuth consent, not just disabling the user login.
- Invalidating tokens and refresh tokens at the provider and application layer.
- Checking shared folders, project spaces, and AI knowledge bases for lingering memberships.
- Reviewing whether any AI agent or automation inherited the user’s permissions through delegation.
- Confirming that exported chat histories, prompt logs, and indexed documents are removed or retained under policy.
Where possible, use the same lifecycle checkpoints you would apply to any NHI: discovery, classification, privilege review, revocation, and post-offboarding validation. In a mature programme, that validation should include evidence that the AI tool cannot still reach internal data even if its integration token is replayed. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward repeatable identity, access, and recovery discipline rather than one-time deletion. These controls tend to break down when AI tools are self-service connected by end users, because security teams often never see the original grant event.
Common Variations and Edge Cases
Tighter offboarding often increases friction, requiring organisations to balance fast employee exit handling against the need to review every connected AI service. That tradeoff is real, especially where departments adopt tools outside central IT approval. Current guidance suggests treating exceptions explicitly rather than assuming a universal control set will fit every SaaS estate.
Some environments need extra care. In sales, marketing, and research teams, users may connect AI tools to shared workspaces, CRM exports, or document repositories that are still needed by the team after departure. In those cases, security teams should separate the user’s personal grant from the team’s operating access and reissue permissions through a managed owner. For high-risk tools, consider whether access should move to a controlled service account or a governed integration rather than an employee-owned token. That is often the safer pattern, but there is no universal standard for this yet.
The clearest breach lessons come from token abuse and over-permissioned integrations. NHIMG’s Salesloft OAuth token breach shows how OAuth material can become the real access boundary, while the DeepSeek breach illustrates the broader danger of exposed secrets and lingering data paths in AI environments. When a departing user has connected multiple AI tools to the same SaaS data source, a single missed grant can preserve access even after account deprovisioning, which is why offboarding must be validated at both the token level and the data layer. This guidance breaks down most often in federated SaaS estates where local admins can reconnect AI services without central security visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses lifecycle revocation and stale non-human credentials. |
| NIST CSF 2.0 | PR.AC-4 | Access entitlements must be removed across SaaS and AI integrations. |
| NIST AI RMF | AI governance should account for retained access and downstream data exposure. |
Revoke AI-linked tokens, keys, and grants during offboarding and verify no residual access remains.
Related resources from NHI Mgmt Group
- How should security teams reduce risk from AI agents and developer tools that use secrets locally?
- How should security teams govern AI tools that connect to SaaS data?
- How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
- How should security teams handle SaaS offboarding when non-human identities are involved?
