Offboarded employees leave behind hidden non-human identity risk

At a glance

What this is: This blog explains how employee offboarding leaves hidden non-human identities behind, with active machine credentials and agent identities often surviving after the human account is closed.

Why it matters: IAM and security teams need to treat offboarding as a cross-identity lifecycle problem, because unmanaged NHIs extend access, ownership and audit gaps beyond human departure.

Context

Employee offboarding is not just a human access problem. The harder governance failure is what happens to the machine identities that employee created, owned or could still influence after departure.

In cloud, CI/CD, SaaS and AI environments, those identities can include tokens, API keys, SSH keys, service accounts and agent-driven automations. When ownership is unclear, revocation is inconsistent and lifecycle controls stop at the person rather than the identity asset, the access trail remains open.

For IAM and NHI programmes, that means the offboarding process must be evaluated as an identity lifecycle control across human and non-human access, not as a final HR step.

Key questions

Q: What breaks when offboarding only covers human accounts and not NHIs?

A: Human-only offboarding leaves behind active machine access through tokens, keys, service accounts and agent identities. That creates orphaned credentials with no accountable owner, which means access can persist in cloud, CI/CD and SaaS systems after the employee exits. The result is hidden attack surface, not a clean deprovisioning event.

Q: When should organisations prioritise NHI revocation over employee account closure?

A: They should do both together, but NHI revocation must be treated as equal priority because closing the human account does not remove embedded secrets or delegated automations. Where a departing employee has created cloud roles, API keys or AI agents, those machine identities can remain active even after the directory account is disabled.

Q: What are the signs that offboarding has missed machine identities?

A: Common signs include long-lived tokens in repositories, service accounts with no current owner, duplicated keys in pipelines, and automations that still run after the employee leaves. If the security team cannot quickly identify who owns each non-human identity, the offboarding process has already failed at inventory and accountability.

Q: How should security teams offboard AI agents when projects end?

A: They should retire the identity, revoke keys and tokens, remove any control-plane registration, and verify that no downstream workflow still trusts the agent. Offboarding has to be a formal governance event, not an informal note in a project tracker, because lingering access is how ghost agents remain active.

Technical breakdown

Why orphaned NHI ownership survives employee exit

An orphaned NHI is a non-human credential or account that no longer has an active, accountable owner after an employee leaves or changes role. The technical problem is not only that the identity still exists, but that no system can reliably answer who can revoke it, rotate it, or attest to its necessity. In distributed environments, these identities are created in scripts, pipelines, cloud consoles and SaaS integrations, then copied into other tools without central lifecycle control. That creates hidden persistence even when the human account is closed.

Practical implication: build explicit ownership transfer into offboarding so every machine identity has a named steward before the employee departs.

How stale credentials keep working in cloud and CI/CD

Machine identities often depend on reusable secrets such as OAuth tokens, API keys and SSH keys. If those credentials are embedded in repositories, pipelines or productivity tools, they can continue authenticating long after the employee has left. Unlike human sessions, which can be terminated through a single deprovisioning event, these credentials may be distributed across multiple systems and copied into automation workflows. That makes revocation a discovery problem as much as an access problem.

Practical implication: inventory and revoke credential copies in source control, build systems and collaboration tools as part of the exit workflow.

Why AI agent identities widen the offboarding gap

AI agents introduce a newer class of NHI that can continue executing automations, calling tools or using stale permissions after the employee who created them is gone. The risk is not just unauthorized access, but ongoing execution based on outdated logic and inherited scope. If those agents are not assigned, reviewed and constrained like other machine identities, they can keep triggering workflows in Jira, SaaS platforms or cloud services without a current business owner. That creates a post-exit control gap that traditional HR-led offboarding does not see.

Practical implication: include AI agent accounts, their delegated permissions and their triggered automations in the offboarding inventory.

Threat narrative

Attacker objective: Maintain persistent, unowned machine access that can be reused for unauthorized data access, automation abuse or cloud compromise.

