Notifications
Clear all
Topic starter
24/06/2026 7:27 pm
TL;DR: Ghost agents are AI agents that keep operating after their human creator leaves, because their own API keys, service accounts, or tokens remain valid and outside standard offboarding flows, according to 1Kosmos. The failure is not just lifecycle hygiene but an ownership assumption collapse: many IAM programmes still assume deactivating a person also ends the access of what they created.
NHIMG editorial — based on content published by 1Kosmos: Ghost agents and runtime identity governance for AI agents
Questions worth separating out
Q: What breaks when an AI agent outlives the employee who created it?
A: The break point is accountability.
Q: Why do ghost agents complicate offboarding and recertification?
A: They complicate both because standard lifecycle processes are built around people, not autonomous workflows with separate credentials.
Q: How can security teams tell whether an AI agent is still governed properly?
A: Look for a current named owner, a visible inventory entry, documented credentials, and a revocation path tied to employment status or sponsorship changes.
Practitioner guidance
- Build a separate agent offboarding path Create a decommissioning workflow for AI agents that is independent of employee offboarding and includes credential revocation, owner validation, and service-side disablement for every agent instance.
- Bind every agent to a current accountable owner Require each agent to have one living owner in the identity system, with automated alerts when the owner leaves, changes role, or loses eligibility to sponsor the workflow.
- Inventory agent-owned credentials and stored secrets Scan configuration files, secrets managers, code repositories, and workflow platforms for agent credentials, then classify them by owner, scope, and expiry so orphaned access can be removed.
What's in the full article
1Kosmos's full post covers the operational detail this analysis intentionally leaves for the source:
- How its runtime authentication model ties agent credentials to the verified human owner
- The step-by-step kill switch flow when an employee account is deactivated
- Examples of how ghost agents survive standard rotation and access review cycles
- The compliance framing the vendor uses for GDPR and SOC 2 accountability
👉 Read 1Kosmos's analysis of ghost agents and AI offboarding risk →
Ghost agents and AI offboarding: what breaks in IAM controls?
Explore further
25/06/2026 4:43 am
Ghost agent governance exposes a runtime ownership gap, not just an inventory gap. The core failure is that many identity programmes can tell you who created an agent but cannot stop the agent once its owner leaves. That leaves a separate machine identity active after the human identity has been closed. Practitioners need to treat agent existence and agent execution as different control planes.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: Who is accountable when a ghost agent makes a bad purchase or change?
A: Accountability should rest with the current business owner and the control process that allowed the agent to remain active after the human creator left. If there is no current owner, the organisation has a governance failure, not just a technical one. That is why agent lifecycle controls must be explicit and auditable.
👉 Read our full editorial: Ghost agents expose a runtime governance gap in AI identity
