What breaks when OAuth consent is used for shadow AI without review?

The organisation loses control over delegated access. A user may authorise an AI app to reach mail, files, or other SaaS resources, and that access can persist even after the original business need has changed. Without review, the consent itself becomes a standing risk surface.

Why This Matters for Security Teams

shadow ai turns oauth consent into an access path that security teams often do not see in the normal joiner-mover-leaver process. Once a user authorises an AI app, that app can inherit mailbox, file, or SaaS privileges without a security review, making consent a durable delegation mechanism rather than a one-time convenience. This is especially dangerous when the app is built or operated outside the organisation’s approved software estate.

The operational risk is not just data exposure. OAuth-connected AI apps can retain refresh tokens, call APIs repeatedly, and expand their reach across linked services. NHIMG research on the State of Non-Human Identity Security shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which helps explain why these grants are so often missed. For threat patterns, the Vercel Context.ai OAuth Supply Chain Breach is a clear example of how a sanctioned-looking integration can become a data access path.

Current guidance suggests treating OAuth consent as privileged delegation, not routine application setup. In practice, many security teams encounter the abuse of OAuth grants only after data has already been shared, indexed, or exfiltrated through an app that nobody reviewed.

How It Works in Practice

When OAuth is used for shadow AI, the user becomes the policy proxy for the app. The user sees a consent screen, approves scopes, and the application receives tokens that may outlive the immediate task. If the app is an AI assistant, it may query mailboxes, documents, tickets, or chat records to complete prompts and then continue operating with the same delegated access.

This breaks several security assumptions. First, static RBAC cannot describe the real behaviour of an autonomous or semi-autonomous app, because the app’s access pattern changes with each prompt, plugin, or workflow. Second, review based only on the original consent prompt misses the downstream chain of actions, such as bulk file reads, cross-tenant API calls, or forwarding data to another service. The Salesloft OAuth token breach shows how stolen or misused tokens can become a broad access channel once the token is trusted.

Practitioners should look for four controls:

• App registration allowlists so only approved AI integrations can request consent.
• Centralised consent review for high-risk scopes such as mail.read, files.read, offline_access, and directory permissions.
• Short-lived, revocable tokens with continuous monitoring for unusual API volume or new resource targets.
• Conditional access and data loss controls that evaluate the app, user, device, and requested action at runtime.

For control design, NIST SP 800-53 Rev. 5 Security and Privacy Controls remains the best external anchor for access enforcement, logging, and authorization governance. These controls tend to break down in environments where users can self-authorise third-party AI apps directly against SaaS tenants because there is no shared approval workflow or complete app inventory.

Common Variations and Edge Cases

Tighter consent governance often increases user friction and administrative overhead, so organisations need to balance speed against the risk of silent delegation. That tradeoff becomes sharper in teams that depend on rapid experimentation with copilots, browser extensions, and workflow automations.

There is no universal standard for this yet, but current guidance suggests separating low-risk productivity add-ons from apps that request broad, persistent, or cross-system scopes. A small helper that drafts text is not the same as an AI agent that can read inboxes, create records, and trigger downstream workflows. Best practice is evolving toward consent review boards, periodic re-certification of OAuth grants, and revocation when the business use case no longer exists.

Edge cases matter. Some enterprises allow vendor-managed AI plugins under procurement review, while others only permit internal apps with enterprise-controlled identities. The right model depends on whether the app is operating as a simple client or as a goal-driven agent with tool access. NHIMG’s State of Secrets in AppSec is also relevant here because weak secrets hygiene and fragmented management make token sprawl harder to detect once OAuth grants proliferate.

For privacy-sensitive environments, the EU General Data Protection Regulation (GDPR) raises the stakes further because over-broad consent can become a data minimisation and purpose-limitation problem. Shadow AI breaks down fastest where consent is treated as a user convenience instead of a governed control point.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• What breaks when AI is used in IAM without clear ownership and approval paths?
• What breaks when AI root-cause analysis is used without ground truth?
• What breaks when access review does not cover non-human identities used by AI agents?