Permission Drift

Expanded Definition

Permission drift describes the slow, often invisible expansion of access rights for a non-human identity after its original business purpose has changed. In NHI security, it commonly affects service accounts, API keys, tokens, workload identities, and AI agents that inherit rights through role changes, shadow administration, or forgotten exceptions. Guidance varies across vendors on whether permission drift is a subset of privilege creep or a broader lifecycle failure, but the operational outcome is the same: access no longer matches intent. The OWASP Non-Human Identity Top 10 treats overprivilege and weak identity governance as core NHI risks, which is why drift must be reviewed as a control issue, not just a hygiene issue. Strong programs pair entitlement review with ownership, expiration, and offboarding logic, as outlined in Ultimate Guide to NHIs — Key Challenges and Risks. The most common misapplication is treating a static role assignment as safe even when the workload, environment, or integration has changed.

Examples and Use Cases

Implementing permission drift controls rigorously often introduces administrative overhead, requiring organisations to weigh tighter access governance against the cost of continuous entitlement review.

• A build service account begins with read-only access to one repository, then accumulates write permissions across multiple projects after temporary troubleshooting access is never revoked.
• An application token used for customer support exports later gains database query rights during a migration, creating an access path that no one revalidates after go-live.
• An AI agent with tool access is granted additional APIs to complete a pilot, then keeps those permissions when the pilot ends and the agent moves into production.
• A third-party integration inherits broad cloud permissions because a legacy exception was created for launch speed and never revisited during quarterly review.
• A service account rotated through multiple teams retains old group memberships, so the current owner cannot explain why the identity can still modify sensitive resources.

In incident response, this pattern is often easier to spot after comparing actual entitlements with the original onboarding ticket or architecture record. That is why Salesloft OAuth token breach is a useful cautionary example of how retained access can become operationally dangerous when a token or integration is not tightly scoped. Teams also use the OWASP guidance to test whether privileges are still necessary, especially when workflows change faster than governance can keep up.

Why It Matters in NHI Security

Permission drift is dangerous because non-human identities do not self-correct. A token, key, or workload identity can continue using granted rights long after the original purpose has ended, and attackers only need one overextended identity to move laterally or exfiltrate data. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes drift a systemic problem rather than an edge case, and the same issue appears in the Ultimate Guide to NHIs — Key Challenges and Risks. For practitioners, the risk is not just overpermission but the failure to prove that access is still justified, especially in fast-moving cloud and agentic environments. Zero Trust Architecture depends on continuously verified, least-privilege access, which is why the OWASP Non-Human Identity Top 10 treats entitlement control as foundational. Organisations typically encounter the business impact only after a compromise, an audit finding, or an outage, at which point permission drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• Runtime Drift
• Privilege Drift