Offboarding pressure exposes the SaaS and AI identity gap

At a glance

What this is: This is a Valence Security analysis of why fast offboarding fails when SaaS, AI, and connected identities sit outside traditional IdP control.

Why it matters: It matters because NHI and IAM teams must govern hidden tokens, integrations, and local accounts that can outlive a terminated employee.

👉 Read Valence Security's blog post on SaaS and AI offboarding under pressure

Context

Offboarding in SaaS and AI environments is not just a user-deletion problem. The real risk is identity and access drift, where local app accounts, integrations, shared files, and external connections remain active after the human relationship ends. That is an NHI governance problem as much as an IAM one, because the accessible surface includes service-like accounts, tokens, and machine-to-machine links that do not disappear when a person is disabled in the identity provider.

Valence Security frames layoffs as a pressure test for visibility, not merely a workflow issue. That starting point is typical of modern SaaS-heavy enterprises, where security teams often inherit access sprawl they never fully mapped. For NHI practitioners, the lesson is straightforward: if you cannot inventory the non-human paths tied to a departing worker, you are not actually offboarding access, you are assuming it has stopped.

Key questions

Q: How should security teams handle SaaS offboarding when users also use AI tools?

A: 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.

Q: What is the difference between disabling a user in the IdP and fully offboarding access?

A: IdP disablement removes central authentication, but full offboarding also removes local application accounts, tokens, integrations, and external shares. In SaaS-heavy environments, those residual paths are often what keep data accessible after departure. Full offboarding requires proof that every usable path has been closed.

Q: Why do layoffs increase insider-risk exposure in SaaS environments?

A: Layoffs compress the time available for review while increasing the chance that long-lived permissions, delegated access, and unmanaged tools are missed. Employees may also have accumulated access across business-managed and self-service apps. The result is a wider residual-access window that can be accidental or malicious.

Q: How can organisations reduce the risk of shadow SaaS and shadow AI during offboarding?

A: They should combine discovery, approval, and revocation workflows so unmanaged tools are found before departure and checked again after access removal. Offboarding should include browser sessions, connected apps, and external sharing paths. If a tool was never inventoried, security cannot assume it is harmless.

Technical breakdown

Why IdP disablement does not close all SaaS access

Disabling a user in the identity provider only removes one authentication path. Many SaaS apps support local credentials, legacy login methods, delegated admin rights, and app-specific tokens that sit outside central SSO control. In parallel, SaaS-to-SaaS integrations can continue to move data even when the original user account is gone. That is why offboarding often fails in distributed environments: access is fragmented across human identity, application identity, and data-sharing links. The control problem is not simply revocation, but proving that every authentication and authorisation path tied to the user has been removed.

Practical implication: Map each departing user across IdP, local app auth, and token-based integrations before closure is considered complete.

Shadow AI and shadow SaaS expand the offboarding surface

Shadow SaaS and shadow AI are unmanaged services that employees adopt without security visibility. These tools may connect through OAuth grants, browser sessions, uploaded data, or embedded automations, which means the access path can persist even after HR and IT actions are complete. The technical issue is not just discovery. It is that unmanaged services often create secondary data stores, caches, and permissions relationships that traditional account deprovisioning never touches. In practice, offboarding now needs to account for where data was sent, which tools received it, and whether those permissions can still be exercised independently of the employee.

Practical implication: Extend offboarding checks to unmanaged services, OAuth grants, and external collaboration paths, not just corporate accounts.

Why data shares and integrations behave like non-human identities

External file shares, API tokens, and SaaS integrations act like non-human identities because they can outlive the person who created them and retain access without continuous human presence. If a share link stays public or a token remains valid, the data path remains open regardless of employment status. This is especially dangerous during layoffs because time pressure encourages partial cleanup. The failure mode is not always malicious. Often it is a stale permission set that continues to work because no one validated the downstream dependencies. That is an identity lifecycle problem, not just an endpoint or email issue.

Practical implication: Treat shared links, API tokens, and connected apps as lifecycle-managed assets that require explicit revocation and verification.

Threat narrative

Attacker objective: The objective is to preserve or abuse residual access long enough to retain data, exfiltrate information, or maintain a foothold after departure.

1. Entry occurs through SaaS accounts, OAuth grants, shared links, or local credentials that were never tied to centralized offboarding.
2. Escalation happens when the departing user retains access to files, integrations, or admin functions beyond the termination event.
3. Impact follows when sensitive data is exfiltrated, overshared, or left reachable by external parties after the organization believes access has ended.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Offboarding in SaaS and AI has become an identity lifecycle problem, not a checkbox task. Disabling a user in the IdP removes only the most visible path. The real security question is whether local credentials, integrations, file shares, and unmanaged services have also been revoked and verified. Practitioners should treat departure events as full lifecycle closures, not account deletes.

