The gradual accumulation of access beyond what a user or workload currently needs. It usually happens because initial approvals are never fully removed or recertified. In practice, permission creep is a lifecycle failure that turns temporary exception access into de facto standing privilege.
Expanded Definition
Permission creep is the cumulative drift from approved access to excessive access, usually when temporary elevation, inherited group membership, or one-time exception handling is never fully unwound. In NHI environments, it affects service accounts, workload identities, API keys, and agent permissions just as much as human users. It is best understood as a lifecycle control failure, not a one-time provisioning mistake. The concept aligns closely with least privilege and access review expectations in OWASP Non-Human Identity Top 10, but usage in the industry is still evolving because some teams treat it as a simple IAM hygiene issue while others treat it as a governance defect spanning recertification, rotation, and offboarding.
Ultimate Guide to NHIs — Key Challenges and Risks shows why this matters: NHIs often accumulate power faster than teams can observe or review them. The most common misapplication is assuming access will naturally decay after a project ends, which occurs when approvals, group assignments, and embedded credentials are never explicitly removed.
Examples and Use Cases
Implementing permission creep controls rigorously often introduces operational friction, requiring organisations to weigh faster delivery against the cost of tighter access governance.
- A CI/CD service account receives write access during a migration and keeps it after the migration ends because no expiry was set.
- An AI agent is granted tool access for testing, then later used in production with the same broad permissions, even though its task scope changed.
- A workload identity inherits access through a nested group, and periodic reviews miss the indirect entitlement because the review process only checks direct assignments.
- A contractor leaves, but their API token remains active in a vault or deployment pipeline, extending access far beyond the original business need.
- An incident response exception grants privileged access to a remediation script, then never gets recertified after the incident closes.
These patterns are easier to spot when organisations compare entitlement drift against NHI risk guidance from NHI Mgmt Group and pair it with the least-privilege expectations described in the OWASP Non-Human Identity Top 10.
Why It Matters in NHI Security
Permission creep is dangerous because NHIs rarely complain, log in manually, or trigger the same review pathways used for human users. Excess access can sit dormant until a key, token, or service account is reused in a different environment, at which point the blast radius is already built in. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which helps explain why permission creep so often becomes an attack-path multiplier rather than a mere compliance gap. The control problem spans access governance, secret hygiene, and zero trust enforcement, and it maps naturally to the NHI privilege and lifecycle concerns highlighted in the OWASP Non-Human Identity Top 10.
Organisations typically encounter the operational impact only after a breach, failed audit, or service compromise, at which point permission creep becomes unavoidable to investigate and remediate.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Addresses excessive privileges and entitlement drift in non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management directly limits permission creep. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, continuously verified access rather than accumulated standing access. |
Enforce least privilege through periodic access reviews and timely revocation.
