Shadow AI Got an Upgrade: OAuth Tokens and the Apps You Didn't Approve

A year ago, “shadow AI” meant someone on your team pasting a client document into ChatGPT. That’s still a problem. But it’s no longer the main one.

The bigger risk in 2026 is OAuth consent grants: third-party apps that your employees authorize with their Microsoft 365 credentials, giving those apps persistent access to email, files, calendars, and Teams data. No password shared. No MFA bypassed. Just a single “Allow” click on a consent prompt, and now an application you’ve never evaluated has standing access to your firm’s data.

How OAuth consent grants work (and why they’re dangerous)

When an employee connects a third-party app to their M365 account, Microsoft shows a consent prompt listing what the app wants access to. Read email. Access files. Send messages on your behalf. If the employee clicks “Accept,” that app receives an OAuth token granting the requested permissions. That token remains valid until someone explicitly revokes it.

Here’s what makes this different from a password being stolen: the app doesn’t need to authenticate again. It has a persistent token. It can access data continuously, in the background, without triggering any login alerts or MFA challenges. From Microsoft’s perspective, the access is legitimate because the user authorized it.

For most small firms, any user can grant consent to any app by default. Microsoft’s Entra ID allows this out of the box. That means a single paralegal, associate, or staff accountant can grant a third-party AI tool access to your firm’s email and files without IT ever knowing it happened.

What this looks like in practice

The AI productivity tool. An employee finds an AI meeting summarizer, email assistant, or document analyzer. They connect it to their M365 account for convenience. That app now reads every email in their inbox, including client communications, privileged discussions, and financial data. The app’s privacy policy may allow it to use that data for model training.

The malicious consent phish. Attackers are building fake productivity apps specifically designed to harvest OAuth tokens. Push Security documented a technique called ConsentFix (originally used by Russian state hackers, now commercialized on criminal forums) that tricks users into granting OAuth access through what looks like a routine verification step. No credentials stolen, no MFA defeated, just a token handed over through a legitimate Microsoft authorization flow.

The legitimate app that overpermits. Even well-intentioned apps often request more permissions than they need. A scheduling tool that asks for “Read and write all files” or a CRM plugin that requests “Full mailbox access” creates exposure far beyond what’s necessary for the stated function.

Why this is worse than someone using ChatGPT

When an employee pastes a document into a consumer AI tool, the exposure is limited to that one document, that one time. It’s bad, but it’s bounded.

An OAuth consent grant is ongoing. The app has access until the token is revoked. It can pull data continuously. And because the access was “authorized,” it won’t show up in your security alerts as anomalous behavior. Your SIEM won’t flag it. Your EDR won’t catch it. It looks like normal, sanctioned access.

This is why we mentioned OAuth consent abuse as one of the four main session token attack vectors last week. The mechanism is different from a phishing kit stealing a session cookie, but the outcome is the same: persistent, unmonitored access to your firm’s data by something that shouldn’t have it.

What to actually do about it

Restrict user consent in Entra ID. Microsoft allows you to configure consent policies that prevent regular users from granting app access without admin approval. This is probably the highest-leverage change most small firms can make. It doesn’t block apps entirely; it routes consent requests through an admin approval workflow so someone qualified reviews what’s being granted before it takes effect.

Audit existing consent grants. Most firms that have been running M365 for several years have accumulated OAuth grants they’ve never reviewed. In the Entra admin center, you can view all enterprise applications and their granted permissions. Look for apps you don’t recognize, apps with overly broad permissions (full mailbox access, read/write all files), and apps that haven’t been used recently but still hold active tokens.

Enable the admin consent workflow. When you restrict user consent, you need to give people a path to request access to legitimate apps. Microsoft’s admin consent workflow lets users submit requests that admins can evaluate and approve or deny. Without this, people will find workarounds (personal accounts, unmanaged devices) that create worse problems.

Review the Microsoft Entra “risky applications” signals. If you have Defender for Cloud Apps or Entra ID P2, you get automated detection of apps exhibiting suspicious behavior (accessing unusually large volumes of data, accessing data at odd hours, apps from unverified publishers). These signals exist but require someone to be watching them.

Block known-bad OAuth patterns via Conditional Access. You can create policies that block consent flows from unmanaged devices, block consent to apps from unverified publishers, or require specific compliance conditions before consent is granted.

The conversation most firms aren’t having

A lot of the AI security advice circulating right now boils down to “use the right AI tool” (meaning an enterprise tool like Copilot instead of a consumer one). That’s not wrong, but it’s incomplete. It addresses one dimension of shadow AI while ignoring the OAuth consent problem entirely.

The real question isn’t just “which AI tool should we use?” It’s “what third-party apps already have persistent access to our data, and does anyone here know?” That’s an audit question, a configuration question, and an ongoing governance question. And for most 20-50 person firms, nobody is asking it.

What this means for your firm

If you’re running Microsoft 365 and you’ve never checked your OAuth consent grants, you probably have apps with access you didn’t intend to give. Some may be legitimate tools that just need their permissions scoped down. Some may be apps an employee connected months ago and forgot about. And some, in the worst case, may be actively exfiltrating data.

The device code phishing attacks we’ve written about exploit OAuth flows maliciously from the outside. Unmanaged consent grants are the same problem from the inside: OAuth tokens granting access that nobody is monitoring.

Start with the audit. Check what’s connected. Restrict future consent. Route requests through an admin. None of this is difficult, but it does require someone to actually go look.