Delegated access grants that let an application act on behalf of a user or service within specified scopes. In AI environments, these permissions often become the hidden path to sensitive systems, so their lifecycle and scope require continuous review.
Expanded Definition
OAuth permissions are delegated authorizations that let an application, agent, or service act within a user-approved scope, usually through tokens rather than shared passwords. In NHI environments, the critical issue is not OAuth itself, but how consented access becomes durable, overbroad, or forgotten after the original business need changes.
Definitions vary across vendors when AI tools, integrations, and service principals are involved, but the core control concern is consistent: OAuth permissions can outlive the intent that created them. That makes lifecycle governance, scope minimisation, and revocation discipline essential, especially when the same grant can expose email, files, chats, or downstream APIs. The OWASP Non-Human Identity Top 10 treats token and permission misuse as a primary NHI risk, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the access control and review discipline needed to govern it.
The most common misapplication is treating OAuth consent as a one-time setup task, which occurs when organisations never revisit scopes after app changes, staff turnover, or AI workflow expansion.
Examples and Use Cases
Implementing OAuth permissions rigorously often introduces friction for users and developers, requiring organisations to weigh convenient delegation against the operational cost of continuous review, re-consent, and revocation.
- A sales productivity app requests read access to mailboxes and calendars, but later expands into file access, creating a hidden overreach path if scopes are not revalidated.
- An AI assistant connects to a collaboration platform and inherits delegated rights that let it search messages or create tickets, which can turn a helpful integration into a data-exposure channel.
- A third-party analytics tool retains access long after the contract ends, a pattern highlighted in the Ultimate Guide to NHIs — Key Challenges and Risks and visible in incidents such as the Salesloft OAuth token breach.
- A support chatbot gains delegated access to customer records through a cloud app, and the permission set is never narrowed after pilot testing ends, leaving dormant access in production.
- Security teams compare granted scopes against intended business function, using the Klue OAuth Supply Chain Breach as a reminder that OAuth trust can extend supply-chain blast radius.
Why It Matters in NHI Security
OAuth permissions are one of the most common ways NHIs gain legitimate-looking access without any shared secret being directly exposed. That makes them attractive to attackers and easy to overlook for defenders, especially when access is granted through third-party apps that touch multiple systems at once. In The State of Non-Human Identity Security, 85% of organisations reported they lack full visibility into third-party vendors connected via OAuth apps, showing how quickly delegated access can exceed governance reach.
Mismanaged OAuth permissions often create a false sense of safety because the application appears approved, logged in, and functional. In practice, excessive scopes, stale consent, and weak monitoring can turn a routine integration into a path for data exfiltration, lateral movement, or business email compromise. This is why OAuth governance must be tied to identity inventory, periodic access review, and immediate revocation when an app is no longer needed. The same risk pattern appears in cases such as the Microsoft OAuth Breach and the CoPhish OAuth Token Theft via Copilot Studio.
Organisations typically encounter the consequences only after a token is abused, an app is compromised, or a vendor relationship ends, at which point OAuth permissions become 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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers token, consent, and secret misuse across non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management apply directly to delegated app permissions. |
| NIST SP 800-63 | AAL2 | Assurance levels inform how strongly delegated access should be established and protected. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust policy decisions depend on continuously verifying app and token context. |
| NIST AI RMF | AI risk management covers delegated access used by assistants and agents. |
Require equivalent assurance for high-risk OAuth grants and protect token issuance with strong authentication.
