On April 19, Vercel disclosed that it had been breached. The entry point was not a zero-day, not a novel AI exploit, not a supply chain compromise of a package dependency. It was a checkbox in Google Workspace that most administrators have never changed.
What Happened #
A Vercel employee had signed up for Context.ai’s “AI Office Suite” using their enterprise Google Workspace credentials and granted “Allow All” OAuth permissions, broad read/write scopes across their corporate account. At the time, this was unremarkable. It was, and in most tenants still is, something any employee can do without administrator review.
Context.ai was subsequently compromised. A Lumma Stealer infection on a Context.ai employee in February 2026 harvested credentials for the tool’s own infrastructure: Google Workspace, Supabase, Datadog, Authkit. With that foothold, attackers pivoted to the OAuth application itself, which gave them authenticated access to every downstream tenant that had granted “Allow All” scopes.
One of those tenants was the Vercel employee’s Google Workspace account. From there, the attackers accessed Vercel’s internal environments and environment variables that had not been marked “sensitive.” Variables marked sensitive, stored in a form that prevents them from being read, appear to be safe. The ones that weren’t, weren’t.
Vercel’s remediation notes tell the rest of the story. Environment variable creation now “defaults to sensitive: on.” The publicly disclosed OAuth Client ID for the compromised app is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, which you should search your own audit logs for.
The Part That Got Me #
I recently performed a Google Workspace security assessment for a publicly traded technology company. One of the findings was the exact OAuth configuration that enabled the Vercel breach: users could install third-party OAuth applications and grant broad scopes without administrator review. It is the default posture in most Workspace tenants. It was the default in that tenant. Statistically, it is probably the default in yours.
Context.ai is not a unique target. It is a small SaaS AI tool whose OAuth application potentially affected hundreds of downstream tenants, most of whom probably have no idea they installed it, let alone that it was compromised.
Why This Keeps Happening #
OAuth sprawl is invisible. Most organizations can tell you how many SaaS tools they license. Very few can tell you how many third-party OAuth apps have been granted access to their Google Workspace or Microsoft 365 tenants by individual employees over the last 24 months.
“Allow All” is a common default. Unless an administrator has explicitly restricted third-party app access, users can, and will, install AI assistants, note-takers, meeting summarizers, and office suites with full read/write scopes across their corporate data. The Workspace admin console does not flag this. It just quietly lets it happen.
AI vendors are third parties. The industry talks about AI as a capability. Your security program needs to treat it as a vendor category, subject to the same diligence as any other SaaS provider.
“Non-sensitive” isn’t “non-valuable.” Environment variables, shared documents, calendar content, email subject lines, all of it has operational value to an attacker. “Nothing sensitive was exposed” is a common breach narrative. It rarely means nothing important was.
What to Do About It #
Audit OAuth applications on your tenant today. In Google Workspace: Admin console → Security → Access and data control → API controls → App access control → Manage third-party app access. In Microsoft 365: Entra ID → Enterprise applications. You will find apps installed months ago by employees who have since changed roles, alongside applications you have no recollection of approving.
Restrict third-party OAuth by default. Move to an allowlist model. Require admin review for any OAuth grant above a restricted scope. Yes, users will complain. They will also stop silently exposing your tenant to compromises at vendors you don’t have contracts with.
Classify the blast radius of every OAuth app. An app with “view your email” scope is a different risk class than one with “manage your files and Gmail data.” Document what is actually installed, what scopes it holds, and who installed it.
Mark environment variables as sensitive by default. Vercel learned this the hard way. Apply the same principle to your own platforms, secret managers, CI/CD systems, configuration stores. Opt-in secrecy isn’t secrecy.
Search your audit logs for the Vercel IoC. If your Workspace has ever had 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com installed, that is worth investigating regardless of whether you are a Vercel customer.
The Bottom Line #
The Vercel breach did not require a novel attack. It required a compromised vendor, an OAuth application, and a Workspace setting that was never reviewed.
If your organization uses Google Workspace or Microsoft 365, and it almost certainly does, the same configuration is waiting for the same kind of compromise. The fix takes an administrator less than an hour. The absence of the fix is one employee signing up for the wrong AI tool away from becoming your breach.
Go check.