1. Entry occurs when an employee creates or configures machine identities, such as tokens, keys, service accounts or AI agents, during normal work.
2. Credential access persists after exit because those identities remain active in cloud, CI/CD, SaaS and collaboration systems.
3. Escalation happens when overprivileged or unmanaged credentials are reused, embedded in pipelines or left with inherited access that no one owns.
4. Impact is hidden access to systems, data, automations and cloud resources long after the employee has left.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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 is now an identity lifecycle problem, not a human deprovisioning task. The article shows that employee exit does not end access if the employee created tokens, keys, service accounts or agents that continue operating elsewhere. That breaks the old HR-led assumption that disabling the human account closes the security event. Practitioners should treat offboarding as a multi-identity lifecycle process spanning human and non-human access.

Orphaned NHI ownership is the control failure hidden inside offboarding. NHIs without named owners cannot be cleanly reviewed, transferred or revoked, which means governance degrades into guesswork. This is the failure mode that creates hidden attack surface across cloud, CI/CD and SaaS. The practical implication is that ownership must follow the identity, not the employee record.

Machine identity lifecycle control must cover AI agents as well as classic secrets. The article correctly extends offboarding risk to AI agents, because they can keep executing automations after the human creator leaves. That widens the governance scope from static secrets to runtime identity behaviour. The implication is a broader lifecycle model that tracks creation, delegation, inherited permissions and retirement across all non-human actors.

Ephemeral human access does not solve persistent machine access. An organisation can deprovision a user in minutes and still leave behind weeks or months of access through embedded credentials, shared accounts and untracked automations. That is a distinct NHI governance gap, not a generic access-control issue. Practitioners should reset their offboarding metrics around machine ownership closure, not just user disablement.

Hidden access outlives employment when lifecycle controls stop at the directory. The article points to a structural disconnect between HR processes and the environments where NHIs actually live. Cloud consoles, Git repositories, SaaS platforms and AI workflows each preserve different remnants of access. The practitioner takeaway is simple: if offboarding does not reach those systems, the identity was never fully offboarded.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Hidden NHI risk often begins at offboarding, not at compromise. When lifecycle controls stop at human deprovisioning, the real exposure sits in the identities that employee created, copied or delegated into other systems. That is why machine identity governance has to be part of leaver processing, not a separate security project.

Identity blast radius is the more useful planning metric here. A departing employee may leave behind a small number of human accounts but a much larger cluster of tokens, keys, roles and agents. The programme question is no longer who left the company, but how far their access footprint spread before they did.

Offboarding gaps expose the difference between visibility and control. Seeing a service account or token in an inventory is not enough if there is no owner, no revocation path and no retirement rule. The next step for practitioners is to shift from discovery to closure, so access cannot outlive accountability.

For practitioners

• Map employee-owned NHIs before departure Inventory every token, API key, SSH key, service account and AI agent linked to the employee across cloud, CI/CD, SaaS and collaboration tools before the exit date.
• Transfer ownership explicitly Assign each surviving NHI to a named team or individual, and record the transfer in the offboarding workflow so revocation and review have a current owner.
• Revoke and rotate machine credentials immediately Remove access for all employee-created secrets, including credentials embedded in pipelines, repositories and chat tools, then rotate any shared or duplicated values.
• Include AI agents in offboarding controls Treat agents, automations and delegated workflows as lifecycle assets, and disable or re-authorise them when the human creator leaves or changes responsibility.

Key takeaways

• The core problem is not employee departure itself, but the machine identities that remain active after the human account is closed.
• The article shows that cloud, CI/CD, SaaS and AI environments can preserve hidden access long after offboarding is complete on paper.
• The control gap is ownership and lifecycle closure for NHIs, which means employee exit processes must include inventory, transfer and revocation.

Key terms

• Orphaned NHI: An orphaned NHI is a non-human identity that remains active without a clear owner, business purpose, or lifecycle path. These identities often survive employee departures, application changes, or missed deprovisioning steps, which makes them difficult to review and risky to leave in place.
• Machine identity lifecycle: Machine identity lifecycle is the full governance process for a non-human identity from creation to retirement. It includes provisioning, access scoping, rotation, renewal, offboarding, and auditability, and it fails when any one of those steps is handled manually or inconsistently.
• Ownership Transfer: Ownership transfer is the point at which an extension changes hands, either through sale, account compromise, or developer handoff. It matters because the extension can keep the same name, rating, and install base while becoming a materially different security object after the transfer.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.

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.