App-to-app OAuth grants create governance risk because the enterprise can lose sight of who approved the delegation, what the app can do, and how to revoke it. When the IdP is outside the flow, access can persist long after the original business need changes, especially in MCP environments with many connected tools.
Why This Matters for Security Teams
App-to-app OAuth grants turn routine integration work into standing delegated access, which means the control point shifts away from the enterprise approval process and toward whatever the connected application decides to request and retain. That is especially risky in MCP-heavy environments, where agents and tools can chain permissions across multiple services. Current guidance from NIST Cybersecurity Framework 2.0 still maps well here: organisations need visibility, governance, and timely revocation, not just a one-time consent event.
The exposure is not theoretical. NHIMG research on The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly the kind of blind spot that lets risk accumulate unnoticed. In practice, many security teams encounter abuse after the app has already been over-scoped, broadly distributed, and forgotten rather than through intentional approval review.
How It Works in Practice
OAuth grants are attractive because they remove friction from application-to-application access, but that same convenience weakens governance when the IdP is not central to the full lifecycle. A user, administrator, or service owner authorises an app once, and the app can continue acting until the grant is manually removed or expires. For AI integrations, that pattern is more dangerous because an agent or automation may request access dynamically, then reuse tokens across downstream tools, APIs, and data stores.
The practical control problem is threefold:
- Approval is often detached from ownership, so no clear business or technical owner remains accountable.
- Grant scope is usually broader than the immediate task, especially when integrations are built for convenience.
- Revocation is inconsistent, because decommissioning the app or changing the workflow does not always invalidate existing consent.
Security teams should treat each OAuth grant as a governed NHI relationship, not as a mere application setting. That means tracking who approved it, what permissions were granted, whether the grant is still necessary, and how quickly it can be revoked. Lifecycle discipline from NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is directly applicable, and the Top 10 NHI Issues page reinforces why stale credentials and hidden access paths routinely become audit findings.
In stronger operating models, teams pair OAuth inventory with periodic access certification, token and grant expiry review, and a policy that any app touching sensitive data must have an explicit owner and a documented business purpose. For AI workloads, this should extend to tool-level logging, because an agent can inherit access from one integration and amplify it through others. These controls tend to break down when the integration sprawl is high and the organisation lacks a single source of truth for app approvals, consent grants, and token revocation.
Common Variations and Edge Cases
Tighter OAuth governance often increases administrative overhead, so organisations have to balance integration speed against the cost of deeper review and faster revocation. Best practice is evolving here, especially for AI-native environments where the app is not a static business system but a goal-driven agent that may alter its tool usage over time.
One common edge case is first-party automation that is treated as low risk and therefore exempted from review. That shortcut becomes fragile when the same automation begins calling additional APIs, using broader scopes, or being repurposed for a different workflow. Another is vendor-managed connectors, where the enterprise can see the app but not the downstream behaviour, making revocation less effective than it appears.
Current guidance suggests that security teams should classify OAuth grants by data sensitivity, business criticality, and revocation difficulty, then apply shorter review cycles to high-risk integrations. Where AI agents are involved, that classification should be stricter, because autonomous tool chaining can create privilege paths that are not obvious at approval time. For related operational patterns, NHIMG’s Salesloft OAuth token breach and DeepSeek breach pages show how delegated access can outlive the original trust decision.
There is no universal standard for this yet, but the direction is clear: treat OAuth grants as revocable NHI trust relationships, not permanent app permissions.
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 | OAuth grants often become stale non-human credentials with weak lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Delegated app access must be managed as least-privilege access, not open-ended consent. |
| NIST AI RMF | AI integrations need governance for autonomous behaviour and downstream access decisions. |
Document ownership, monitor agent actions, and evaluate AI access risk throughout the lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
