Workflow-aware offboarding is now an NHI governance problem

At a glance

What this is: This is an analysis of why employee offboarding now has to cover workflows, not just user accounts, because automations can keep acting after the person leaves.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams need one lifecycle model for people and the non-human credentials they create, own, or delegate to.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Unixi's analysis of workflow-aware offboarding and zombie agents

Context

Employee offboarding in an AI-enabled environment is no longer just account disablement, device return, and SaaS seat removal. It now has to include the non-human identities, workflow credentials, and delegated permissions that continue to act after the employee has left. In practice, the primary governance gap is that most offboarding processes still assume the human account is the centre of control.

The article's core point is that a workflow can retain authority through OAuth grants, API keys, service accounts, shared inboxes, and connectors even after the original employee loses direct access. That makes offboarding a lifecycle problem across NHI and IAM, not a single HR or IT step. The typical enterprise starting position described here is unfortunately common, not exceptional.

OWASP defines non-human identities as applications, workloads, APIs, bots, and automated systems that authenticate and authorise access to secured resources. That definition fits the article's workflow example because the automation itself becomes the actor that keeps using credentials, even when the person who created it is no longer present.

Key questions

Q: How should teams offboard workflows that outlive the employee who created them?

A: Treat the workflow as the thing being offboarded, not just the user. Identify every automation, revoke or rotate its delegated credentials, transfer ownership to an accountable business owner, and confirm the workflow still has a valid purpose. If the workflow cannot be owned, retired, or reauthorised, it should be disabled before the leaver process closes.

Q: Why do standard offboarding processes miss non-human identities?

A: Because most offboarding controls are built around human accounts, devices, and SaaS seats. They do not automatically capture OAuth grants, API keys, shared inboxes, webhook secrets, or low-code connectors that continue to act after the employee leaves. That leaves machine authority intact even when the human account has been removed.

Q: What breaks when a departed employee's automation still has valid access?

A: Account disablement no longer equals access removal. The workflow can keep reading records, sending messages, triggering approvals, and exporting data through credentials that were approved when the creator was trusted. The result is an orphaned authority path that can create compliance, operational, and security exposure without any active login by the former employee.

Q: Who is accountable when a former employee still has access after offboarding?

A: Accountability usually sits with IAM, IT, and application owners together, because offboarding failure is a cross-system governance issue. Directory admins may disable the account, but SaaS owners must also invalidate sessions and remove app access. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared control ownership.

Technical breakdown

Why workflow authority survives user offboarding

A workflow can persist independently of the user account that created it because its authority is carried by credentials and integrations, not by the person in the directory. OAuth grants, shared mailboxes, service accounts, webhooks, and API keys can all keep a process alive after HR closes the departure ticket. This creates a split between human lifecycle and machine lifecycle: the person is removed, but the delegated execution path remains valid. In identity terms, the actor that needs governance is the workflow plus the credentials bound to it, not just the departed employee.

Practical implication: inventory every automation with the credentials and data paths that keep it active after the user leaves.

Offboarding gaps in OAuth grants, tokens, and shared automations

The failure mode is not just a stale login, but stale delegated authority. A personal token created in a low-code platform, a connector approved months earlier, or a shared inbox rule can continue to perform reads, writes, and approvals long after the original business context has changed. These credentials often sit outside core identity provider offboarding, which is why account disablement does not equal workflow retirement. The governance problem is ownership, scope, and revocation across multiple control planes, especially when one workflow can touch CRM, data warehouse, and collaboration tools at once.

Practical implication: bind each automation to a named business owner, then revoke or reauthorise its grants when employment changes.

Zombie agents and the audit problem

A zombie agent is an automation that still acts with valid authority but no current human accountability. The risk is amplified when logs show only generic integration accounts or workflow names, because the audit trail may prove activity without proving ownership. That matters for compliance, incident response, and investigation, since the question is not only what happened, but who was responsible for the continuing authority. Once a workflow outlives the employee, the organisation has a living control gap: operationally active, procedurally orphaned, and often invisible to standard access review cycles.

Practical implication: require workflow-level audit trails that preserve creator, approver, last reviewer, and current owner.

Threat narrative

Attacker objective: The objective is to preserve operational control through an automation path that remains trusted after the human user leaves.

1. Entry occurs when a worker creates or approves a workflow using OAuth grants, API keys, shared inboxes, or connectors that outlive the employee relationship.
2. Escalation follows when the workflow continues to read CRM data, enrich records, send emails, or trigger approvals with authority no longer tied to an active human owner.
3. Impact lands when the organisation discovers the departed employee's automation still moving data and making business decisions after offboarding should have ended that authority.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• 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

Offboarding must now be treated as a workflow lifecycle control, not a user lifecycle checkbox. The article shows that a departed employee can lose their account while the automation they built still operates through valid non-human credentials. That breaks the old assumption that disabling the person disables the authority. For IAM and IGA teams, the practitioner conclusion is clear: workflow ownership and credential ownership must be governed as first-class lifecycle objects.

