Shadow AI & OAuth sprawl

Most organizations are rightly nervous about employees adopting unapproved AI tools. Shadow AI use in the form of LLMs, where users upload sensitive data to ChatGPT, Claude, or a dozen other chatbots, is a legitimate concern. But it’s not the biggest one.

When an employee connects an AI app into Google Workspace, Microsoft 365, Salesforce, or any other core platform, they’re creating a persistent, programmatic bridge between your environment and a third party.

That bridge doesn’t go away when the employee stops using the app. And if that third party gets compromised, the bridge becomes a direct pathway into your systems.

We just saw this scenario play out with the Vercel breach. Context.ai’s AI app was trialled by a Vercel employee, who had granted it access (via OAuth) to their Google Workspace account. When Context.ai got breached, Vercel got caught in the fallout.

The AI scramble is a force multiplier for shadow SaaS

Shadow IT is not a new problem. Most organizations run heavily (or exclusively) on SaaS, accessed in the browser, with hundreds of apps per enterprise. Unmanaged, self-adopted apps have been a thorn in the side of security teams for some time. But the AI scramble is a force multiplier.

There are different kinds of shadow IT to be aware of in the context of AI apps:

• Shadow apps: Apps that employees have signed up to and are using for business purposes without business approval. This includes apps signed up to with a corporate account or personal account.

• Shadow tenants: Apps that employees are accessing with personal accounts, essentially creating shadow tenants outside of your organization’s control — even if you’ve approved the app itself.

• Shadow extensions: Many AI apps come with an extension counterpart, along with countless third-party extensions that are either untrustworthy or downright malicious. Browser extensions add another angle to the equation by presenting visibility beyond the application into browser activity. 

• Shadow integrations: OAuth connections across apps that aren’t known or approved. Even if an app itself is approved, plugging that app directly into your primary enterprise apps — with all the sensitive data and functionality therein — isn’t necessarily also approved.

In the Vercel case, we’re talking specifically about shadow integrations. But all of these present a key risk to your organization. 

The Vercel breach: a textbook example of OAuth grants gone wrong

The Vercel breach clearly illustrates the impact of shadow AI integrations. 

A Vercel employee had connected an AI app — specifically a deprecated consumer-grade “AI Office Suite” product from Context.ai — into their Google Workspace tenant. Vercel wasn’t even a registered customer of Context.ai.

This was most likely a self-service trial that got integrated, lightly used, and forgotten about, adding an invisible node to the organization’s attack surface.

By adopting the Context.ai app, the Vercel employee added a third-party’s employees and systems as a security dependency. 

When Context.ai was subsequently compromised (allegedly the result of an infostealer infection from an employee searching for Roblox cheats — yes, really), the attacker was able to leverage OAuth tokens stored in Context.ai’s environment to pivot into downstream customer accounts.

That included the Vercel employee’s Google Workspace, which happened to be a well-permissioned account with access to internal dashboards, employee records, API keys, NPM tokens, and GitHub tokens.

Vercel isn’t an outlier: attackers are targeting OAuth at scale

Widespread OAuth interconnectedness isn’t just an AI app problem. Attackers have been exploiting this for some time, and the cadence is accelerating:

• In 2025, Scattered Lapsus$ Hunters launched OAuth-driven supply chain attacks against Salesforce and Google Workspace tenants after breaching Salesloft (specifically the Salesloft Drift platform) and Gainsight. Over 1000 organizations were impacted — including Google, Cloudflare, Rubrik, Elastic, Proofpoint, JFrog, Zscaler, Tenable, Palo Alto Networks, CyberArk, BeyondTrust, Qualys, and many more — with over 1.5 billion records stolen.

• Snowflake customers were impacted after a breach at data anomaly detection company Anodot, where the attacker attempted to leverage stolen authentication tokens to access Salesforce data, with Rockstar Games a high-profile victim.

Attackers aren’t only abusing existing OAuth connections as part of supply chain attacks — they’re using OAuth-focused phishing as the front door to victim environments. Last year’s Salesforce campaign began with device code phishing, where attackers tricked victims into registering an attacker-controlled app into their Salesforce tenant, granting full API access for mass data exfiltration.

We’ve since observed a 37x increase in device code phishing attacks this year, with more than a dozen criminal PhaaS kits in circulation.

The pattern is clear: OAuth integrations are becoming one of the most reliably abused attack surfaces in enterprise environments, and every new AI tool your employees connect makes the web a little wider.

The web of OAuth sprawl spans way beyond Google and Microsoft

The Vercel breach is illustrative, but it only scratches the surface of the problem.

Controlling OAuth in your main enterprise cloud environment (think M365 or Google Workspace) is fairly straightforward — both platforms give admins the ability to audit and control OAuth connections. The Vercel breach could have been avoided had their employees been blocked from adding new OAuth integrations without admin approval — a toggle in their Google admin panel. Or, if the integration had been flagged in a routine audit and removed.

But doing this across every SaaS app is considerably harder. Not only do you need a comprehensive and up-to-date inventory, you need to be an app admin for every app (not always the case for self-adopted apps), and the particular app needs to give you the control to restrict and remove OAuth grants on behalf of users in your tenant.

Think about how the typical AI app operates. If you want it to effectively automate workflows — pull data from one app, aggregate and analyze it in another, present that information in a report, dashboard, or presentation, and then distribute it — that’s a fair few integrations in just one workflow. MCP connections use OAuth to achieve this interconnectivity in the same way as any other SaaS app.

We used to talk about automation apps like Zapier as being a goldmine for attackers. Well, AI apps are on their way to being even more interconnected, more frequently used, and more flexible in terms of how attackers can abuse them.

What security teams should do now

Lock down OAuth consent. Adopt a default-deny approach to allowing users to consent to new integrations in your primary enterprise apps. This is the same principle we recently advised for browser extension management — users shouldn’t be able to introduce new trust relationships without approval. 

Audit what’s already connected. Routinely audit the OAuth integrations already in your environment to ensure they’re still definitely required. Each integration expands your attack surface and could potentially grant an attacker extensive access. 

Think beyond Google and Microsoft. Controlling OAuth in your primary enterprise cloud is necessary but not sufficient. SaaS-to-SaaS connections are less visible and often have fewer controls. You need visibility into OAuth grants happening across every app. 

Remember, this isn’t exclusively a shadow AI problem, even if AI adoption is contributing significantly to the sprawl.

How Push Security can help

As we’ve established, there are quite a few pieces to this puzzle. Push Security can help with all of them.

Push observes every app login your employees make in their browser, building a comprehensive picture of SaaS and AI use across your organization. This includes how they’re logging in and how secure the login is: did it have MFA, what kind of MFA, was it using a weak or compromised password, did they use SSO, and so on.

Push also tracks OAuth integrations in your environment and gives you the ability to manage and remove them, providing a single platform to view, manage, and secure app use across your organization.

This makes it easy to surface both vulnerabilities and possible control gaps, and do something about them. 

But where Push really excels is in the ability to observe and block OAuth connection requests even outside of your primary enterprise apps. Using Push, you can detect and block OAuth integration requests as they traverse the browser.

This app-agnostic level of control is absolutely critical to halting OAuth integration sprawl.

Push’s browser-based security platform also detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, device code phishing, ClickFix, and session hijacking in real time — including the most prominent infostealer delivery vectors (the source of Context.ai’s breach).

Push analyzes every web page in every browser session and tab for threats, in real time, with no latency.

Learn more about how to secure Shadow AI with Push, and book time with our team for a live demo.

Sponsored and written by Push Security.