Vercel Breach via Google Workspace OAuth — Why Every Microsoft 365 and Google Workspace Tenant Needs App Control

Vercel was breached through a compromised Google Workspace OAuth application belonging to Context.ai, a third-party AI tool used by a Vercel employee. When Context.ai was compromised, attackers gained access to every Google Workspace account that had previously consented to the Context.ai OAuth app — including the Vercel employee's account. From there, they pivoted into Vercel's internal environments and read customer environment variables that were not marked as sensitive. Vercel confirmed the incident in an official bulletin on 19 April 2026.

Yes — and it is one of the most common ways SaaS tenants are breached in 2026. Any staff member who signs in to a third-party SaaS tool using "Sign in with Google" or "Sign in with Microsoft" grants that tool an OAuth token with access to their mailbox, files, or calendar. If that third-party SaaS tool is compromised, the attacker inherits that access. Without OAuth app governance in Google Workspace or Microsoft Entra, any employee can authorise any app with no visibility or approval. AyeTech locks this down across every managed tenant.

Whatever the user granted the app access to — and most apps request broad scopes. Common leaked data includes full mailbox contents, attachments, OneDrive and Google Drive files, SharePoint libraries, Teams or Slack messages, calendar entries with meeting contents, contact lists, and — in dev-heavy organisations like Vercel — source code, environment variables, API keys, and database credentials. OAuth tokens survive password resets and typical MFA, so compromise can persist for months undetected. AyeTech's cyber security services audit every connected app across your tenant.

In Microsoft Entra ID, navigate to Enterprise apps > Consent and permissions and set user consent to either "Do not allow user consent" (fully centralised) or "Allow user consent for apps from verified publishers for selected permissions" (a safer baseline). You should also enable the admin consent workflow so users can request access through a managed process. This requires Entra ID licensing and an understanding of which apps your business legitimately needs. AyeTech configures this across all managed Microsoft 365 tenants. Get in touch to have your tenant checked and locked down.

In the Google Admin console, go to Security > Access and data control > API controls and move your organisation to "Restricted" for Google services. Then individually review every third-party OAuth app under "Third-party app access" and mark each as Trusted, Limited, or Blocked. You should also enable OAuth scope-based controls so apps cannot quietly expand their permissions in the future. Finally, review the OAuth Token audit log to see which apps your staff have already connected. AyeTech can audit your tenant and implement the full hardening baseline.

You need to audit every app consent across every user account, cross-reference against known malicious app IDs (Vercel published the Context.ai app ID as 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com), review API access logs for unusual bulk reads of mailboxes or files, and check for new mail forwarding rules the attacker may have created. This is not a five-minute job. AyeTech runs this audit across every managed tenant and continues to monitor for new OAuth consents every day. Call us on 02 9188 8000 for an immediate assessment.

Yes. AyeTech performs OAuth app audits across Google Workspace and Microsoft 365 tenants as part of our cyber security services. We list every connected app, review scopes, flag risky consents, revoke unused access, enforce admin consent workflows, and hunt for known malicious OAuth app IDs in your tenant. Contact AyeTech on 02 9188 8000 for a free SaaS security assessment.

An OAuth token is a credential issued by an identity provider (Google or Microsoft) after a user successfully authenticates and consents to a third-party app. The token lets the app access defined resources without prompting the user again. Because MFA was completed at the moment of consent, subsequent API calls using the token do not re-challenge the user — the token itself is proof of a completed authentication. If an attacker steals the token, they inherit that completed authentication. This is why MFA, password resets, and most Conditional Access sign-in controls do not stop token replay.

Context.ai is an AI-agent platform used for enterprise workflow automation. Multiple outlets, including The Hacker News and BleepingComputer, identified Context.ai as the compromised third-party tool referenced in Vercel's 19 April 2026 bulletin. It is the kind of SaaS that employees in tech-forward businesses sign up for individually without IT involvement — often to trial AI workflows, summarisation, or agent-driven automation. That routine self-service signup created the consent that gave attackers access.

