One Employee. One AI Tool. One OAuth Click. Zero Entries in the Register.

On April 19, an unknown productivity app breached Vercel. The customer database is now for sale for $2 million on BreachForums. Your DORA Register did not see it coming.

$2,000,000.

That is the asking price for the Vercel customer database posted on BreachForums on April 19, 2026 — nine days ago. Hundreds of thousands of organisations host their applications on Vercel. A subset of customer Vercel credentials and decrypted environment variables — secrets, API keys, payment tokens — are now in criminal circulation.

The attacker did not exploit a Vercel vulnerability. The attacker did not phish a Vercel administrator. The attacker did not breach Google Workspace. The attacker compromised a small third-party AI productivity tool — Context.ai — that one Vercel employee had connected to his Vercel-issued Google Workspace account, with “Allow All” OAuth scope, sometime before February 2026.

Lumma Stealer infected Context.ai in February. The attackers harvested Context.ai’s Google Workspace OAuth tokens. Through those tokens they took over the employee’s Vercel Google Workspace account. Through that account they pivoted into Vercel’s internal systems. Through those systems they enumerated and decrypted environment variables for “a limited subset of customer projects.”

Sixty days. Three pivots. One forgotten OAuth scope.

Context.ai was not in Vercel’s vendor management system. It was not in any DORA Register equivalent. It was not in any compliance attestation, any procurement record, any penetration test scope. It was, until April 19, an unfunded, employee-installed productivity app — exactly the kind of tool that the AI vendor governance frameworks of 2025 explicitly do not assess.

That is the architecture problem. And every framework currently on the market — AVAEM, ACAM, NIS2 supplier lists, the DORA Register itself — was designed before this attack pattern existed.

The attack chain that breached Vercel is a fourth-party attack — and your enterprise architecture has no inventory of fourth parties.

WHAT ACTUALLY HAPPENED — AND WHY IT IS NOT A VERCEL STORY

The instinctive response to the headline is to route it to Vercel’s CISO and forget about it. That is a strategic error.

This is not a Vercel breach. It is a class of breach that any organisation with employees and AI productivity tools is now exposed to. Vercel disclosed quickly, publicly, and with clear technical detail — exactly what good incident response looks like. The lesson is not about Vercel’s defences. It is about the attack chain that succeeded against them.

Here is the attack sequence:

• One Vercel employee installed Context.ai, an “AI office suite,” to summarise documents in his Google Workspace.

• The employee granted Context.ai “Allow All” OAuth permissions — full read access across the entire Google Drive.

• Context.ai persisted those OAuth tokens in its own infrastructure.

• In approximately February 2026, Lumma Stealer malware compromised a Context.ai system and exfiltrated the OAuth tokens.

• The attackers used the stolen tokens to authenticate as the employee against Google Workspace.

• From inside Google Workspace, the attackers pivoted to Vercel’s internal account systems.

• Once inside Vercel, they enumerated environment variables for a subset of customer projects.

• The data was packaged and listed on BreachForums on April 19 for $2 million.

The protocol that connected steps 1 and 2 was OAuth 2.0 — a 13-year-old authorisation standard. The technology that enabled steps 3 to 8 was a standard SaaS productivity feature: enterprise Google Workspace allowed an employee to authorise a third-party app at full-tenant scope. There was no zero-day. There was no novel exploit. There was a permission model that has existed for a decade — combined with an AI tool nobody had architected for.

The attack succeeded because of architectural permission, not technical breach.

THE ATTACK CLASS NOBODY HAS A FRAMEWORK FOR

The Vercel–Context.ai breach exposes a category of risk that does not fit cleanly into any current enterprise architecture model.

Existing frameworks address adjacent — but not equivalent — problems:

• The DORA Register of Information captures contracted ICT third parties. Context.ai was not contracted. It was OAuth-installed by an employee. Out of scope.

• NIS2 supply-chain provisions require risk assessment of identified suppliers. An AI tool installed via OAuth at the consumer interface is not, by most definitions, a supplier.

• EU AI Act Article 50 transparency obligations apply to AI systems that produce content or interact with users. Context.ai is a productivity tool, not a high-risk AI deployment.