Identity blast radius is the right concept for layoff-driven risk. A departing employee often has years of accumulated access across sanctioned and unsanctioned tools, and that access can persist through tokens, external shares, and app-specific permissions. The blast radius is determined by what remains reachable after deprovisioning, so governance must shift from user-centric thinking to access-path-centric thinking.

Shadow AI makes the offboarding gap harder to see and easier to miss. AI copilots, automations, and connected third-party services can retain permissions to content long after the user has left. That creates a durable trust relationship that standard HR-triggered workflows do not address. Security teams need lifecycle controls for machine access, not just human access.

Fast layoffs do not justify incomplete revocation. The operational pressure to act quickly increases the chance of partial cleanup, but partial cleanup is precisely what turns offboarding into insider-risk exposure. Mature programmes separate termination timing from access verification and require evidence that every data path has been closed. The practitioner takeaway is to build revocation proof into the workflow itself.

Visibility is now the limiting factor in non-human identity governance. If teams cannot see local SaaS accounts, unmanaged integrations, or external shares, they cannot credibly claim they have secured offboarding. This is where NHI governance and SaaS governance converge. The programmatic response is to inventory, classify, and continuously verify every non-human access path tied to a user lifecycle event.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader lifecycle view, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that reduce residual access.

What this signals

Identity lifecycle governance now has to include SaaS-integrated machine access. The reader programme should assume that user offboarding, token revocation, and integration shutdown are one control family. When services, shares, and automations remain active after termination, the practical failure is not visibility alone but the absence of verified closure across the access chain.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the residual-access problem is not limited to HR-driven exits, according to the Ultimate Guide to NHIs. That means offboarding needs to extend into developer and SaaS operations, where forgotten credentials can continue to work after the person is gone.

Identity blast radius: the amount of data and access that remains reachable after a user leaves. Teams should use this concept to prioritise which SaaS apps, shares, and integrations require validation first, especially where AI copilots and third-party connectors can silently extend access.

For practitioners

• Build a complete offboarding inventory Inventory IdP accounts, local SaaS logins, OAuth grants, third-party integrations, and external file shares for every departing user before termination is closed. Use the inventory to confirm that each access path was removed or retained for a documented business reason.
• Revoke and verify token-based access Shut down orphaned tokens, delegated app credentials, and machine connections, then validate that the token no longer authorises access to data or APIs. Verification matters because revocation without confirmation leaves stale trust in place.
• Scan for shadow SaaS and shadow AI exposure Identify unsanctioned services that received corporate data or were granted browser-based or OAuth access, then add them to the offboarding checklist. This catches the tools that HR and the IdP never see.
• Require evidence of access closure Make termination complete only when security has evidence that local accounts, external shares, and active integrations are no longer usable. A checklist that does not include validation is an assumption, not control.

Key takeaways

• Offboarding failures in SaaS and AI are usually lifecycle failures, not single-control failures.
• Residual access persists through local logins, integrations, and public shares, which makes identity closure a verification exercise.
• Security teams need discovery and revocation evidence before they can say a departing user no longer has usable access.

Key terms

• Identity Lifecycle Governance: Identity lifecycle governance is the discipline of managing access from creation through change, suspension, and removal. In NHI contexts, it must cover users, service accounts, tokens, integrations, and AI-connected access paths so that rights do not outlive the business need that created them.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and permissions that remain reachable if an identity is not fully removed. It is a practical way to measure residual access after offboarding and to prioritise which credentials, shares, and integrations require immediate verification.
• Shadow AI: Shadow AI is the use of AI tools or automations that security teams have not discovered or approved. These services often connect to corporate data through browser sessions, OAuth grants, or embedded workflows, which makes them a hidden part of the offboarding and access-control problem.
• Residual Access: Residual access is any permission, token, account, or data path that continues to work after a user should no longer have access. It is a common failure mode in SaaS-heavy environments because deprovisioning one system does not automatically shut down all downstream connections.

Deepen your knowledge

SaaS offboarding under pressure is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to close identity gaps across users, tokens, and integrations, it is worth exploring.

This post draws on content published by Valence Security: Offboarding Under Pressure, how to keep SaaS and AI data secure during layoffs. Read the original.