ShinyHunters is a threat actor handle that has been associated with numerous high-profile data theft and extortion incidents since 2020. In the Vercel incident, a threat actor using that name posted on a hacking forum claiming to have breached Vercel and offered the stolen data for approximately $2 million. Vercel has not officially attributed the incident to any specific group in its public bulletin. Claims made under the ShinyHunters brand should be treated as the stated identity of the seller rather than verified attribution.

Access tokens are typically valid for about one hour, but refresh tokens — which let an app obtain a new access token without reprompting the user — commonly stay valid for 90 days or longer and can be automatically renewed. In practice, if nothing revokes the consent, a refresh token can persist for months or years. This is the critical problem with OAuth app compromise: a token granted today can still be working silently for an attacker long after the employee has left the company, changed their password, or forgotten the app even exists.

No. OAuth tokens are independent of the user's password. A password reset does not invalidate existing tokens for most third-party OAuth apps. To revoke access, you must explicitly remove the app's consent: in Google, at myaccount.google.com > Security > Third-party apps & services > See all connections > select app > Remove access; in Microsoft, at myapplications.microsoft.com > profile > Manage your account / app permissions; or from the admin console at a tenant level. In an incident, admins should revoke all refresh tokens, remove the app consent, and rotate any secrets the app could have accessed — all of which AyeTech handles as part of incident response.

Shadow SaaS is the collection of third-party cloud applications that staff sign up for and connect to corporate accounts without IT visibility or approval. Each connection creates an OAuth consent — which is effectively a persistent access grant to your corporate data stored in someone else's infrastructure. The danger is that IT does not know the app exists, does not know what data it accesses, does not know the vendor's security posture, and will not know when the vendor gets breached. The Vercel/Context.ai incident is a textbook shadow SaaS outcome.

The core user-consent restriction (disabling user consent or limiting it to verified publishers) is available with any Microsoft Entra ID tier, including the free tier bundled with Microsoft 365 Business Basic. The admin consent request workflow is also available without paid Entra licensing. Advanced behavioural detection — app governance via Microsoft Defender for Cloud Apps — requires a higher-tier license. The baseline lockdown is therefore available to every Microsoft 365 customer at no extra cost; most businesses just never change the defaults.

The Google Workspace Admin console API controls for third-party app access are available across all paid Google Workspace tiers, including Business Starter, Business Standard, Business Plus, and Enterprise. Any Google Workspace admin can move the tenant to Restricted for Google services, review third-party app access, and block or allow apps individually. Some advanced scope-based controls were rolled out to general availability in late 2024 and are widely available today.

If the breach involves personal information and is likely to result in serious harm, yes — under the Notifiable Data Breaches scheme operated by the Office of the Australian Information Commissioner (OAIC), eligible data breaches must be reported to the OAIC and affected individuals as soon as practicable. The "we did not know the app was connected" defence does not exempt an organisation from notification obligations. If an OAuth app had access to customer emails, contact lists, HR files, or other personal data and a breach is suspected, the notification clock starts when the organisation becomes aware.

MITRE ATT&CK technique T1528 is "Steal Application Access Token" — the technique of obtaining OAuth or other application tokens to gain access to resources. The Vercel/Context.ai incident is a textbook T1528 case: attackers obtained OAuth tokens from a compromised third-party application and used them to access resources as the token owner. Defensive mapping involves restricting user consent, reviewing granted scopes, monitoring for unusual token use, and maintaining an inventory of approved applications.

A full audit should happen at least quarterly, and ideally monthly. New apps should trigger review on connection (which is exactly what the admin consent workflow does). A baseline audit is essential on day one for any tenant that has been running with default settings — because the existing consent backlog is usually large. AyeTech runs continuous OAuth inventory review for managed tenants, so new consents are reviewed as they happen rather than once per quarter.

A Microsoft verified publisher is an app developer whose Microsoft AI Cloud Partner Program account (formerly the Microsoft Partner Network) has been verified and whose app has been confirmed to be associated with that verified publisher's Entra tenant. A verified badge appears in the consent prompt and Enterprise apps page. Limiting user consent to verified publishers raises the bar significantly — unverified publisher apps cannot be consented to by end users and require admin approval — without blocking legitimate vendors. It is a middle ground between free-for-all consent and fully centralised control.

