Why do ghost agents increase NHI risk more than ordinary dormant accounts?

Why This Matters for Security Teams

Ghost agents are more dangerous than ordinary dormant accounts because they are often not truly dormant. They may still possess valid tokens, API keys, service credentials, or delegated tool access, which means the identity is inactive from a business perspective but still active from a technical one. That gap is especially risky in environments where automation is sprawling and ownership is unclear. The problem is not just unused access, but access that remains quietly executable.

NHIMG research shows how broad this exposure can be: in the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, and only 20% of organisations have formal offboarding and revocation processes for API keys. A ghost agent sitting inside that privilege model can keep reading, calling, and chaining tools long after the project or workflow that created it has ended. That is why the risk is not just residual access, but residual autonomy.

Security teams often miss ghost agents because human lifecycle signals do not apply. There is no resignation, leave request, or badge deactivation to trigger review. In practice, many teams discover the issue only after an API key is abused or a forgotten workflow is used as the easiest path into sensitive systems.

How It Works in Practice

Ordinary dormant accounts are usually visible in identity governance tools because they belong to people with known managers, schedules, and business context. Ghost agents are different. They are often created by developers, CI/CD pipelines, orchestration tools, or AI workflows, then left behind with persistent secrets and broad permissions. The identity may be non-interactive, but the access path can still be fully live.

This is why current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework leans toward runtime control rather than static approval alone. For ghost agents, the practical sequence is:

• Inventory every non-human identity, including service accounts, agent tokens, webhook credentials, and automation principals.
• Map each identity to an owner, workload, and expected expiry so abandoned access is detectable.
• Replace long-lived secrets with short-lived, just-in-time credentials where possible.
• Use workload identity and policy-as-code to decide access at request time, not only at provisioning time.
• Revoke or quarantine identities when ownership, purpose, or workload state is unknown.

For autonomous systems, this matters even more because agents can chain tools, search for alternate paths, and escalate privilege in ways static IAM reviews do not anticipate. NHIMG has documented how quickly this gap becomes operationally real in the Top 10 NHI Issues, especially when secrets are stored outside dedicated vaults or are not rotated on schedule. These controls tend to break down in fast-moving CI/CD environments because ownership is fragmented and secrets are reused across ephemeral workloads.

Common Variations and Edge Cases

Tighter ghost-agent controls often increase operational overhead, requiring organisations to balance revocation speed against deployment stability. That tradeoff is real in platforms with many ephemeral jobs, multi-account cloud estates, or legacy service accounts that cannot be easily tied to a human owner. Current guidance suggests treating those cases as exceptions only when there is a documented compensating control and a clear expiry date.

One common edge case is an agent that looks inactive because it has not logged in, yet still retains indirect access through delegated OAuth grants, cached refresh tokens, or downstream tool permissions. Another is an internal automation account that belongs to a retired application. It is not abandoned in the same way as a forgotten user profile, but it can be just as dangerous if it still reaches production data.

Best practice is evolving toward continuous validation rather than periodic recertification alone. That means combining CSA MAESTRO agentic AI threat modeling framework concepts with identity telemetry so ownership drift, privilege creep, and stale secrets are surfaced before they become incidents. It also means using event-driven revocation when a workload is retired, not waiting for the next quarterly access review. For deeper context, NHIMG’s 2024 ESG Report: Managing Non-Human Identities shows how often NHI compromise is already happening in enterprises, which is why “inactive” should never be assumed to mean “safe.”

There is no universal standard for this yet, but the practical rule is simple: if no one can explain why a ghost agent still exists, it should not retain production access.

Related resources from NHI Mgmt Group

• Why do non-human identities increase zero trust risk?
• Why do secrets create disproportionate risk in NHI environments?
• How should teams reduce the risk from exposed NHI secrets?
• Why do AI agents create more NHI risk than ordinary developer automation?