OAuth consents can turn a short user interaction into durable cloud access with read, write or delete scope. Even if the app was individually approved, the permission may persist long after the employee stops using it. That makes consent review and revocation part of access governance, not a one-time onboarding task.
Why approved apps still become shadow access paths
Approval is only the beginning. OAuth consent can grant a third-party app durable delegated access to mail, files, chat, calendars, directory data, or other SaaS content, often without any further user interaction. Once the consent exists, the app can keep using the token or refresh flow until the permission is removed, the token expires, or the provider enforces a policy change.
That is why a sanctioned app can still behave like shadow ai. The organisation may have approved the app brand or vendor, but not the specific consent grant, scope set, or downstream data use. If an employee authorises a new feature, plugin, or AI assistant inside that app, the effective access can extend beyond what the original approval review covered. See the OAuth 2.0 model in RFC 6749: The OAuth 2.0 Authorization Framework for why delegated access can outlive the initial click.
That delegated access also sits squarely in access governance. The question is not only whether the app was vetted, but whether the consent is still needed, whether the scope still matches the business purpose, and whether the connection is visible enough to be reviewed later. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is useful here because it treats consent, scopes, token risk, and revocation as a lifecycle control rather than a one-time approval step.
How shadow AI emerges from normal user consent
The risk is usually created by a mismatch between the approval decision and the actual runtime behaviour. A user may approve a legitimate productivity or AI app, then connect it to corporate data through an OAuth grant that allows read, write, or delete operations. If the app later adds automation, background sync, summarisation, or agent-style actions, the same consent can start supporting much broader access than the business expected.
That is why consent-driven integrations are not just convenience features. They can become hidden integration points that pull data into external systems, create stale access after role changes, and bypass the normal review cycle for new applications. NHIMG’s Shadow AI and AI Agent Discovery Guide is relevant because it focuses on finding unmanaged AI apps through OAuth grants and other signals, which is often how these shadow paths are first discovered.
Approved app status can also hide the difference between the vendor and the consented instance. Two employees may approve the same app for different scopes, different tenants, or different resources, producing very different blast radius. The practical control question is therefore “what exact access exists right now?” not “was this app ever approved?”
What makes OAuth consents especially risky for AI-enabled SaaS
OAuth consents are attractive to shadow AI because they give an external service a trusted foothold without requiring the user to share a password. Once granted, the service can act continuously, often through refresh tokens or long-lived access paths, and may read far more data than the user realised was being exposed. That creates a persistence problem, not just an onboarding problem.
Third-party app risk is amplified when the app can forward data into model APIs, workflow engines, browser extensions, or agentic features that were never evaluated in the original approval. NHIMG’s Vercel Context.ai OAuth Supply Chain Breach shows how an unmanaged OAuth integration can turn a seemingly approved service into a data exposure path, while Human vs Non-Human Identity helps explain why delegated user consent can blur into machine-like access once software begins acting on a person’s behalf.
In practice, the highest-risk consents are the ones that combine broad scopes with poor visibility. Mailbox access, file access, offline access, admin scopes, or directory permissions can all persist beyond the user’s original intent. That is what makes consent a governance issue: the approval might be legitimate, but the standing access can still be excessive.
Risk and Threat Considerations
Approved apps become shadow AI when their OAuth grants outlast the review that justified them. The main exposure is persistent delegated access to data and actions that the organisation no longer actively supervises, especially when the app can read mail, harvest files, or trigger downstream automations.
Failure mechanism: The user approves a legitimate app once, then the consent grant remains active while scopes, features, or connected systems expand over time. If the app is compromised, over-scoped, or repurposed, the attacker or vendor can continue using the same trusted token path without redoing the original approval.
Impact: Stale consent can create quiet data exposure, unauthorised AI processing of corporate content, and lateral access into other SaaS systems. It also weakens auditability, because the business may still view the app as approved even after the underlying access has become inappropriate.
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 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — Mission, objectives, and stakeholder expectations | Consent grants create governance decisions about approved access use. |
| PR.AA-05 — Identity management, authentication, and access provisioning | OAuth consent is an access-granting mechanism that needs lifecycle control. | |
| ID.AM-01 — Physical devices and systems within the organization are inventoried | Shadow AI requires visibility into connected apps and integrations. | |
| Recommendation — Inventory approved app consents as governed access relationships. Provision, review, and revoke OAuth grants like access entitlements. Inventory connected apps and OAuth grants to find hidden access paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | OAuth scopes should be minimized to the access actually needed. |
| IA-5 — Authenticator Management | OAuth tokens and refresh tokens require lifecycle and revocation control. | |
| Recommendation — Restrict consented scopes to the minimum necessary permissions. Manage token issuance, rotation, storage, and revocation tightly. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | OAuth tokens for apps can become overprivileged standing access. |
| NHI-07 — Long-Lived Secrets | Refresh tokens and durable consents can persist long after need ends. | |
| NHI-10 — Human Use of NHI | User-approved OAuth grants let humans create machine access on their behalf. | |
| Recommendation — Reduce app scopes and remove excess delegated permissions. Shorten token lifetime and revoke stale consents quickly. Separate human approval from machine access governance. | ||
Practitioner Guidance
What to prioritise: Treat consent grants as active access relationships. Review the scope, data target, and token lifetime before you review the app brand or vendor name, because that is where the real blast radius lives.
What to verify: Confirm whether the consent is still required, whether the scopes match the current use case, and whether the app can continue operating after the employee leaves, changes role, or stops using the tool. If the access survives the user relationship, it needs governance as a standing entitlement.
Decision rule: If an approved app can keep reading or moving organisational data without a fresh business need, revoke or narrow the consent first, then decide whether the app itself still deserves approval. NHIMG’s Identity Data Privacy and Consent Guide is useful for separating lawful consent handling from over-retention of delegated access.
Practitioner takeaway: The approval decision answers only whether the app may enter the environment; the consent decision answers whether it may keep touching data, and that second decision is what usually determines shadow AI risk.
Related resources from NHI Mgmt Group
- Why do non-human identities create compliance risk even when policies exist?
- Why do AI agents create risk even when they stay within approved permissions?
- Why do app-to-app OAuth grants create governance risk for AI integrations?
- Why do AI tools create shadow governance risk even when they improve productivity?