The 30-Second Click That Will End a Company.

A Roblox cheat. An OAuth grant. And 85% of your engineers doing the same thing right now.

The thirty-second moment in every engineering organisation right now.

Part four of a series on the governance gaps that will define agentic AI in regulated industries.

Originally published on LinkedIn on April 28th 2026. Read the LinkedIn version here.

The breach that exposed internal data from a $9B cloud platform last week started two months earlier, with a developer at a different company downloading cheats for Roblox onto a personal device.

By the time it surfaced, internal Vercel data was listed for sale on a hacker forum for $2 million.

The thirty seconds that connect those two events — an engineer at Vercel clicking “Allow All” on a third-party AI tool’s OAuth consent screen — is happening inside the engineering organisation of every company reading this. Right now. Possibly several times today.

I’ll get to the timeline. But first, the line every CTO, CISO, and PE operating partner reading this needs to sit with for a moment, from David Lindner, the CISO of Contrast Security, talking to *Dark Reading* the day after Vercel disclosed:

“No exploit. No zero-day. Just an unsanctioned AI tool, an over-permissioned OAuth grant, and a gaming cheat download. Your employees are doing the same things on their machines right now. The question is whether you know about it.”

He’s right. They are. And almost nobody does.

The actual chain, because the details matter

I’ve spent enough time inside regulated fintech and payment processors to know that the post-mortems people remember are the ones with sharp specifics. Here’s what we actually know about the Vercel/Context.ai cascade, based on the public bulletins from both companies and forensic reporting from Mandiant, Hudson Rock, and OX Security:

February 2026. A Context.ai employee — Context being a small AI tooling startup whose product, the “AI Office Suite,” let users connect AI agents to their Google Workspace — gets a personal device infected with Lumma Stealer infostealer malware. According to Hudson Rock’s analysis, the infection vector was a Roblox cheat script downloaded onto that machine. Off-the-shelf malware. Off-the-shelf delivery mechanism. Nothing exotic.

The malware exfiltrates whatever credentials, session tokens, and OAuth tokens are on the machine.

March 2026. Context.ai independently detects unauthorised access to its AWS environment. Their security team blocks the access, engages CrowdStrike, and shuts down the affected product. By any reasonable standard, that’s a competent response. They notify what they believe is the only affected customer. The OAuth tokens that were already exfiltrated remain with the attacker.

Earlier — date unconfirmed. A Vercel employee had, at some point, signed up for Context.ai’s AI Office Suite using their Vercel enterprise Google Workspace account. On the OAuth consent screen, they clicked “Allow All.” The permissions requested were the kind every modern AI agent requests as standard — read access to Drive, ability to send mail, ability to act on the user’s behalf in Workspace. Permissions intended to let the AI write emails and create documents.

Early April 2026. The attacker, sitting on stolen OAuth refresh tokens from the February breach, uses one to take over the Vercel employee’s Google Workspace session. SSO into Vercel internal systems. Lateral movement. Enumeration of environment variables not marked “sensitive.” Approximately 580 employee records, some API keys, GitHub and NPM tokens, and database credentials for specific customer projects are accessed.

April 19, 2026. Vercel CEO Guillermo Rauch discloses on X. A threat actor, claiming to represent ShinyHunters, lists the data on BreachForums for $2M.

Total dwell time from infostealer infection to public disclosure: roughly two months.

No exploit on Vercel’s side. No vulnerability in Next.js, Turbopack, or the deployment platform. The entire intrusion path runs through a single authorisation that an engineer made on a Tuesday afternoon using a marketing-funnel link from a Twitter post.

The actual chain — from a Roblox cheat in February to a $2M listing in April.

This is not the strange edge case. This is the category.

I want to make a claim that I think is going to age well: the Vercel cascade isn’t an anomaly. It’s the first widely-reported example of what’s about to be the dominant supply-chain attack pattern of the next twenty-four months.

The reasons are structural, not behavioural:

• 85% of working developers now use AI tools for coding and software-design work (JetBrains, *State of Developer Ecosystem 2025*, n=24,534).
• The vast majority of those tools request broad OAuth scopes against the user’s email, drive, calendar, repositories, and cloud credentials. The “Allow All” button is faster than the alternative by a factor of about ten.
• Most enterprise IdPs — Google Workspace, Microsoft 365, Okta — ship with default settings that allow individual employees to authorise any third-party app against their work account, with no admin review.
• OAuth refresh tokens, once granted, persist silently until manually revoked. They survive password resets. They survive most SSO posture changes. They survive the original tool being deprecated.
• When a vendor in that chain is compromised — and given the trajectory of this category, more will be — the attacker inherits whatever access the original grant gave them, with zero re-authentication required.

This is the new lateral movement. It doesn’t go through your VPN. It doesn’t trip your EDR. It walks in through an OAuth grant an engineer made six months ago to a tool nobody on your security team knows exists.

