Why do generative AI integrations create offboarding problems?

Why This Matters for Security Teams

Generative AI integrations are not just another app connection. They often sit on top of long-lived OAuth grants, service tokens, API keys, and delegated permissions that were created for a person or team, then quietly inherited by the integration. When the creator changes roles or leaves, the access path can remain intact unless the non-human identity is treated as a first-class asset. That makes offboarding a lifecycle problem, not an HR checklist item.

This is especially risky because AI systems are now part of the attack surface. SailPoint reports that 91% of former employee tokens remain active after offboarding in the wild, which is a strong signal that revocation is still lagging behind operational reality. NHI governance guidance in the NHI Lifecycle Management Guide and the Top 10 NHI Issues both point to the same failure mode: standing access outlives business need. Current guidance from the NIST AI 600-1 Generative AI Profile reinforces that GenAI systems need ongoing governance across their full lifecycle, not only at deployment. In practice, many security teams discover lingering integration access only after data exposure or an audit request, rather than through intentional offboarding.

How It Works in Practice

The offboarding problem starts with how the integration is built. A generative AI workflow may authenticate through a user-consented OAuth grant, a shared API token, or a secret stored in a vault for a chatbot, retrieval pipeline, or agent. If that credential is not bound to a clear owner, expiration rule, and revocation path, the integration survives the employee. The result is a hidden NHI with access that no one feels responsible for until it is too late.

Practical offboarding needs to cover both the human and the workload. That means revoking the user’s delegated consent, disabling any service account or NHI the integration used, rotating downstream secrets, and checking whether the AI tool cached tokens, refresh grants, or connector permissions. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames identity lifecycle as create, operate, rotate, and revoke. For GenAI systems, that revocation step must include prompts, connectors, plugins, and workflow automations that can keep acting even after the original user is gone.

• Inventory every AI integration that uses delegated access or shared secrets.
• Map each grant to a named business owner and a revocation trigger.
• Prefer short-lived credentials and explicit expiry over static long-lived tokens.
• Test whether the integration still functions after user offboarding and secret rotation.

For implementation detail, the NIST AI 600-1 GenAI Profile and the NIST risk guidance both support continuous monitoring and governance over AI-enabled systems. These controls tend to break down when teams use shared enterprise tokens across multiple bots, because one offboarding event can inadvertently disrupt unrelated workloads while leaving other hidden grants active.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance security against workflow continuity. That tradeoff matters because not every AI integration is built the same way, and best practice is evolving rather than universally standardised.

One common edge case is the “team-owned” integration that no single person remembers creating. Another is an agentic workflow that uses refresh tokens to call multiple systems on behalf of a user. In those environments, a simple account disable is not enough, because the agent may continue operating through cached tokens, copied secrets, or another delegated path. This is why NHI offboarding must be tied to privilege review, not just employment status.

There is also a practical distinction between revoking the person and revoking the workload identity. For autonomous systems, current guidance increasingly favours separate workload identity, JIT credentials, and context-aware authorisation rather than static role-based access. That aligns with security lessons from NHI incidents such as the DeepSeek breach and the Microsoft Azure OpenAI service breach, where governance gaps around access and exposure became security issues. For organisations with many shared secrets or overused tokens, offboarding may require coordinated rotation windows, because an aggressive cutover can break production automations while a slow one leaves standing access in place.

Related resources from NHI Mgmt Group

• How should security teams handle SaaS offboarding when users also use AI tools?
• How can organisations reduce the risk of shadow SaaS and shadow AI during offboarding?
• Why do AI agents create more identity risk than ordinary SaaS integrations?
• Why do AI agents create more governance risk than ordinary integrations?