Offboarded employees leave behind hidden non-human identity risk

At a glance

What this is: This is an offboarding guide showing that employee departures often leave behind active non-human identities, stale secrets, and unmanaged automation access.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern what employees create and own, not just what their human accounts can sign into.

By the numbers:

• 53% of IT leaders are terrified by the risk of a cyberattack through an unmanaged account when an employee is not properly deprovisioned.
• 75% of companies reported having machine identities without dedicated personnel managing them, increasing vulnerabilities to data loss and compromised access.
• 82% of 1,100 executives at large enterprises plan to integrate AI agents within the next three years.
• 45:1.

👉 Read Token Security's guide to offboarding employees and the NHIs they leave behind

Context

Offboarding is supposed to end access cleanly, but that assumption breaks when employees leave behind non-human identities such as API keys, OAuth tokens, SSH keys, service accounts, and AI agents. Those identities can survive in cloud platforms, CI/CD systems, IdPs, and SaaS applications long after the person is gone, which means the real governance problem is not just human deprovisioning but machine identity lifecycle control.

The article argues that traditional IAM workflows were built for people, not for identities created by code, pipelines, automation tools, or AI systems. Once those identities are scattered across environments without ownership, revocation becomes slow, attribution becomes unclear, and the organization inherits an attack surface that standard offboarding processes do not see.

Key questions

Q: How should security teams offboard non-human identities when an employee leaves?

A: Treat the employee departure as a full identity lifecycle event. Inventory every machine credential the person created, inherited, or can still influence, then transfer ownership, rotate secrets, and revoke access in the same workflow. The goal is to remove operational reach from cloud, SaaS, CI/CD, and automation environments before the human account disappears.

Q: Why do orphaned service accounts and tokens create so much risk after offboarding?

A: They create risk because access can persist after employment ends, often with no accountable owner and no automatic expiration. A single unrevoked token can preserve access to repositories, cloud resources, or workflows, which turns a routine departure into a standing privilege problem. That is why offboarding must include machine identity revocation, not just account disablement.

Q: What breaks when employee offboarding does not include machine identity cleanup?

A: The governance chain breaks at ownership, visibility, and revocation. Teams may disable the human account while leaving valid API keys, OAuth tokens, or service accounts active in production systems. In practice, that means the organisation has ended the person’s login, but not their ability to act through the identities they created.

Q: Who should be accountable for NHIs after an employee exits?

A: The accountable owner should be the person or team that can actually revoke, rotate, or transfer the identity without waiting for the former employee. If no such owner exists, the identity is not governed. Offboarding is the moment to assign that responsibility, because after the employee leaves, accountability becomes harder to reconstruct.

Technical breakdown

Why orphaned non-human identities persist after offboarding

Orphaned NHIs persist because their lifecycle is often detached from HR-triggered offboarding. A human account can be disabled on departure, but the related secrets, service accounts, and automation credentials may remain active in cloud consoles, repositories, and SaaS tools. This is an ownership problem as much as an authentication problem: if nobody is assigned to track, rotate, or revoke the identity, it effectively becomes immortal. In practice, the gap widens when teams create credentials in scripts, pipelines, or integrations without registering them in a central inventory.

Practical implication: build offboarding checks that enumerate machine identities, not just human accounts.

How stale secrets and shared credentials expand the attack surface

Stale secrets are risky because access can outlive the employee who originally created it and remain usable across multiple systems. Shared accounts, embedded keys, and long-lived tokens are especially dangerous when they are copied into CI/CD pipelines or repositories, because one forgotten credential can expose production data or enable destructive actions. The article’s core technical point is that detection without rotation is incomplete. If a secret is still valid after offboarding, the compromise window remains open even when the human account is gone.

Practical implication: inventory exposed secrets and revoke or rotate them as part of the employee exit workflow.

Why AI agents and automation need lifecycle governance

AI agents and automation tools create a harder offboarding problem because they can continue executing with stale permissions after the employee leaves. If those identities still have access to Jira, cloud roles, or internal workflows, they may trigger actions based on obsolete logic or outdated authorisation. That turns offboarding into a control-plane issue, not merely an account closure issue. The article correctly treats AI agents as part of the NHI surface, because their operational value comes from persistent access, but their risk comes from persistence without oversight.

Practical implication: tie automation and agent ownership to named custodians and revoke inherited permissions on exit.

Threat narrative

Attacker objective: The attacker wants to exploit abandoned machine access to reach systems, data, or automation paths that should have been closed at offboarding.

1. Entry occurs when an employee creates or is granted machine credentials such as API keys, OAuth tokens, SSH keys, or service accounts during normal work.
2. Escalation happens after the employee leaves and those credentials remain valid, allowing continued access to cloud systems, repositories, SaaS apps, or automation workflows.
3. Impact follows when stale NHIs are used to access data, run automations on incorrect logic, delete resources, or abuse excess privileges at scale.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Employee offboarding is now an NHI lifecycle problem, not just an HR control. The article shows that departure workflows which end at disabling human accounts leave the more dangerous assets untouched: tokens, keys, service accounts, and agent credentials. That is a governance failure because the organization has not actually ended the employee’s operational reach. Practitioners should treat offboarding as a full identity inventory and revocation event across human and machine access.

