They are built to govern people, not separate runtime identities. A manager can certify a user’s access and IT can disable the user account, yet an agent with its own API key or token remains outside that review scope. The control failure is that the review population excludes the actor that is still making decisions.
Why the Control Population Is Wrong
Offboarding and access review controls usually start from a human roster, then ask what that person should still be allowed to do. That works for employee access, but ghost agents are runtime actors with their own keys, tokens, or delegated credentials. The review can certify the human account as clean while the actual decision-maker stays outside the review boundary.
The mismatch is not just administrative, it is architectural. If the control system inventories people, roles, or employment status, it will miss identities that were created for automation, inherited by software, or detached from a named owner. Those actors can keep operating after the human lifecycle event that triggered the review has already closed.
A useful way to think about it is that the offboarding event ends employment, not execution authority. If the runtime identity is not tied back to the same lifecycle record, the review has no natural place to inspect it. That is why the failure often shows up as a gap between HR-driven deprovisioning and the separate inventory of non-human credentials, sessions, and service permissions.
Where Review Scopes Break Down
Access reviews fail when the object being certified is the user, but the access path belongs to an agent, integration, or service account. In practice, that means reviewers see a legitimate account with no obvious excess access, yet the agent still holds API keys, refresh tokens, certificates, or vault-issued secrets that continue to authorize actions. The review logic was correct for people and incomplete for autonomous runtime access.
This is especially common when teams treat “offboarding” as account disablement instead of authority revocation. Disabling a directory account does not necessarily revoke bearer tokens, upstream API permissions, cloud roles, or embedded credentials already deployed in workflows. If those credentials can still authenticate, the agent can continue to act long after the human owner has left.
The other break point is ownership. A manager may know who used to sponsor the account, but not which systems consume the credential, which pipeline holds a copy, or which downstream services trust it. Without that linkage, access review becomes a paper exercise over a proxy while the live access path remains active.
Why Ghost Agents Survive the Offboarding Cycle
Ghost agents survive because their lifecycle is often decoupled from the human lifecycle that created them. They are provisioned through code, issued by a platform, or embedded in an application path, so there is no single manager to certify, no clear leaver event to trigger revocation, and no obvious prompt to rotate the secret. The control gap is not lack of intent, it is lack of a complete inventory of all runtime identities.
That gap becomes more serious when the agent uses long-lived secrets or shared credentials. In that case, even a good offboarding process can remove the person from the org chart while leaving the credential usable in scripts, jobs, and integrations. The result is a surviving actor with persistent access and very little visibility.
Once that happens, the old access review model is effectively blind to the remaining authority. The human record may be closed, but the machine record is still open, and the control framework was never built to reconcile both populations together.
Risk and Threat Considerations
Ghost agents create a persistence problem: the credential or token continues to work after the supposed owner has been removed, so attackers, contractors, or abandoned automation can keep using it. The danger is not limited to unauthorized access, it also includes silent privilege retention and hard-to-detect lateral movement through trusted integrations.
Failure mechanism: The offboarding or recertification workflow closes the human lifecycle record, but does not revoke the runtime credential, so the live agent remains authenticated and authorized.
Impact: Access review reports become misleading, dormant integrations stay active, and a compromised or abandoned agent can keep making decisions until the secret is found and rotated.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Ghost agents persist when runtime credentials are not revoked at offboarding. |
| NHI-07 — Long-Lived Secrets | Persistent tokens and keys let agents survive user offboarding. | |
| NHI-10 — Human Use of NHI | Human-centric review processes miss machine actors that outlive user lifecycle events. | |
| Recommendation — Revoke all runtime credentials and agent ownership links during offboarding. Replace long-lived secrets with short-lived, rotated credentials. Separate human account review from non-human runtime access review. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Offboarding depends on removing active accounts and their access paths. |
| IA-5 — Authenticator Management | Ghost agents persist through unrevoked keys, tokens, and certificates. | |
| IA-9 — Service Identification and Authentication | Runtime identities need their own authentication lifecycle, separate from users. | |
| Recommendation — Tie account disablement to complete credential and session revocation. Inventory, rotate, and revoke authenticators when owners depart. Treat service and workload authenticators as first-class lifecycle assets. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity records must cover people and non-human actors to support offboarding. |
| A.5.18 — Access rights | Access rights must be reviewed and removed for surviving runtime identities. | |
| Recommendation — Maintain a complete identity inventory across human and non-human actors. Revoke access rights for all credentials linked to departed users. | ||
Practitioner Guidance
What to verify: Confirm that every offboarded person is linked to all active runtime identities, issued tokens, service principals, API keys, certificates, and vault entries. If the review cannot enumerate those artifacts, it is not a complete offboarding control.
Decision rule: If the credential can still authenticate outside the user directory, treat it as a separate revocation event, not as a user disablement issue. Human deactivation without secret rotation is only partial containment.
Practitioner takeaway: The control must certify the actor that still has authority, not the employee who once sponsored it, otherwise ghost agents remain live after the review says they are gone.