When OAuth scopes are broader than resource permissions, the connector can succeed while the downstream application allows access to objects the security team never meant to expose. That creates a split control plane where one layer says yes to invocation and another layer says yes to access, with no single governance decision in charge.
Why This Matters for Security Teams
Broader OAuth scopes create a dangerous split between what a connector is allowed to ask for and what the downstream application will actually return. That mismatch is not a theoretical IAM nuisance. It is a control failure that can expose records, files, or tenant data the security team never intended to surface, especially when the app enforces object-level permissions separately from token issuance. The issue is central to the OWASP Non-Human Identity Top 10 because over-privileged non-human access is a recurring attack path.
NHI Management Group has repeatedly highlighted how OAuth-connected third parties expand the attack surface, with The State of Non-Human Identity Security reporting that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That visibility gap matters because access reviews often stop at the scope label, while the actual blast radius is defined by the resource server’s object permissions. In practice, many security teams discover this only after an integration has already been used to enumerate or exfiltrate data, rather than through intentional design review.
How It Works in Practice
OAuth scopes are coarse-grained statements about what a client may request, not always what it may see. If a connector is granted a broad scope such as read-all or mailbox access, but the downstream application has permissive object permissions or weak sharing rules, the token can succeed even when the original intent was narrow. The result is a split control plane: the authorization server approves the token request, while the resource server decides what data can be returned. When those decisions are not aligned, the effective privilege becomes the union of both layers, not the minimum of either.
Practitioners usually reduce this risk by tightening three controls together:
- Map every OAuth scope to concrete resource actions and object classes, not just to app names.
- Review whether the application enforces object-level checks at read and write time, not only at login or token validation.
- Use the most specific scopes available, then validate them against actual API calls and data paths.
- Continuously monitor third-party OAuth grants, especially where connectors can traverse multiple workspaces or tenants.
This is where NHI governance becomes operational, not abstract. The Ultimate Guide to NHIs — Key Challenges and Risks explains why excessive privileges and poor visibility remain persistent failure modes, while the Salesloft OAuth token breach shows how OAuth-mediated access can become a direct data exposure path when trust assumptions are too broad. Current guidance suggests treating OAuth approval as only one part of authorisation, with the resource layer independently verified through policy-as-code or equivalent controls. These controls tend to break down when a broad connector is paired with weak object-level authorization in a SaaS app because the token is valid even when the data boundary is not.
Common Variations and Edge Cases
Tighter scope design often increases integration friction, requiring organisations to balance safer defaults against developer convenience and legacy app compatibility. That tradeoff is real, and there is no universal standard for it yet. Some SaaS platforms expose only a handful of coarse scopes, so the security team cannot express least privilege precisely at token issuance time. In those cases, compensating controls have to move downstream into resource permissions, logging, and approval workflows.
Another edge case appears with delegated admin models, where a high-privilege human authorises a low-privilege connector. The token may still inherit broad reach if the resource server trusts the user’s general role more than the app’s intended function. Similar issues arise with third-party apps that sync data across teams, because a scope that looks benign in one tenant can expose sensitive objects in another. Best practice is evolving toward explicit mapping of scopes to business use cases, with periodic revalidation after app updates, permission model changes, or tenant expansion. The Dropbox Sign breach is a useful reminder that third-party access paths can become sensitive very quickly when trust and privilege drift apart.
Where the resource layer does not support fine-grained checks, the safe answer is not broader scopes, but reduced data exposure, shorter-lived grants, and tighter monitoring of anomalous object access.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Broad OAuth scopes create over-privileged non-human access. |
| CSA MAESTRO | ID-2 | Agent and connector identity must be constrained at runtime. |
| NIST AI RMF | GOVERN | Authorisation drift is a governance issue for automated access paths. |
Assign ownership for OAuth-connected workflows and require documented review of scope-to-resource mappings.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