The control failure here is orphaned machine identity ownership. NHIs created by people but governed by nobody persist because the lifecycle model assumes a stable custodian will inherit them. In reality, many credentials are scattered across cloud, CI/CD, and SaaS systems with no accountable owner and no revocation path. This is a classic NHI governance gap under OWASP-NHI and NIST CSF thinking: access cannot be governed if ownership is not explicit. The practitioner conclusion is that ownership assignment must be part of creation, not an afterthought at exit.

Standing machine access outlives human employment and creates hidden privilege debt. The article’s warning about excessive permissions and unreleased credentials describes a measurable governance debt, not just a cleanup task. The longer privileged NHIs remain active after the employee leaves, the more they resemble dormant backdoors with business legitimacy. Teams should read this as a privilege lifecycle failure that compounds over time and directly raises blast radius.

AI agents make the offboarding assumption collapse visible. Offboarding policies were designed for identities whose access can be reviewed after the fact, but AI agents can keep acting with stale permissions and stale logic once the human operator is gone. That assumption fails when the actor is autonomous enough to keep executing without the former employee’s active presence. The implication is not merely tighter cleanup, but a rethink of what it means to retire an identity that can keep initiating actions.

Hidden NHI inventory is the named concept this article sharpens. The problem is not only unrevoked access, but the inability to see every machine identity an employee created, inherited, or influenced before departure. Without that inventory, ownership transfer, rotation, and deprovisioning are partial controls. Practitioners need a lifecycle model that treats discovery as the prerequisite to accountability.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• GitGuardian found that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For lifecycle governance, see NHI Lifecycle Management Guide for the ownership, rotation, and offboarding controls that make revocation operational.

What this signals

Hidden NHI inventory: offboarding programmes now need a complete picture of where employee-created machine identities live, who owns them, and which workflows still depend on them. When 45:1 is the operating ratio for NHIs versus humans, exit processes that only touch HR systems will always miss part of the attack surface.

The practical shift is toward lifecycle controls that join IAM, PAM, and secrets management into one exit process. That means discovery before revocation, ownership before transfer, and automation before the next employee leaves with an unknown set of credentials still active in production.

For practitioners

• Map every employee-linked machine identity before offboarding. Build a departure checklist that inventories API tokens, OAuth grants, SSH keys, service accounts, cloud roles, and automation credentials tied to the employee across cloud, GitHub, SaaS, and internal tooling.
• Assign a named owner to each NHI at creation. Do not wait for exit day to discover who owns an identity. Require a responsible custodian for each secret, service account, or agent credential so revocation and transfer are possible when roles change.
• Revoke long-lived secrets as part of the exit workflow. Rotate API keys, tokens, and shared credentials immediately after departure, then confirm that CI/CD pipelines, GitHub repositories, Slack, Jira, and SaaS integrations no longer hold valid access.
• Review AI agents for inherited permissions and stale logic. Identify automations and AI agents that continue to run after the employee leaves, then verify whether they still have valid credentials, active workflows, or access paths that should be terminated.

Key takeaways

• The article shows that offboarding fails when organisations stop at human accounts and ignore the machine identities the employee created or influenced.
• The scale of the issue is material because NHIs can persist across cloud, CI/CD, and SaaS environments with no dedicated owner and no automatic revocation path.
• The control that changes the outcome is complete lifecycle governance, including discovery, ownership assignment, secret rotation, and access revocation before the employee exit is closed.

Key terms

• Non-Human Identity: A non-human identity is any machine or software identity used to authenticate and act inside an environment, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. It can hold access independently of a person and therefore requires its own lifecycle, ownership, and revocation controls.
• NHI Lifecycle Management: NHI lifecycle management is the discipline of creating, owning, reviewing, rotating, transferring, and retiring machine identities across their full useful life. It matters because a secret or service account that is never formally offboarded can remain active long after the original business purpose has ended.
• Orphaned Credential: An orphaned credential is a secret, token, key, or account that remains active without a clear responsible owner. In practice, it is a governance failure that turns a former employee’s access into a lingering security exposure, especially when the credential is embedded in pipelines, repositories, or SaaS integrations.
• Hidden NHI Inventory: Hidden NHI inventory describes machine identities that exist in the environment but are not fully discovered, mapped, or attributed to an owner. This creates blind spots during offboarding because security teams cannot revoke what they cannot see or transfer what they cannot attribute.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step offboarding checklist for employee-owned machine identities across cloud, SaaS, and developer tooling
• Detailed guidance on rotating API keys, OAuth tokens, SSH keys, and shared secrets after departure
• Practical inventory and ownership transfer approach for NHIs created by scripts, pipelines, and AI agents
• Token Security's visibility and risk graph workflow for prioritising revocation and remediation

👉 Token Security's full post covers the offboarding workflow, ownership transfer steps, and secret revocation detail.

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.