Granting an integration more OAuth access than it needs to perform its task. For AI skills and machine identities, over-provisioning increases blast radius because a compromise can inherit broad repository, cloud, or token permissions that were never required for the intended workflow.
Expanded Definition
OAuth over-provisioning occurs when an app, bot, AI skill, or other machine identity receives broader OAuth scopes, delegated access, or refresh-token reach than its workflow genuinely requires. In NHI security, the issue is not merely “too much access” but too much durable access that can be reused after compromise, especially when a token can traverse multiple services or data sets.
Definitions vary across vendors on whether the term includes only consented scopes or also inherited permissions from connected systems, so governance teams should treat it as a design and review problem rather than a product label. The control objective is consistent: limit delegated access to the minimum needed, validate scope justification, and remove standing privilege that no longer supports the integration’s purpose. NIST Cybersecurity Framework 2.0 reinforces this least-privilege posture through access governance and continuous monitoring. The most common misapplication is granting a broad “one-time” integration permission set, which occurs when teams optimise for fast onboarding instead of reviewing the downstream blast radius of token reuse.
Examples and Use Cases
Implementing OAuth scopes rigorously often introduces onboarding friction, requiring organisations to weigh developer speed against reduced blast radius and clearer accountability.
- An AI note-taking agent is allowed read-only access to a shared mailbox, but it is also granted calendar, file, and team-chat scopes “just in case,” creating unnecessary exposure if the token is stolen.
- A SaaS integration is approved for a single repository, yet receives organisation-wide code and issue access, making one compromised refresh token enough to expose broader intellectual property.
- A workflow bot needs ticket creation in a service desk, but is granted admin-level API access because the owner does not want to revisit the consent screen later.
- A third-party sales app is connected through OAuth and then silently accumulates access as new scopes are accepted during updates, a pattern that should be reviewed alongside the visibility concerns highlighted in the State of Non-Human Identity Security.
- An enterprise security team compares requested scopes to the intended task using guidance from NIST Cybersecurity Framework 2.0 and the lifecycle controls described in the NHI Lifecycle Management Guide.
These examples show that over-provisioning often starts as a convenience decision and becomes a governance problem only after the integration is widely trusted.
Why It Matters in NHI Security
OAuth over-provisioning expands the attack surface of non-human identities because a single stolen token can expose far more data and functionality than the original task required. For AI agents, this is especially dangerous: tool use and delegated access can turn a narrow workflow into a high-impact compromise path. NHIMG research shows that 97% of NHIs carry excessive privileges, which means over-provisioned OAuth is not an edge case but part of a broader privilege discipline problem.
The risk intensifies when third-party access is involved. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, making it difficult to know which integrations are over-scoped until an incident occurs. In practice, over-provisioning also undermines revocation, since broad consent often persists long after the original business need has expired. The most damaging outcomes are credential reuse, lateral movement, and data exfiltration through trusted automation. Organisations typically encounter the true cost only after a token theft, at which point OAuth over-provisioning 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-02 | Over-provisioned OAuth scopes are a direct least-privilege and secret-exposure concern. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed to enforce least privilege for machine identities. |
| NIST Zero Trust (SP 800-207) | SC.DP | Zero trust requires explicit, minimal, continuously evaluated access for every request path. |
Map integration scopes to least-privilege controls and continuously review delegated access.
