Why do ghost agents complicate offboarding and recertification?

Why Ghost Agents Break Standard Offboarding

Ghost agents complicate offboarding because the usual process is designed to terminate a person, not an autonomous workflow that can keep authenticating long after the employee has left. A human identity review may close cleanly while the agent’s API keys, service account bindings, and delegated tokens remain active. That gap is exactly where hidden persistence forms. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs treats lifecycle control as a core security function, not an admin cleanup step.

The risk is not theoretical. Entro Security found that 91% of former employee tokens remain active after offboarding, which shows how easily machine access survives the human exit. That aligns with broader lifecycle failures documented in the Top 10 NHI Issues and in the NIST AI Risk Management Framework, which both emphasize accountability, traceability, and ongoing monitoring for autonomous systems. In practice, many security teams discover ghost-agent persistence only after an employee has already departed and the agent has continued to call production tools unnoticed.

Why Recertification Misses Autonomous Workflows

Recertification often misses ghost agents because the review process asks managers to attest to people, roles, and business need, while the actual permissions live in CI/CD jobs, orchestration layers, vaults, and tool credentials. If the agent is not represented as a first-class identity, there is nothing obvious to recertify. Current guidance suggests treating the agent as its own reviewable object, with owner, purpose, runtime scope, and expiry tied to each workflow rather than each employee.

That means recertification should verify four things at minimum:

• the agent still has a valid business purpose
• the owning team is current and accountable
• the credential is still needed for the specific task set
• the access path matches the current toolchain and policy

For agentic systems, this is easier when workload identity is the primitive, not shared secrets. The emerging pattern is to issue short-lived credentials and evaluate access at runtime, rather than relying on static RBAC entitlements that age badly in autonomous environments. The OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reinforce runtime governance because autonomous behavior cannot be safely inferred from a static access list. These controls tend to break down when ghost agents are embedded in shared pipelines and no single owner can prove which workflow still depends on the credential.

Operational Gaps, Exceptions, and What Good Practice Looks Like

Tighter offboarding and recertification controls often increase operational overhead, requiring organisations to balance speed of automation against assurance and change-management cost. That tradeoff is real, especially where agents are chained across multiple tools or teams. Best practice is evolving, but it is increasingly clear that ghost agents should be reviewed on a different cadence from employee access, with explicit expiry, automated revocation, and evidence of last use.

One common edge case is the “shared helper” agent that supports several applications. If one team offboards the human sponsor, the other teams may still need the agent, which means revocation cannot be a blanket action. Another edge case is a long-running autonomous job, where a task may outlive the employee who launched it. In those cases, current guidance suggests tying access to workload identity, not personal ownership, and enforcing just-in-time renewal rather than perpetual trust. The NHI Lifecycle Management Guide is useful here, because lifecycle ownership, not just secret rotation, is what closes the gap. For threat context, the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework both support continuous oversight and accountability. Ghost-agent control breaks down fastest in legacy environments where service accounts are undocumented, secrets are reused, and no one can prove who is still relying on the identity.

Related resources from NHI Mgmt Group

• Why do autonomous agents complicate zero trust architecture?
• Why do AI agents complicate zero trust and least privilege models?
• Why do MCP-connected agents complicate zero trust architecture?
• Why do AI agents complicate zero trust architecture assumptions?