In Google Workspace Admin console API controls, each third-party OAuth app can be categorised as Trusted (the app has access to all requested Google Workspace services, including restricted scopes), Limited (the app can only access unrestricted Google services, regardless of what it requests), Specific Google data (the app is restricted to only the OAuth scopes you explicitly allow — scope-based control, generally available from late 2024), or Blocked (users cannot consent to or use the app at all). Best practice is to default the tenant to Restricted, mark only vetted apps as Trusted, leave most apps Limited or scope-restricted, and Block anything unnecessary or unknown.

Partially, but not by default. Standard Conditional Access policies are typically scoped to interactive user sign-ins — they do not automatically apply to service principals or workload identities using OAuth tokens. Microsoft offers Conditional Access for Workload Identities (a separately licensed SKU — "Workload Identities Premium") and app governance through Defender for Cloud Apps, both of which can detect and block suspicious token activity. Combining user-consent restriction, admin consent workflow, Token Protection / Continuous Access Evaluation, and workload identity Conditional Access provides the strongest layered defence.

Yes — arguably worse, because corporate controls do not apply to personal accounts. If a staff member connects a SaaS tool to a personal Gmail or Outlook.com account that also receives work email, and the SaaS vendor gets breached, corporate data in that mailbox is exposed without any way for IT to audit, monitor, or revoke. This is one of the reasons AyeTech recommends strict separation between personal and corporate accounts and enforces forwarding/delegation restrictions on corporate mailboxes.

A phishing attack tricks the user into entering credentials on a fake site or approving a rogue MFA prompt. Defences like phishing-resistant MFA (FIDO2, passkeys), user training, and email filtering can prevent or detect it. An OAuth app breach does not involve fake sites, stolen passwords, or MFA prompts. The user legitimately authenticated to a legitimate app months earlier. The attacker exploits the third party's compromise, not the user's behaviour. This is why the defence is consent governance — not awareness training. See our related post on device code phishing for another OAuth-based attack vector.

Yes. Vercel CEO Guillermo Rauch said on X that he suspects the attackers were "significantly accelerated by AI," citing the velocity and depth of understanding they demonstrated of Vercel's systems — framed as his personal assessment rather than a formal attribution. AI-assisted attackers can more quickly parse stolen tokens, map scopes, fingerprint internal systems, and identify the highest-value pivot paths. The defensive implication is that the window between initial compromise and full exploitation is shrinking — making proactive controls like consent restriction and continuous token monitoring more important, not less.

Tell them the truth: their corporate Google or Microsoft account is the crown jewel, and connecting it to a random SaaS tool gives that vendor persistent access to company data. When the vendor gets breached — which happens regularly — the attacker inherits their access. Explain that they can still request access to legitimate tools through the admin consent workflow, usually approved within hours. Framing this as "we want you to use great tools safely" rather than "no" preserves productivity while eliminating silent exposure.

It depends on the policy, but many cyber insurance policies are tightening exclusions around supply chain attacks and around breaches caused by inadequate access controls. If your tenant allowed unrestricted user consent and no OAuth app inventory was maintained, an insurer may argue inadequate security controls as grounds to reduce or deny a claim. Review your policy wording and talk to your broker. Implementing OAuth consent restriction, admin consent workflow, and continuous audit is increasingly considered baseline due diligence.

For Google Workspace, log in to the Admin console, go to Security > API controls > App access control > Manage third-party app access, and search for the app client ID published by Vercel (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com). If present, block it and revoke consent for every user. For Microsoft 365, review Enterprise apps in the Entra admin centre for any Context.ai-related app and remove it. Beyond this specific incident, the broader question — how many other unknown apps have access — requires a full OAuth audit. Call AyeTech on 02 9188 8000 and we will run the full audit for you.