Jaime Blasco, CTO of Nudge Security — and the researcher who independently surfaced Context.ai as the source before Vercel publicly named them — put it most cleanly to *Dark Reading: OAuth tokens are now “the new attack surface, the new lateral movement.”* They aren’t a vulnerability you can patch. They’re a class of trust relationships you have to govern.

And almost no engineering organisation I’ve worked with in the last twelve months — full-time, fractional, or as a board advisor — has the governance layer that owns them.

What I’m seeing across portfolio companies

Three observations, all anonymised, all real, all from the last year of operating and advisory work.

Observation one: nobody owns the inventory.

When I’ve asked CTOs at companies for a list of every third-party AI tool with active OAuth grants against their corporate Google Workspace or Microsoft 365 tenant, the answer is roughly the same every time: a long pause, then “we should probably pull that.” The list, when it finally arrives a few days later, is consistently five to ten times larger than anyone expected. It includes tools the security team has never heard of. It includes tools associated with employees who left the company months ago. It includes tools whose vendors no longer exist.

This isn’t negligence. It’s the default state. Engineers are productive people solving immediate problems with the most powerful tools available. They are not, and shouldn’t be expected to be, the ones thinking about token persistence and refresh-token blast radius.

Observation two: the “Allow All” click is structural, not behavioural.

I’ve sat through the consent flow for these tools dozens of times. The friction between “Allow All” and “Allow Only Some” is enormous — to deselect specific scopes you often have to re-flow through the entire onboarding. The product designers building these tools want the broadest permissions because it makes their demo work. The end user wants to get back to their actual job. Five thousand small product decisions every day push every employee in every company toward the broadest possible grant.

You cannot fix this with a security awareness training video. You fix it at the IdP, at the policy layer, before the employee ever sees the screen. Most companies haven’t done that work because nobody on the leadership team has framed it as a board-level governance question yet.

Observation three: the AI vendor’s security posture is now your security posture.

This is the part the boardroom has the hardest time absorbing. Context.ai is, on the available evidence, a real company with real engineers and a real security programme. They detected the unauthorised AWS access. They blocked it. They engaged CrowdStrike. They shut down the affected product. By any standard, that’s a competent response.

It still wasn’t enough.

When you authorise a third-party AI tool against your corporate identity system, you have functionally extended your security perimeter to include that vendor’s weakest employee on their personal device on a Saturday night. Their security maturity becomes an input to your risk model — and most of these vendors are 12–24 months old, pre-SOC-2, with engineering teams of fewer than twenty people.

You wouldn’t grant a Series A vendor read access to your production systems with no SOC 2 report. But you’ve already done the equivalent, dozens of times over, through OAuth. You’ve just done it without anyone signing the paperwork.

Why your existing controls don’t see this

Most enterprise security stacks were built to defend against a network-perimeter attack model. Firewalls. EDR on endpoints. SSO with MFA. CASB for sanctioned SaaS. None of those see what’s happening inside an OAuth grant your employee made on a Tuesday using a link from a marketing email.

The OAuth flow doesn’t go through your network. It originates in a browser, terminates at a third-party service, and persists as a refresh token — which is just a string of characters that vendor’s backend can use to act on your employee’s behalf, indefinitely, until manually revoked. Your SOC will see no traffic. Your DLP will see no exfiltration. Your CASB, in most configurations, will see no policy violation.

The detection problem is that the action looks legitimate. From the perspective of every monitoring tool in your stack, an OAuth-backed agent reading your engineer’s Drive at 3am is functionally indistinguishable from your engineer reading their own Drive at 3am. Because in the system’s view, that’s exactly what it is.

This is the part of the agentic AI transition the security industry is two years behind on.

Three questions every board should be asking on Monday

If you’re a board member, PE deal partner, an operating partner, or a senior leader sitting one level below the board, you don’t need to understand OAuth to ask the right questions. You need to ask three:

1. “Show me the list.” Get the full inventory of every third-party application with active OAuth grants against your portfolio company’s primary IdP. If they can’t produce it within a working day, that is your answer.

2. “Who reviewed the scopes?” For each tool on the list, ask which person — by name — approved the OAuth scopes the tool requested. If that role doesn’t exist, it’s because nobody owns this. Which is exactly how Vercel got here.

3. “What’s the revocation process?” When an employee leaves, when a vendor is compromised, when a tool is deprecated — what is the documented, tested, time-bounded process for revoking the corresponding OAuth grants? In most companies, the answer is some version of “we’d figure it out at the time.” That answer becomes the press release.

These aren’t questions for the CTO alone. They’re questions for the CISO, the Head of IT, and increasingly the board’s risk committee. If your portfolio companies don’t have a governance layer that owns the answers, you have an unbounded liability sitting inside your investment thesis.

The August 2026 EU AI Act deadline is going to make this material to every regulated portfolio company in your book. The Vercel cascade is the first headline. There will be more.

The three questions board members can ask without needing to understand OAuth.

For the readers who want the technical depth

