Access rights that remain active after the business need has ended. They are a governance failure, not just an administrative nuisance, because they expand the attack surface and undermine Zero Trust by preserving access that should already have been removed.
Expanded Definition
Ghost permissions are active entitlements that outlive the business purpose that justified them. In NHI and IAM programs, the term covers stale API key scopes, service account roles, token grants, and delegated access paths that were never removed when a workflow, owner, or integration changed. No single standard governs this term yet, but the operational meaning is clear: access exists in the control plane even though the need no longer exists in the business process.
Ghost permissions differ from ordinary overprovisioning because the issue is persistence after obsolescence, not just overly broad access at creation time. They also differ from credential expiration problems, where access ends automatically. In practice, ghost permissions often appear after application retirements, team reorganisations, cloud migrations, or automation changes that leave old authorisations behind. The OWASP Non-Human Identity Top 10 treats this class of failure as a core lifecycle and privilege governance risk. The most common misapplication is assuming that offboarding a user, job, or system also removed every related NHI entitlement, which occurs when identity lifecycle and permission lifecycle are managed separately.
Examples and Use Cases
Implementing ghost-permission controls rigorously often introduces review overhead and workflow friction, requiring organisations to weigh faster change delivery against tighter entitlement hygiene.
- An application team decommissions a microservice, but its service account still has read access to production storage and logs.
- A CI/CD pipeline is rebuilt, yet the old deployment token remains valid and can still publish to registries.
- A contractor leaves a project, but the shared API key used for testing remains active in a config file and automation script.
- A cloud migration replaces one integration with another, but legacy role assignments are never removed from the old workload identity.
These patterns are easier to miss when access is distributed across IAM, secrets stores, and infrastructure-as-code. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why ghost permissions persist. The control question is not whether the credential still works, but whether the underlying business justification still exists. That distinction is consistent with the lifecycle-oriented guidance in the NIST SP 800-53 Rev. 5 Security and Privacy Controls around access enforcement, review, and revocation.
Why It Matters in NHI Security
Ghost permissions are dangerous because NHIs operate at machine speed and often hold broad, persistent access. One stale entitlement can become a durable foothold for lateral movement, data exfiltration, or destructive automation. This is especially serious in Zero Trust environments, where every standing permission weakens the model by preserving trust that should have been withdrawn. NHIMG reports that 97% of NHIs carry excessive privileges and that only 5.7% of organisations have full visibility into their service accounts, which means hidden access often goes unchallenged until an incident forces discovery.
Ghost permissions also complicate compliance and incident response. If permissions are not tied to owners, expiry, or review cadence, teams cannot reliably prove least privilege or demonstrate that access was removed after a change. That is why NHIMG’s NHI guidance and the Microsoft SAS Key Breach both illustrate how stale credentials and forgotten access paths become operational liabilities. Organisations typically encounter the impact only after an account takeover, unauthorized data access, or a failed audit, at which point ghost permissions become operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Ghost permissions are stale NHI entitlements left active after their purpose ends. |
| NIST CSF 2.0 | PR.AA-04 | Identity and access governance requires removing stale permissions as part of access administration. |
| NIST Zero Trust (SP 800-207) | JA-3 | Zero Trust assumes access is dynamic and should not remain standing without ongoing need. |
| NIST SP 800-63 | AAL2 | Assurance depends on controlling authenticator use and revocation for non-human access paths. |
| NIST AI RMF | AI risk management includes limiting persistent machine access and unmanaged tool permissions. |
Map AI agent permissions to business need and remove stale tool access as part of ongoing risk treatment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