Human offboarding is designed for stable authority, but delegated automation creates authority that persists independently of the employee. That persistence is exactly why account disablement, mailbox archival, and SaaS seat removal are incomplete controls. The model fails because it does not capture the continuing execution rights held by OAuth grants, service accounts, and shared connectors. Practitioners must recognise that the real control boundary is the workflow, not the leaver record.

Workflow-aware offboarding is the named control gap this article exposes. A workflow can retain CRM access, messaging rights, and data export capability even after the original creator leaves, which means the organisation has preserved capability without preserving accountability. That is an NHI governance failure with direct audit and operational consequences. The implication is that lifecycle governance has to follow the automation wherever it runs.

Offboarding reviews should be built around entitlement provenance, not just entitlement presence. Knowing that a token exists is less useful than knowing who created it, why it was granted, what systems it can reach, and who is accountable today. The article's scenario shows why provenance matters more once workflows can chain actions across tools. Practitioners should treat provenance as the only reliable way to decide whether a workflow is still legitimate.

OWASP NHI guidance on improper offboarding maps directly to this problem, but the article sharpens the risk into a broader enterprise pattern. Long-lived secrets, overprivileged integrations, and human use of non-human identities become harder to see once automations are embedded in normal business processes. The practitioner conclusion is to govern all post-employment authority as NHI lifecycle risk, not as a one-off HR exception.

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.
• A second finding from the same research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which explains why lifecycle delays remain operationally dangerous.
• For the governance lens behind this article, see NHI Lifecycle Management Guide for lifecycle controls that extend beyond human offboarding.

What this signals

Workflow-aware offboarding is becoming a structural requirement for identity programmes because human lifecycle controls do not govern delegated automation by default. When a leaver can still be represented by OAuth grants, service accounts, and shared automations, the control model has to shift from account closure to authority closure. The practical signal for teams is simple: if your JML process does not enumerate automations, it is already incomplete.

Workflow authority debt: a useful way to describe the accumulated risk when automations keep operating after ownership, approval, or business need has changed. That debt grows quietly because the system still works until a token expires or a review catches it. Teams should expect this to surface first in audit findings, unexplained exports, or failed incident containment.

The article reinforces a broader NHI trend already visible across identity programmes: lifecycle discipline matters more than the form factor of the identity. The relevant question is no longer whether the actor is human or machine, but whether the organisation can prove who owns the authority today. That is where offboarding, recertification, and PAM governance converge.

For practitioners

• Create a workflow inventory at offboarding time Record every automation the employee created, approved, or inherited, along with owner, business purpose, data scope, credential type, and last review date.
• Revoke delegated grants before closing the leaver ticket Check OAuth grants, personal access tokens, service accounts, shared inbox rules, webhook secrets, and low-code connectors before the employee's identity is fully closed.
• Transfer or retire automations explicitly Move each workflow to a named business owner or retire it, then reissue credentials under managed workload identities instead of leaving personal tokens in place.
• Add workflow-level recertification to JML controls Require periodic review of agents, integrations, and connectors so that authority is reapproved with the same discipline used for human access and NHI lifecycle management.
• Monitor post-offboarding activity for stale authority Alert on continued exports, approval triggers, failed token use, and unexpected API calls after role change or departure, then route findings to the current owner and security.

Key takeaways

• The article's central warning is that offboarding now has to remove workflow authority, not just user accounts.
• The operational risk is persistent non-human access through OAuth grants, service accounts, tokens, and shared automations that survive the employee.
• The control that would have limited this failure is workflow-level lifecycle governance with clear ownership, revocation, and recertification.

Key terms

• Workflow-aware offboarding: Workflow-aware offboarding is the process of removing, transferring, or reauthorising automations when the human creator or approver leaves or changes role. It extends lifecycle governance beyond user accounts to the credentials, connectors, and business logic that keep non-human actions running.
• Zombie Agent: An AI agent that remains active after its original purpose, project, or owner has ended. It still has valid credentials and can keep acting inside enterprise systems, which makes it an identity lifecycle problem as much as an AI operations problem.
• Policy provenance: The ability to trace an AI-driven decision back to the exact policy, document, or record that informed it. In identity governance, provenance is what makes a recommendation reviewable and defensible. Without it, even a correct answer may fail audit or incident investigation requirements.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• The full workflow-aware offboarding model for inventories, ownership mapping, and approval chains
• Specific examples of how HR, IT, and security should trigger automation reviews after role change or departure
• The article's discussion of how shared inboxes, connectors, and service accounts should be reauthorised or retired
• The closing recommendations for audit routing, alerting, and post-change monitoring of stale workflow activity

👉 Unixi's full article covers the offboarding gap, workflow authority, and the control failures behind stale automations.

Deepen your knowledge

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