AI agent leaver workflows expose the NHI offboarding gap

At a glance

What this is: This is an analysis of why AI agent offboarding fails in practice, showing that leaver workflows for non-human identities break down where credentials live outside connected identity systems.

Why it matters: It matters because IAM, PAM, and NHI programmes still assume revocation follows a predictable termination path, while agent access can persist across APIs, SaaS tools, and disconnected systems.

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.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Opnova's analysis of AI agent offboarding and the NHI leaver gap

Context

AI agent offboarding is the control problem that appears when a non-human identity is no longer needed but its access still exists. In this case, the primary weakness is not authentication or initial provisioning. It is the lack of a reliable, enterprise-wide leaver workflow for agent credentials, tool connections, and direct permissions.

The article argues that human-style termination processes do not translate cleanly to agents because access is distributed across API keys, OAuth grants, service accounts, and disconnected applications. That makes the primary governance question one of coverage, not intent, and it is a familiar failure mode for NHI programmes that still rely on manual tickets and partial integrations.

Key questions

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. AI agents often hold access across disconnected applications, raw API keys, and vendor-issued grants, so the same workflow leaves credentials active after the project ends. The failure is coverage, not intent, and the revocation step is frequently missed.

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. That means offboarding has to infer retirement from behaviour or enforce it manually, which is much weaker than a human HR termination event. The result is persistent access that outlives the work.

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. If the team can only prove that a ticket was closed, not that the grant disappeared from the target application, the offboarding control is not effective. Verification must happen where access exists.

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.

Technical breakdown

Why AI agent offboarding breaks in disconnected applications

AI agents often accumulate access across systems that do not share a common deprovisioning path. A human leaver workflow can trigger from HR through an IdP, but an agent may hold direct database permissions, raw API keys, and OAuth grants that never touch SCIM. That means the termination event exists only in fragments. If revocation depends on every system being centrally connected, the process fails exactly where enterprise software is most fragmented: legacy tools, ad hoc integrations, and vendor-specific admin consoles.

Practical implication: map every disconnected system an agent can touch and require a revocation path that does not depend on a single IdP connector.

Credential inventory as the real leaver control

The central technical requirement is not a policy document but an inventory of what the agent can actually use. That includes service accounts, short-lived tokens, long-lived API keys, certificates, and vendor-issued OAuth grants. Without that inventory, offboarding becomes guesswork because the security team cannot know what to revoke. The article’s core point is that access persists when the inventory is distributed across teams, spreadsheets, and vendor portals rather than registered at issuance.

Practical implication: maintain a centralized, per-agent credential register so revocation can be verified against known entitlements rather than assumed.

Verification matters more than declared revocation

Revocation is not complete when a workflow says it succeeded. For NHI governance, the important question is whether the target system still shows the identity, the token, or the grant. This is especially true for disconnected systems where the control plane may not have a live view of the resource being decommissioned. The article’s strongest operational lesson is that verification must be performed in the target system, not inferred from the deprovisioning system’s log entry.

Practical implication: require post-revocation verification in the destination application, not just an offboarding ticket closure.

Threat narrative

Attacker objective: The objective is to retain usable non-human access after the agent should have been offboarded, keeping dormant credentials available for later misuse or accidental harm.

1. Entry occurs when an AI agent is given legitimate operational access through tools such as API keys, OAuth grants, or MCP-style connections.
2. Credential access persists after the project ends because the agent’s entitlements are not centrally revoked across disconnected applications.
3. Impact follows when dormant access remains active long enough for misuse, data exposure, or uncontrolled changes in production systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

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.

The assumption that an identity can be cleanly fired was designed for humans, not autonomous or semi-autonomous systems. That assumption fails when the actor is a non-human identity that keeps running until a person intervenes, because there is no natural resignation event and no guarantee that the system of record sees every credential. The implication is that access governance must be built around revocation observability, not around human employment semantics.

Vendor access without lifecycle offboarding: The article exposes a named failure mode where vendor-issued or tool-specific credentials outlive the project, the engineer, or the application that created them. That is not just orphaned access, it is orphaned accountability, because nobody owns the last revocation step once the primary team moves on. The practitioner conclusion is that offboarding must be tied to entitlement ownership at issuance, not left to end-of-project memory.

Disconnected applications are where NHI offboarding most often fails, and that is why coverage beats policy. SCIM and HR-triggered workflows work only for the integrated top layer of the stack. The real exposure sits in long-tail SaaS, admin consoles, internal tools, and direct API access that never enter the same deprovisioning path. Security teams should assume that any system outside the revocation plane is a standing offboarding blind spot.

Dormancy should be treated as a governance signal, not a benign state. The article rightly treats inactivity as evidence that an agent may already be retired in practice even if its credentials remain live. That is an NHI lifecycle issue, not just a hygiene issue, because idle identities accumulate silent risk. Practitioners should use dormancy to surface forgotten access before it becomes an incident.

From our research:

• 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.
• 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 Ultimate Guide to NHIs.
• From our research: Review the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that make offboarding measurable, not assumed.

What this signals

Offboarding for AI agents will keep failing wherever entitlement ownership is unclear. The programme-level lesson is that leaver workflows need a complete credential map and a verified revocation path, not just an IdP integration. For identity teams, that means every disconnected system becomes a governance exception until it is brought into the offboarding plane.

The article’s strongest forward signal is that lifecycle governance is becoming the control boundary for NHI risk, not a back-office admin process. Teams that still treat dormant agent access as a cleanup task will keep inheriting residual privilege. The better model is to classify agent retirement as a revocation event with evidence, ownership, and auditability.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, leaver workflows must assume access is scattered by design. That is why the named concept here is offboarding coverage gap: the gap between who should lose access and which systems can actually enforce it.

For practitioners

• 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.
• Treat dormancy as a retirement trigger Flag agents that have not executed for a defined period and move them into review before their credentials become forgotten standing access.

Key takeaways

• AI agent offboarding fails when enterprises assume human termination logic will remove non-human access automatically.
• The scale of the problem is already visible in dormant and unreleased credentials that remain active long after work ends.
• The control that matters most is verified revocation in every destination system, especially where the identity platform has no direct reach.

Key terms

• AI Agent Offboarding: The process of removing an AI agent’s access, credentials, and tool connections when it is no longer needed. In practice, this means revoking every entitlement the agent can use, then confirming removal in the target systems, not just in the identity platform.
• Coverage Gap: A governance failure where an identity process exists in principle but does not reach all the systems where access was created. For NHI programmes, coverage gaps usually appear in disconnected applications, vendor portals, and direct API access that never enter the normal deprovisioning path.
• Dormant Identity: A non-human identity that is no longer actively used but still has valid access. Dormancy is risky because it looks harmless while preserving credentials, permissions, and trust relationships that can still be abused or accidentally triggered.

Deepen your knowledge

AI agent offboarding and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building leaver controls for disconnected applications and machine identities, it is worth exploring.

This post draws on content published by Opnova: Blog Leaver for AI Agents, which examines why AI agents often remain active after projects end. Read the original.