AI agent leaver workflows expose the NHI offboarding gap

At a glance

What this is: This is a blog analysis of why AI agent leaver workflows fail, with the central finding that offboarding controls built for humans do not reliably revoke agent access across disconnected applications and vendor-managed credentials.

Why it matters: It matters because IAM, IGA, and PAM teams need a leaver model that can actually terminate non-human access across the full credential estate, not just identity provider-connected apps.

By the numbers:

• 38% of all accounts in the enterprises it analyzed are dormant.

Context

AI agent offboarding is the governance problem that appears when a non-human worker outlives the project, the owner, or the vendor workflow that created it. Human leaver processes rely on a termination event, a clean inventory, and a place to revoke access. AI agents often have none of those properties, especially when their permissions span API keys, OAuth grants, service accounts, and disconnected admin consoles.

The operational gap is not whether a policy exists on paper. It is whether revocation can reach every place the agent authenticated, and whether the organisation can prove that the access is gone. That makes agent offboarding a lifecycle issue for IAM, IGA, and PAM, not just a tooling issue for the team that deployed the model or automation.

Opnova frames this through a JML lens for AI agents, where the leaver stage is the weakest point because the actor may keep running until someone actively stops it. That is typical of the problem, not an edge case: the broader NHI estate already shows that abandoned access is common and persistent.

Key questions

Q: What breaks when AI agents are not included in offboarding?

A: When AI agents are excluded from offboarding, they can keep accessing data and systems after the human owner leaves. That leaves active automation with no accountable owner, no shutdown trigger, and no reliable inventory. The result is persistent runtime access that traditional employee exit processes do not see or remove.

Q: When should organisations prioritise agent offboarding over other NHI work?

A: They should prioritise it when agents touch production systems, customer data, regulated workloads, or disconnected applications that cannot be revoked through one identity provider. In those cases, unfinished offboarding leaves standing access in the places that matter most, and the cleanup cost rises quickly after an incident or owner change.

Q: What are the signs that AI agent authorization is failing?

A: Watch for agents reaching systems outside their intended task, holding broad permissions after the job changes, or producing incomplete audit trails for sensitive actions. If compliance, security, and operations teams cannot reconstruct why an action was allowed, the authorization model is already too weak for governance.

Q: Who should be accountable when an AI agent retains access after a project ends?

A: The accountable party should be the current human sponsor who can explain why the agent still exists and approve its continued access. Creator history is useful, but it is not sufficient once teams change, projects end, or identities are reused. Accountability has to follow operational ownership, not historical creation metadata.

Technical breakdown

Why AI agent leaver workflows break across disconnected applications

A human leaver event usually starts in HR and propagates through identity systems into connected applications. AI agents rarely have that clean control plane. They may authenticate with OAuth grants, service account tokens, direct API keys, certificates, or UI-driven administrative sessions, and each mechanism can sit outside a single deprovisioning path. When the application is not integrated to the identity provider, offboarding becomes a search problem, not a button press. The underlying technical issue is that revocation is fragmented across issuance points, target systems, and vendor caches, so removal must be verified at each layer rather than assumed from one upstream action.

Practical implication: build offboarding coverage around every credential type and target system the agent can reach, not around the identity provider alone.

What makes AI agent offboarding different from human offboarding

Human leaver workflows assume the person leaves, the badge stops working, and the manager can confirm ownership transfer. AI agents do not generate their own departure signal, so dormancy, project closure, or vendor change must be inferred and operationalised. That changes the control design. An agent can be active, dormant, misbehaving, or partially offboarded while still holding valid credentials in several systems at once. In governance terms, the leaver state is not binary. It is a distributed condition across accounts, tokens, permissions, and tool connections that can persist long after the business thinks the project has ended.

Practical implication: treat dormancy, project closure, and ownership loss as explicit triggers for revocation review in the agent lifecycle.

Why revocation verification matters more than ticket closure

Ticket closure is not evidence of access removal. For AI agents, especially in disconnected applications, the only reliable proof is a post-revocation check against the target system or its admin console. A workflow can say an account was disabled while a cached token, secondary API key, or vendor-side grant remains active. That is why verification needs to be built into the leaver workflow itself. The mechanism is simple: create the revocation, then confirm the credential no longer authenticates or appears in the destination system. Without that second step, the organisation only knows that a request was made, not that access actually ended.

Practical implication: require evidence of revocation in the destination application before the offboarding case can close.

Threat narrative

Attacker objective: The objective is not necessarily external intrusion but uncontrolled persistence of non-human access after the organisation believes the actor has been offboarded.