Everything below is for the CTOs, CISOs, and platform engineers who are now asking themselves “how do I actually close this?” If you’re board-side, you can stop reading here — the three questions above are what matter. For everyone else, here’s the controls picture, organised by where it sits in the stack.

[IMAGE: 04_controls_stack.png] Defence-in-depth: identity, device, detection, vendor governance.

At the IdP layer (Google Workspace, Microsoft 365, Okta, Entra ID)

The default state in most enterprise IdPs is permissive. Move it to allowlist-only.

• In Google Workspace: set third-party app access to “Restricted” by default and explicitly review every allowlisted app. Block any app requesting high-risk Drive, Gmail, or admin scopes from being authorised by individual users. Require admin consent.
• In Microsoft 365 / Entra ID: configure App Consent Policies to disable user consent for any application requesting permissions beyond a minimal allowlist. Use the “permissions classified as low” tier for user consent and require admin consent for everything else.
• Implement an OAuth grant review workflow. New third-party applications get reviewed by security before they can be authorised against any work account. This isn’t “make security a bottleneck” — it’s the same vendor security review you already do for any other third-party data processor, just at the right point in the flow.

At the device layer

• Browser extension governance is now part of endpoint security. The Vercel cascade is partially attributable to a Chrome extension associated with Context.ai (extension ID omddlmnhcofjbnbflmjginpjjblphbgk) that was removed from the Web Store in March but persisted on user machines. Your EDR should be inventorying browser extensions across the fleet. Your IT policy should specify which can be installed without review.
• Personal-device-on-corporate-account is a category that needs explicit policy. The Roblox cheat reportedly started this entire chain on a personal device. The damage hit the corporate account because the same browser session was logged into both. This is a pattern, not an aberration.

At the detection layer

• OAuth grant creation should be a logged event with alerting on high-scope grants. Both Google Workspace and Microsoft 365 expose this through their admin audit logs. Most companies don’t pipe these events into their SIEM. Start there.
• Refresh token usage from anomalous IPs or geographies for tokens belonging to high-privilege accounts is the detection pattern that maps directly to this attack class. Your SOC should be testing it. If the answer is “we don’t have visibility on refresh token usage at all,” that’s your gap.
• A new generation of SaaS Security Posture Management (SSPM) tools — Reco, Nudge Security, Push Security, AppOmni, and others — exist specifically to surface OAuth grants and shadow-SaaS-AI inventory. If you’re scoping security tooling for FY26, this category should be on the list.

At the vendor governance layer

• Treat AI tool vendors with the same diligence you’d apply to any other third-party data processor with read access to your corporate data. SOC 2 Type II report. Incident disclosure SLA. Refresh token lifecycle policy. Sub-processor list. If they can’t answer those questions, they don’t get the grant.
• Build a deprecation playbook before you need one. Context.ai shut down its AI Office Suite product in March. The OAuth grants associated with it almost certainly persist in dozens of customer environments where nobody has noticed. When a vendor sunsets a product, the grants don’t sunset with it. Somebody has to revoke them, and that somebody needs to be a named role with a documented process.

None of this is novel security thinking. The OWASP guidance on OAuth has existed for years — but it focuses on how to implement OAuth securely, not on how to govern who gets to grant it.

What’s new is the velocity at which AI tools are creating these trust relationships, and the immaturity of the vendors at the receiving end.

The pattern, named

When I wrote about the token tax a few weeks ago, the argument was that the financial exposure of agentic AI was running ahead of the governance that should be containing it. The shadow AI problem is the same shape on a different axis.

The cost overrun shows up on a CFO dashboard eventually. The OAuth grant doesn’t show up anywhere until it’s a press release.

There is a thirty-second moment — often less — in every engineering organisation right now where an engineer is clicking “Allow All” on a consent screen for a tool nobody on the security team has ever heard of. The action will create a trust relationship that will outlive the project, the engineer, the tool, and possibly the vendor itself. Two years from now, when a different vendor is compromised through a different infostealer, that trust relationship will still be there.

You can’t catch every one of those clicks. You can govern the conditions under which they happen.

This is the fourth piece in a series on governance work I’d argue every CTO/CPTO and every PE operating partner needs to have completed before the EU AI Act lands in August this year. After agentic delivery discipline. After operational governance. After AI cost guardrails. You need an answer to “who has the keys, and who gave them?”

If the honest answer today is “we’d have to look into it,” you’ve already had your Vercel moment.

You just don’t know it yet.

Edwin Poot is a technology executive and Board Advisor with twenty years of experience scaling engineering organisations across PE- and VC-backed fintech, payments, and platform companies. He writes for his blog CTO Insights: Learn & Grow.

Sources

• Vercel Security Bulletin, “Vercel April 2026 security incident”
• Context.ai Security Update, April 19–21, 2026
• Guillermo Rauch (@rauchg), incident thread on X, April 19, 2026
• Alexander Culafi, “Vercel Employee’s AI Tool Access Led to Data Breach,” Dark Reading, April 20, 2026
• JetBrains, “The State of Developer Ecosystem 2025,” published October 2025