TL;DR: Improper offboarding remains the top non-human identity risk, and AI agents are now exposing why: dormant credentials, disconnected applications, and vendor-dependent revocation leave access active long after projects end, according to Opnova. The real failure is not policy design but coverage, because access review and deprovisioning models assume a clean termination event that agents do not produce.
NHIMG editorial — based on content published by Opnova: Blog Leaver for AI Agents, which examines why AI agents often remain active after projects end
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when an AI agent is offboarded like a human employee?
A: A human leaver workflow assumes there is a single termination event, a clear owner, and a connected identity path.
Q: Why do AI agents complicate leaver workflows for non-human identities?
A: AI agents complicate leaver workflows because they do not resign, do not self-report dormancy, and may hold access in systems that are invisible to the IdP.
Q: How do security teams know whether AI agent offboarding is working?
A: They know it is working when every entitlement can be traced to a live owner, revoked in the destination system, and confirmed as removed after the workflow completes.
Practitioner guidance
- Build a per-agent offboarding register Record every OAuth grant, API key, service account, certificate, and direct permission at issuance so offboarding starts from an inventory instead of a search exercise.
- Require destination-system verification Do not close an offboarding case until the target application shows the account, token, or grant has been removed, especially in disconnected admin consoles.
- Create a forced-leaver playbook for misbehaving agents Define who can revoke access immediately when an agent is compromised, destructive, or out of control, and make that path independent of project ownership.
What's in the full article
Opnova's full blog post covers the operational detail this post intentionally leaves for the source:
- A four-part AI agent Joiner/Mover/Leaver model with decommission, emergency termination, and ownership-loss scenarios.
- Specific workflow examples for disconnected applications, including revocation steps that do not rely on SCIM coverage.
- Practical guidance on verifying revocation in target systems and handling dormant agents as retired identities.
- The governance argument for treating AI agent offboarding as a budgetable control with audit and compliance implications.
👉 Read Opnova's analysis of AI agent offboarding and the NHI leaver gap →
AI agent offboarding: what happens when the worker never leaves?
Explore further
Improper offboarding is not a process nuisance, it is the structural failure mode of NHI governance. When access lives in disconnected applications, the enterprise cannot rely on a single termination event to remove it. The article shows that the problem is not whether a workflow exists in theory, but whether every credential path is actually inside the control boundary. Practitioners should treat offboarding coverage as the real measure of leaver maturity.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when an AI agent keeps access after it should have left?
A: Accountability should sit with the team that issued, approved, and maintains the agent’s entitlements, not with the eventual incident responder. If ownership is not assigned at issuance, offboarding becomes a shared assumption and the last revoke never happens. Governance frameworks should make entitlement ownership explicit before the agent goes live.
👉 Read our full editorial: AI agent leaver workflows expose the NHI offboarding gap