1. Entry occurs when the AI agent is provisioned with multiple credentials across connected and disconnected systems during its active project.
2. Credential access persists because API keys, OAuth grants, service accounts, and direct permissions are not all revoked when the project ends or the owner leaves.
3. Impact follows when the lingering agent credentials continue to authenticate, allowing unwanted actions, data exposure, or destructive changes after the business believes the worker has left.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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 a lifecycle failure, not a documentation problem: The governance model for AI agents breaks when access can outlive the project, the owner, and the termination signal. In human IAM, the leaver event is anchored to a person and propagated from a known source. With AI agents, the leaver event must be inferred across scattered credentials and disconnected systems. The implication is that offboarding has to become an inventory and revocation discipline, not a policy statement.

Partial revocation creates the real control gap: The hard failure is not that an organisation forgets to deprovision one account. It is that the agent’s access is often split across OAuth grants, API keys, service accounts, and vendor-side caches, so the organisation removes some paths and leaves others alive. That is a classic NHI governance blind spot. Practitioners need to recognise that a single termination workflow cannot govern a distributed access surface without complete credential visibility.

Leaver for AI agents is a distinct named concept: it requires revocation, verification, and ownership transfer across every application the agent touched. The phrase matters because the market still treats agent offboarding as an extension of human offboarding, when the actor does not leave in the same way and may not even have a human owner at the end. The practitioner conclusion is straightforward: if the leaver workflow cannot prove access death, it is not a leaver workflow.

Disconnected applications are where governance assumptions go to fail: Identity provider coverage is only part of the control surface, and the long tail of admin consoles, legacy SaaS, and raw API integrations is where agent credentials persist. That is why offboarding has to be measured by actual revocation reach, not by whether SCIM or SSO exists. For identity programmes, the important question is coverage, not intent.

Agent offboarding now defines whether identity governance is real or symbolic: If an organisation can hire an AI worker but cannot fire it everywhere it exists, then the lifecycle model is incomplete. That is true across OWASP-NHI, zero trust access assumptions, and broader IAM governance. The field should treat this as a test of operational maturity, because incomplete leaver coverage turns every project-end into a potential standing-access event.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Partial revocation is the risk most programmes underestimate: AI agent access is often distributed across credentials and disconnected applications, so removing one path does not end the identity. Identity teams should stop measuring offboarding by ticket closure and start measuring whether every credential type was actually revoked in the destination system.

Agent leaver governance will separate mature programmes from symbolic ones: Human offboarding models assume a clean termination event, but AI agents may need dormancy rules, ownership-loss triggers, and post-revocation checks to close the loop. The organisations that operationalise that coverage first will have a smaller standing-access problem when agents begin to operate at scale.

According to the 2026 Infrastructure Identity Survey, 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, so leaver workflows will become a mainstream governance requirement rather than a niche control.

For practitioners

• Define an AI agent leaver playbook Create a written offboarding path for each agent class, with named owners, required checks, and explicit revoke steps for production, customer data, and regulated systems.
• Inventory every agent credential at issuance Register each OAuth grant, API key, service account, certificate, and direct permission when it is created so revocation has a complete target list.
• Verify revocation in the destination system Confirm the token, account, or grant no longer authenticates in the target console or application before the offboarding case closes.
• Treat dormancy as a termination trigger Flag agents that have not executed in the defined retirement window and route them into the leaver workflow instead of leaving them in place.
• Separate vendor revocation from enterprise closure Require evidence that vendor-side caches, delegated grants, and externally hosted tokens were removed, not just that an internal ticket was closed.

Key takeaways

• AI agent offboarding is a lifecycle governance problem because access can persist across multiple credentials after the work is finished.
• The article shows that dormant or partially revoked non-human access is common enough to make coverage, not policy intent, the deciding factor.
• Revocation has to be verified in the destination system, or the organisation only knows a ticket was closed, not that access actually ended.

Key terms

• Agent Offboarding: The process of formally retiring an AI agent by revoking credentials, detaching tools, closing access paths, and recording evidence that authority has ended. In NHI programs, offboarding is as important as onboarding because abandoned access is still active risk.
• Offboarding: Offboarding is the controlled retirement of a workload, service account, token, certificate, or other non-human identity when it is no longer needed. It includes revoking credentials, removing permissions, and verifying that no residual trust path remains available to attackers.
• Revocation Validation: Revocation validation is the process of checking whether a certificate or signing authority is still trusted at the moment of use. It matters because a document can appear technically valid while the underlying credential has already been withdrawn or compromised.
• Dormancy Signal: The security value created by a long period of no authentication or no meaningful account activity. Dormancy is not a problem by itself, but it makes later actions easier to detect as outliers. Defenders use the contrast between silence and sudden activity to identify risky account use.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.