No. Vercel also suffered an OAuth-related incident earlier through the Nx package / GitHub supply-chain compromises, which is why several commentators have framed the April 2026 Context.ai incident as "Vercel got pwned by an OAuth app — again." The lesson is that OAuth app compromise is a recurring class of attack, not a one-off. Organisations that treat it as an ongoing governance discipline — inventory, consent restriction, audit — suffer fewer incidents than organisations that treat each breach as an isolated surprise.

OAuth 2.0 is the industry-standard protocol that lets a user grant a third-party application limited access to their account data on another service — without sharing their password. When you click "Sign in with Google" or "Sign in with Microsoft" and consent to a list of permissions, the service issues the third-party app a token that represents that authorised access. The app can then call APIs on your behalf until the token expires or consent is revoked. OAuth is everywhere in modern SaaS — which is exactly why compromised OAuth apps are such a high-impact attack vector.

An access token is a short-lived credential (typically about one hour) that lets an app call APIs on the user's behalf. A refresh token is a longer-lived credential the app uses to obtain a new access token without re-prompting the user — Microsoft's default refresh token lifetime is 90 days, and Google production apps often have effectively indefinite refresh tokens unless unused for six months or revoked. If an attacker steals a refresh token, they can silently keep generating new access tokens for months. This is why revocation of the app's consent — not just password rotation — is essential in incident response.

Any business running Microsoft 365 or Google Workspace is at risk, but the sectors most exposed are those where staff enthusiastically adopt new SaaS tools without central IT approval: professional services (legal, accounting, consulting), creative agencies, tech and SaaS companies, health and wellness, property, and financial services. Industries handling regulated data (health, finance, legal) also face the highest downstream cost because a breach automatically triggers OAIC NDB obligations, client confidentiality breaches, and potential professional-conduct consequences.

Revoking consent invalidates the refresh token and prevents the app from minting new access tokens — but any already-issued access token remains valid for its remaining lifetime (up to about an hour). Additionally, if the attacker used the OAuth access to create mail-forwarding rules, create new OAuth consents to secondary apps, add new sign-in methods, or exfiltrate data to external storage, those persistence mechanisms survive the revocation. Proper incident response requires full remediation — not just consent removal. AyeTech handles this end-to-end for managed clients.

Report to the Office of the Australian Information Commissioner using the Notifiable Data Breach form at oaic.gov.au. The form captures the nature of the breach, the personal information involved, the steps the organisation has taken to contain and assess it, and the notification being made to affected individuals. Reports should be lodged as soon as practicable after reasonable grounds to believe an eligible breach has occurred. AyeTech's incident response includes preparation of NDB paperwork, engagement with the OAIC where required, and coordinated notification to affected individuals.

Microsoft Defender for Cloud Apps is Microsoft's Cloud Access Security Broker (CASB) product, which includes an "app governance" feature that continuously discovers OAuth apps registered in your Entra tenant, profiles their behaviour, and alerts on suspicious activity — over-permissioned apps, unusual bulk API reads, consent by a risky user, or tokens being used from anomalous locations. It is a higher-tier licensed feature (typically bundled in Microsoft 365 E5 or purchased standalone) and it is the strongest continuous-monitoring layer on top of user-consent restriction.

Token Protection (sometimes called token binding) is a Conditional Access feature that cryptographically ties a refresh token to the device that originally received it. If an attacker steals the token and tries to use it from a different device, Microsoft rejects the authentication. Token Protection is one of the strongest defences against token replay attacks like the Vercel/Context.ai scenario, but it requires modern client support and specific Conditional Access licensing. It is still rolling out across the Microsoft ecosystem and is not yet a complete solution, but it is the trajectory of where enterprise token security is heading.

Continuous Access Evaluation is a Microsoft Entra feature that allows real-time revocation of access tokens in response to critical events — password change, user disablement, MFA credential revocation, high-risk sign-in detection. Without CAE, access tokens remain valid for their full lifetime regardless of what happens to the underlying user. With CAE enabled and supported by the client, a compromised account can be locked out within minutes rather than hours. CAE is on by default for most modern Microsoft 365 scenarios, but administrators should verify it is enforced and that legacy clients are not bypassing it.

