An OAuth scope is a permission string that defines what an application can do on behalf of a user. In practice, scopes set the blast radius of delegated access, because the token carries the right to read, write, or administer resources until it is revoked or expires.
Expanded Definition
OAuth scope is the permission boundary attached to an access token, telling a resource server what actions an app can perform and on which resources. In NHI security, scopes are a delegated authorisation mechanism, not an identity proof.
That distinction matters because a scoped token can still be dangerous if the app is compromised, overconsented, or allowed to request broad permissions by default. OAuth 2.0 standardises token issuance and authorisation flows, but usage in the industry is still evolving: vendors often expose custom scope names, composite scopes, or app-specific consent models that vary in granularity. For practitioners, the operational question is not whether a scope exists, but whether it enforces the minimum access needed for the exact workload or agent.
Scopes are often confused with roles, claims, or API permissions. A role usually describes what an identity is allowed to do inside an application, while a scope describes what a token can do when presented to an API. In OWASP Non-Human Identity Top 10 terms, poor scope design becomes an NHI risk when access is broad, long-lived, or invisible to reviewers. The most common misapplication is treating consented OAuth access as safe by default, which occurs when administrators approve broad scopes without reviewing the downstream API reach.
Examples and Use Cases
Implementing OAuth scope rigorously often introduces consent friction and governance overhead, requiring organisations to weigh faster app integration against tighter permission boundaries.
- A SaaS integration requests only read scope for calendar data, preventing write access if the integration is later compromised.
- An AI agent receives narrowly defined scopes for ticket lookup and status updates, but not for deleting records or exporting entire datasets.
- A third-party analytics app is blocked from using broad mailbox scopes until the security team reviews vendor posture and approval history, a pattern highlighted by the Salesloft OAuth token breach.
- A customer support tool is granted separate scopes for profile read and case write, so access can be revoked selectively without breaking every workflow.
- A cloud backup service is limited to a subset of files rather than full-drive access, reducing exposure if token theft occurs, similar to the lessons from the Dropbox Sign breach.
For implementation guidance, practitioners should compare scope design against the OAuth 2.0 model and the permission-minimisation themes in OWASP Non-Human Identity Top 10. In agentic environments, the same scope can be acceptable for one workflow and excessive for another, so approval should be tied to a specific task, environment, and expiry window.
Why It Matters in NHI Security
OAuth scope is one of the most practical control points for reducing the blast radius of compromised tokens, but it only works when organisations review what was granted, to whom, and for how long. That is especially important because Ultimate Guide to NHIs — Key Challenges and Risks reports that 97% of NHIs carry excessive privileges, and 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. Excessive scopes turn a single token into a broad access path across data, workflows, and administrative functions.
Scope governance also supports Zero Trust thinking because access should be evaluated continuously, not assumed safe after initial consent. In practice, teams need to monitor whether scopes match business need, whether expired apps still retain authorisation, and whether high-risk scopes are ever requested in production. Pairing this with guidance from the same Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP Non-Human Identity Top 10 helps security teams focus on least privilege rather than consent fatigue.
Organisations typically encounter the impact of poor scope design only after a token is abused, at which point scope review becomes operationally unavoidable to contain the breach.
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 Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses excessive permissions and token misuse in non-human identities. |
| NIST Zero Trust (SP 800-207) | AC-3 | Least privilege access control supports limiting token reach to required actions. |
| NIST SP 800-63 | Provides digital identity assurance concepts that inform delegated access design. |
Treat scoped tokens as delegated access artefacts and enforce assurance on the issuing identity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
