Scope creep is the gradual expansion of what a delegated application can do beyond its original purpose. In OAuth environments, it usually appears as broader permissions, extra APIs, or added administrative reach that increase the blast radius of a compromise.
Expanded Definition
Scope creep in NHI and IAM programs is the slow widening of delegated access after the original business need has changed, or was never clearly bounded. It is not a single event. It usually appears as extra API scopes, added admin endpoints, broader tenant visibility, or a service account that accumulates permissions as teams “temporarily” expand its role. In practice, this is one of the clearest ways a harmless integration turns into standing risk.
Definitions vary across vendors, but in security operations the term is best understood through least privilege, consent boundaries, and lifecycle control. The OWASP Non-Human Identity Top 10 treats over-privileged identities and weak governance as core failure modes, which is why scope creep should be reviewed alongside authorization design, not just access provisioning. If a delegated application can laterally expand its reach without a new approval path, the issue is not just “more access” but a broken trust model.
The most common misapplication is assuming scope changes are harmless because they were added for convenience during troubleshooting, when the permission never gets rolled back after the incident is resolved.
Examples and Use Cases
Implementing scope boundaries rigorously often introduces operational friction, requiring teams to balance fast delivery against the overhead of tighter approvals and more frequent entitlement review.
- A marketing automation app starts with read-only contact access, then gains write access to campaign data and admin visibility after successive feature requests.
- A CI/CD integration receives broader repository and secrets access during a release freeze, but the temporary exception becomes permanent.
- An AI agent used for ticket triage is later allowed to close incidents, create users, and query production logs, expanding its execution authority beyond the original workflow.
- A third-party reporting tool is granted additional tenant scopes to “fix” dashboard gaps, then retains access even after the reporting need changes.
This pattern is covered in NHI governance discussions such as the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights how permissions accumulate across lifecycle stages. The practical test is simple: if the app must keep expanding its authorization to remain useful, the original delegation model was too broad or too vague. Scope creep is also closely related to OWASP Non-Human Identity Top 10 recommendations on reducing exposure and limiting blast radius.
Why It Matters in NHI Security
Scope creep matters because non-human identities rarely fail all at once. They usually become dangerous through accumulation: more scopes, more secrets, more environments, more standing privilege. That is why NHI governance must treat permission growth as a measurable control failure, not as an unavoidable byproduct of integration work. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
In a Zero Trust Architecture, scope creep weakens verification because the system can no longer assume the delegated identity is constrained to one task, one dataset, or one environment. It also complicates offboarding, secret rotation, and incident response, because responders must now untangle what the identity was originally supposed to do versus what it eventually learned to do. The same problem appears in agentic systems, where an AI Agent may inherit tool access that exceeds its intended workflow, especially when humans blur temporary exception handling into normal operations. Organisations typically encounter the consequence only after a misuse case, credential theft, or audit finding exposes the excess access, at which point scope creep becomes 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 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-01 | Over-privileged non-human identities are a primary OWASP NHI failure mode. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management directly addresses permission growth over time. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust limits implicit trust and reduces lateral reach from delegated identities. |
Enforce approval and periodic review for every scope expansion, including temporary exceptions.
