What is the difference between shadow agents and ghost identities?

Shadow agents are created outside approved governance, so the organisation may not know they exist or who owns them. Ghost identities are retired agents that still retain access because decommissioning failed. Both are governance failures, but shadow agents are an onboarding problem while ghost identities are a revocation problem.

Why This Matters for Security Teams

shadow agent and ghost identities are both signs that identity governance has fallen out of sync with how work is actually being executed. The distinction matters because the remediation paths are different: shadow agents call for discovery, ownership, and onboarding controls, while ghost identities call for offboarding, revocation, and continuous assurance that access truly ended. In autonomous environments, that gap can become an attack path fast, especially when agent execution authority is tied to secrets, API keys, or service accounts that outlive the intended workflow.

Practitioners should also view this through an agentic AI lens. Once an AI agent can choose tools, chain actions, or request additional access, static RBAC alone is too blunt to describe intent at runtime. Guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both reinforce the need to manage dynamic behaviour, not just static entitlement. NHI governance research from Ultimate Guide to NHIs — What are Non-Human Identities also shows how often organisations lack full visibility into service accounts, which is exactly where both conditions hide.

In practice, many security teams encounter the problem only after an incident review reveals an “unknown” agent still calling production systems long after its owner assumed it was gone.

How It Works in Practice

The operational difference is simpler than the terminology suggests. A shadow agent exists before governance catches up to it. It may be created by a developer, embedded in a workflow, or introduced by an AI tool with its own credentials and permissions. A ghost identity exists after governance should have removed it. The agent is retired, but its tokens, keys, certificates, or service account bindings still work. That means the issue is not just identity creation or deletion. It is lifecycle integrity across discovery, ownership, access, rotation, and decommissioning.

For autonomous systems, current guidance suggests pairing workload identity with runtime policy checks instead of relying only on pre-assigned roles. That aligns well with the direction described in the CSA MAESTRO agentic AI threat modeling framework and the OWASP Top 10 for Agentic Applications 2026. The practical pattern is:

• discover every agent, service account, token, and secret source of truth;
• bind each agent to a named owner and a documented purpose;
• issue just-in-time credentials for specific tasks instead of long-lived secrets;
• set short TTLs and automatic revocation on task completion or workflow exit;
• log runtime decisions so unexpected tool use or privilege escalation can be reviewed.

This is where NHI operations and agentic governance converge. NHIMG research on the Analysis of Claude Code Security and the Moltbook AI agent keys breach shows why exposed or stale keys are operationally dangerous: once an agent can act autonomously, one lingering credential can become repeated access at machine speed. These controls tend to break down when agents are embedded in CI/CD pipelines with overlapping ownership because lifecycle events are hidden inside automation instead of being managed as explicit identity changes.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance rapid agent deployment against stronger revocation discipline. That tradeoff is real, especially when teams want fast experimentation but still need to prevent unknown agents from accumulating access.

There is no universal standard for this yet, but best practice is evolving toward intent-based authorisation and short-lived workload identity. In that model, access is granted at request time based on what the agent is trying to do, not just what role it was born with. That is especially important when agents can behave unpredictably, chain tools, or request new actions after initial approval. The right question is less “What role should this agent have forever?” and more “What task is it performing right now, and does it still need access?”

Edge cases often appear in hybrid estates. For example, a shadow agent may start as a legitimate automation script and later become an unsanctioned autonomous workflow, while a ghost identity may survive because decommissioning succeeded in one system but failed in a secrets store or external API. The OWASP NHI Top 10 and Ultimate Guide to NHIs — 2025 Outlook and Predictions both support the same operational takeaway: visibility, ownership, rotation, and offboarding must be treated as a single control plane, not separate clean-up tasks. Organisations that delay this often find the problem first through an access anomaly, not through planned inventory review.

Related resources from NHI Mgmt Group

• What is the difference between managing human accounts and non-human identities?
• What is the difference between shadow AI and approved SaaS AI usage?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• What is the difference between attack surface management and NHI governance?