• AVAEM (the AI Vendor Architectural Exposure Model from Edition 46) maps named AI vendor risk along five dimensions. Context.ai was never named — therefore never mapped.

• ACAM (the Agent Commerce Architecture Model from Edition 48) addresses autonomous agents transacting on behalf of the enterprise. Context.ai was not transacting; it was reading a Google Drive.

What Context.ai actually was, in architectural terms, is the fourth party: a vendor of a vendor of the enterprise — connected at the identity perimeter through an OAuth scope no one in the risk function ever saw.

Industry research published this month reports that two-thirds of firms have already had a security incident caused by AI agents. Eighty-eight per cent of enterprises report agentic-AI-related security incidents in the last twelve months. Only twenty-nine per cent report being prepared. The gap is structural — not procedural.

Most enterprise architecture functions cannot answer the most basic question this breach raises: which OAuth scopes have been granted to which AI tools against your enterprise identity provider, and what data does each one access? The data lives in Google Admin’s third-party app log. In Microsoft Entra’s Enterprise Applications registry. In Okta’s OAuth grants table. None of it is in your DORA Register. None of it is in your AVAEM assessment. None of it is in any architecture artefact your CISO has ever signed — because the artefact does not exist yet.

THE REGULATORY COLLISION

Three regulatory regimes are converging on the fourth-party perimeter — and each one assumes a registry of named entities that today does not include shadow AI tools.

DORA — Active; Register of Information cross-checking live

The grace period ended in January. National competent authorities are now automatically cross-checking Registers of Information. The supervisory focus has moved to subcontracting chains and concentration risk. Article 28 requires the Register to capture every ICT service provider — including subcontractors — that supports a critical or important function. An OAuth-connected AI tool with read access to a CFO’s Google Drive is, by any reasonable interpretation, an ICT service provider. The supervisory authorities have not yet litigated this interpretation. Your inspector will.

NIS2 — Belgium’s first conformity deadline passed April 18

Belgium became the first Member State to require essential entities to submit accredited conformity assessments by April 18, 2026 — ten days ago. Eighty-four per cent of NIS2-regulated entities admit they are not ready. Article 21 supply-chain provisions explicitly require entities to assess “the security of supply chains of network and information systems” — which, post-Vercel, must be interpreted to include the OAuth-connected fourth parties that act as identity-tenants of an organisation’s communications infrastructure. The April 18 deadline did not wait for the framework to mature.

EU AI Act Article 50 — Active August 2, 2026; not delayed by the Digital Omnibus

This is the obligation the Digital Omnibus did not delay. The April 28 trilogue is expected to defer high-risk Annex III obligations to December 2027 and embedded-product systems to August 2028. Article 50 transparency requirements were not on the deferral table. An employee-installed AI productivity tool that summarises corporate documents — and persists OAuth tokens that can be exfiltrated — meets the definition of an AI system interacting with users on a deployer’s behalf. The deployer is the enterprise. The deployer’s accountability does not depend on whether the deployer ever procured the tool.

DORA, NIS2 and the AI Act all assume your fourth parties are visible. They are not. That is the architecture gap, and August 2 is when it stops being theoretical.

INTRODUCING SAVED — THE SHADOW AI VENDOR EXPOSURE DIAGNOSTIC

What enterprises need is not another vendor assessment process. They need a structural model that captures the fourth-party perimeter that DORA, NIS2, AVAEM and ACAM all leave invisible.

The Shadow AI Vendor Exposure Diagnostic (SAVED) is a five-axis model for enterprise architects assessing exposure to OAuth-installed, employee-authorised, agent-capable AI tools that operate outside formal vendor governance.

