A retired non-human identity that still retains access because revocation or cleanup failed. In agent environments, ghost identities are especially risky because they can continue to call systems long after the business owner believes the asset is gone.
Expanded Definition
Ghost identities are retired Non-Human Identities that should have been decommissioned but still hold valid access. They often appear after a service, integration, workload, or AI Agent has been replaced, migrated, or abandoned. In practice, the identity itself is not “active” from a business perspective, yet its credentials, tokens, certificates, or permissions continue to work.
Definitions vary across vendors on whether a ghost identity must be fully unreachable, merely unowned, or still able to authenticate. No single standard governs this yet, so operators should treat the term as a lifecycle failure state rather than a narrow technical category. The important distinction is that the identity is no longer expected to exist, but it still has an operational path into systems. That makes it different from a dormant account, which may be intentionally paused, and different from an active service account that still has a current owner and purpose. The most common misapplication is treating a migrated or deprecated workload as harmless when its credentials remain valid in production.
For baseline identity governance, the broader guidance in NIST Cybersecurity Framework 2.0 is useful because ghost identities are fundamentally a detect, protect, and recover problem, not just an IAM cleanup task.
Examples and Use Cases
Implementing ghost identity control rigorously often introduces cleanup overhead, requiring organisations to weigh operational agility against the cost of continuous inventory and revocation discipline.
- A CI/CD pipeline is replaced, but its API key remains in a secrets vault and continues to deploy artifacts long after the pipeline owner has moved on.
- An AI Agent is retired after a pilot ends, yet its tool credentials still authorize database queries, creating a hidden persistence path.
- A contractor-managed service account is never removed after offboarding, so the identity survives the engagement and keeps accessing storage or ticketing systems.
- A cloud workload is migrated to a new account, but the old certificate remains valid and is reused by a forgotten integration.
- A postmortem shows that a decommissioned integration was still present in production, similar to patterns discussed in the JetBrains GitHub plugin token exposure analysis and other 52 NHI Breaches Analysis cases.
In governance terms, ghost identities are often uncovered during access reviews, incident response, or migration audits rather than during normal operations. They also intersect with Zero Trust thinking because a system cannot enforce strong verification if a retired identity still has standing access. The lifecycle issue is described in the Top 10 NHI Issues research, while NIST Cybersecurity Framework 2.0 helps frame the need for asset visibility, access control, and recovery validation.
Why It Matters in NHI Security
Ghost identities matter because they create invisible residual access. They defeat least privilege, undermine offboarding, and make it harder to prove that a workload, integration, or agent has actually been removed. In NHI environments, those risks are amplified because machine credentials are often long-lived, widely distributed, and embedded in automation. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why retired identities so often persist.
That gap is not theoretical. If a ghost identity still has permissions, it can be exploited by attackers, reused by another team, or accidentally triggered by legacy automation. The presence of valid secrets outside a managed lifecycle also complicates incident response because responders must determine whether the access path is still live, where it is used, and who owns it. The operational lesson aligns with the broader NHI guidance in the Ultimate Guide to NHIs and the risk patterns documented in the Cisco DevHub NHI breach.
Organisations typically encounter a ghost identity only after a breach, audit failure, or failed decommissioning review, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Ghost identities stem from failed secret and lifecycle revocation controls. |
| NIST CSF 2.0 | PR.AC-4 | Standing access from retired identities violates least-privilege access management. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous verification, not trust in old credentials. |
Treat retired NHI credentials as untrusted and enforce continuous revalidation and revocation.