Delegated permissions are scopes granted to an app acting on behalf of a signed-in user — the app can only access what the user can access. Application permissions (often called "app-only" or "workload identity" permissions) let the app act without any user — typically with broader, tenant-wide access. Application permissions are more powerful and should always require admin consent. Many high-impact OAuth breaches involve apps that were granted application permissions (for example Mail.Read at tenant scope) without adequate review. AyeTech audits both permission types across managed tenants.

Not entirely — "Sign in with Google" or "Sign in with Microsoft" is often more secure than letting staff create separate passwords per SaaS tool, because it centralises authentication and MFA. The risk is not the SSO button; it is the OAuth consent that usually accompanies it. The right answer is to keep SSO but control what apps are allowed to request consent (via the admin consent workflow) and what scopes they can be granted (via scope-based restrictions). AyeTech configures this balance across every managed tenant.

At minimum: confirm the vendor has SOC 2 Type II or ISO 27001 certification, review their security and privacy pages for evidence of encryption, access control, and breach response, check their status page for past incident history, review the OAuth scopes they require against what they actually need, check the publisher verification badge in the consent prompt, and search for the vendor's name alongside "breach" or "incident" before granting access. Large organisations run this through a formal vendor risk assessment. Smaller organisations rely on their MSP — AyeTech performs this evaluation for managed clients on request.

OAuth app governance is not a named Essential Eight strategy, but it directly supports several of them: Restrict Administrative Privileges (by preventing silent delegation of access via consent), Multi-Factor Authentication (by preserving MFA's effectiveness against token replay), Application Control (by treating OAuth apps as application-layer code that needs control), and User Application Hardening. Many maturity level 2 and 3 organisations find that OAuth app governance is required to pass a full Essential Eight audit, even though the framework does not name it explicitly. See our Essential Eight compliance guide for more detail.

Underwriters increasingly ask whether user consent is restricted in Microsoft 365 and Google Workspace, whether a third-party app inventory exists, how often it is reviewed, and how OAuth consent is monitored. Documentation should include: a screenshot or configuration export of user-consent settings, a current app inventory with risk ratings, the most recent audit log, and a policy statement describing consent and revocation procedures. AyeTech provides managed clients with underwriting-ready OAuth governance documentation as part of cyber security services.

Very similar pattern. In the 2025 Salesforce/Drift incident, attackers compromised the Drift chatbot vendor and inherited OAuth tokens that gave access to every Salesforce customer that had connected Drift. In April 2026, attackers compromised Context.ai and inherited OAuth tokens that gave access to every Google Workspace tenant that had connected Context.ai — Vercel being the highest-profile victim. The recurring pattern is: one upstream SaaS vendor breached, hundreds of downstream customers exposed. The only reliable defence is consent governance and continuous app audit on the downstream side — because you cannot control the upstream vendor's security.

Act in this order: revoke the app's consent and delete the enterprise application / remove third-party app access; revoke all refresh tokens for every user who consented; reset the users' passwords and sign them out of all sessions; audit mail-forwarding rules, inbox rules, and OAuth consents for secondary apps the attacker may have created; review audit logs for bulk mailbox or file reads, data exfiltration, and sign-ins from unfamiliar IPs; rotate any secrets the app could have accessed (API keys, connection strings); and begin the NDB assessment if personal information is involved. Call AyeTech on 02 9188 8000 if you want this run for you.

A service principal is the identity that a third-party application uses inside your Microsoft Entra tenant when it acts on your organisation's behalf. Every time a user consents to an app, a service principal for that app is created in your tenant. Service principals hold the permissions that were consented to — which is why auditing them is the core activity of OAuth governance. If a service principal has broad scopes and belongs to an obscure vendor, that is exactly what an attacker inherits if the vendor is breached.

Yes — both platforms expose per-user app consent data. In Google Workspace, the Admin console OAuth log events and the OAuth grant activity report break down consents by user, app, and scope. In Microsoft Entra, Enterprise apps and the Sign-in logs show which users have consented to which apps and when. This data lets you identify the "shadow SaaS power users" who have granted the most consents — a common risk pattern, because those users become the highest-value accounts for attackers to target.