Axis	Domain	Regulatory Trigger	SAVED Diagnostic Question
1. Identity Perimeter	OAuth scope discovery	DORA Art. 28; NIS2 Art. 21	Do you have a current inventory of every third-party app connected to your enterprise IdP — by scope, by user, by data class?
2. Data Egress Topology	Token-mediated access	GDPR Art. 32; AI Act Art. 50	Do you know which fourth-party AI tools can read which data classes — and where the resulting data is stored, copied, or fine-tuned?
3. Token Lifecycle	Issuance / revocation	NIS2 Art. 21; ISO 27001 A.5.18	Are OAuth tokens decommissioned at offboarding, with evidence? Are dormant or unused tokens revoked on a defined cadence?
4. Regulatory Visibility	Register inclusion	DORA Art. 28–44	Are OAuth-connected AI tools that touch protected data classes recorded in your Register of Information and supplier lists?
5. Pivot-Path Containment	Lateral access boundary	NIS2 Art. 21; AI Act Art. 50	If a fourth-party AI tool is compromised, can the attacker pivot to environment variables, secrets, payment surfaces, or customer data?

Score each axis 1 to 5: 1 means not assessed, 5 means continuously evidenced under your compliance framework.

A composite SAVED score below 12 indicates critical fourth-party exposure. If Axis 5 (Pivot-Path Containment) scores below 3, an OAuth-mediated AI tool compromise can reach production. Most enterprises today score a 7.

Axis 1 (Identity Perimeter) is the most commonly absent. Most enterprise architecture functions have never produced an inventory of third-party OAuth grants against the enterprise IdP. The data exists — it lives in Google Admin’s Third-Party Apps view, Microsoft Entra’s Enterprise Applications, Okta’s OAuth grants. It has not been treated as architecture data. It is.

Axis 5 (Pivot-Path Containment) is the most consequential. The Vercel breach was not catastrophic because Context.ai was breached — it was catastrophic because Context.ai’s compromise had a path to environment variables. That path was an OAuth scope that should have been narrower than “Allow All”, an account boundary that should have been narrower than “enterprise Google Workspace = enterprise Vercel admin”, and a secret store that should have been less reachable from a productivity-app session.

That is not a Context.ai problem. It is an architecture problem. And it is now a compliance problem.

THREE ACTIONS FOR ENTERPRISE ARCHITECTS THIS QUARTER

1. Run the OAuth perimeter audit before the next quarter ends. Pull the third-party app grants from your enterprise IdP — Google Workspace, Microsoft Entra, Okta. Filter to AI-category tools and to tools with broad scopes (drive.readonly, mail.read, directory.read.all, full Workspace impersonation). For each, identify the user who granted it, the date of grant, the last time it accessed your tenant, and the data class it can reach. This is a one-day exercise — and most enterprise architects have never done it.

2. Add the fourth-party class to your DORA Register, NIS2 supplier list, and AVAEM map before August. DORA’s Register is not optional. NIS2’s supply-chain assessment is not optional. The Digital Omnibus has not deferred either. By August 2, 2026 — the date Article 50 activates — every fourth-party AI tool that handles protected data must have a regulatory home: an entry, an owner, an assessment, an offboarding evidence trail. If your governance framework does not have a category that fits, add one.

3. Score yourself with SAVED — and act on Axis 5 first. The five axes can be assessed in a single workshop with your CISO, IAM lead, and EA function. Most organisations will discover that Axis 1 is empty and Axis 5 is structurally indefensible — that an OAuth-compromised productivity tool can reach environment variables. Fix Axis 5 first: narrow OAuth scopes, separate identity domains for production access, and stop persisting long-lived secrets in the same identity boundary as productivity tooling. The Vercel breach is the explicit, public, dollar-priced demonstration of why.

The attack vector that breached Vercel was not novel. It was visible — in every Google Workspace admin panel, in every Entra Enterprise Apps log, in every Okta OAuth grants table — for the past five years.

It just was not in any architecture artefact.

That is the gap SAVED is designed to close.

ABOUT THE AUTHOR

Paulo Falcão is a Fractional Enterprise Architect, AI Strategist, and Transformation Leader with over 25 years of experience. He operates at the intersection of payments systems, enterprise architecture, AI strategy, and European digital regulation — helping mid-market organisations build architectures that are audit-ready, resilient, and prepared for the next structural shift in technology.

The Hawk Nest Newsletter is published weekly on LinkedIn. Follow Paulo Falcão for the next edition.