Delegated OAuth connections can outlive the original business need and carry more access than users realise. When the connected app is compromised, the attacker inherits the delegated authority, not just the app itself. That creates an NHI problem because the token becomes a reusable identity path into systems, often with enough privilege to expose credentials or move laterally.
Why This Matters for Security Teams
Delegated OAuth connections are risky because they turn a business shortcut into a durable identity path. A user may approve an app once, but the resulting token can remain active long after the original task is done, and the app often inherits far more access than the requester intended. That matters for NHI security because the token is not just an integration detail; it is a reusable credential with real privilege.
The scale of the visibility problem is why this issue keeps surfacing in incident response. In The State of Non-Human Identity Security, Astrix Security and CSA report that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. Once that connection exists, security teams may not know which systems are reachable, which scopes were approved, or whether the app still has a valid business purpose. NIST also frames this as an access governance problem, not just an app-risk problem, in the NIST Cybersecurity Framework 2.0.
In practice, many security teams discover the delegated path only after an alert, a breach review, or a privilege audit has already exposed how much access the token retained.
How It Works in Practice
OAuth delegation increases compromise risk because it shifts trust from a person to an application, then allows that application to act inside the user’s authorised scope. If the app is compromised, the attacker does not need to steal the user’s password. They can use the delegated token, refresh token, or connected app grant to query data, call APIs, or chain into other services that trust the same identity path.
This is why OAuth connections should be treated as NHIs with lifecycle controls. Current guidance suggests three practical guardrails:
- Restrict scopes to the smallest set needed for the integration, then review them like any other privileged entitlement.
- Use expiration, re-consent, or re-approval where possible so old connections do not become standing access.
- Continuously monitor token use, unusual API calls, and app-to-app activity, especially for third-party integrations.
NHIMG research shows how often these paths are overlooked. The 52 NHI Breaches Analysis and the Salesloft OAuth token breach both illustrate the same pattern: a delegated integration becomes the attack path because the token is accepted as legitimate even after the original trust decision is no longer safe. That aligns with vendor research in The State of Non-Human Identity Security, which found that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
These controls tend to break down in SaaS-heavy environments where admins cannot centrally see app consents, token refresh behaviour, and downstream API usage across every tenant.
Common Variations and Edge Cases
Tighter OAuth control often increases operational overhead, so organisations have to balance user convenience against the risk of dormant or over-scoped access. That tradeoff is especially sharp when teams rely on multiple vendors, automation platforms, and low-code tools that ask for broad delegated permissions to function at all.
One edge case is service-like apps that genuinely need long-lived access. Best practice is evolving here, and there is no universal standard for every platform, but the safer pattern is to prefer short-lived credentials, JIT approval where supported, and explicit business ownership for each connection. Another exception is internal automation that uses OAuth as a transport layer for workload identity. In those cases, the question is not whether OAuth exists, but whether the connected workload has clear identity, bounded scope, and a revocation path when the task ends. For broader identity context, Ultimate Guide to NHIs and Top 10 NHI Issues are useful starting points.
For mature programmes, the question is no longer whether delegated OAuth is convenient. It is whether the organisation can prove who approved it, what it can reach, and when it should be removed. That is also why the problem belongs in governance, not just in the app catalog. The Anthropic report on AI-orchestrated cyber espionage reinforces a broader point: automated abuse scales fast once credentials or tokens can be reused across systems.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses weak rotation and lifecycle control of delegated tokens. |
| NIST CSF 2.0 | PR.AC-4 | Covers access enforcement for third-party and delegated identities. |
| NIST AI RMF | Useful for governing autonomous or automation-driven token use. |
Apply governance, accountability, and monitoring to delegated automations as AI-like workloads.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
