Your OAuth Apps Are a Supply Chain Time Bomb: How the Vercel Breach Exposed the Third-Party Trust Gap

You didn't write the code that got breached. Your developers didn't push a secret. Your CI pipeline passed every scan. And yet, in April 2026, Vercel watched attackers stroll through their internal systems via a compromised third-party AI tool called Context.ai. The entry point wasn't a CVE, a leaked password, or a phishing email. It was an OAuth grant that someone approved months ago and never reviewed again.

46% of organizations cannot effectively monitor non-human identities, according to the Cloud Security Alliance's State of SaaS Security report. 56% report active concern about overprivileged API access in SaaS-to-SaaS integrations. Meanwhile, the average enterprise has hundreds of OAuth apps connected to their Google Workspace, Slack, GitHub, and AWS accounts—most of them invisible to security teams, many with scopes that would make an auditor weep.

OAuth didn't fail. It worked exactly as designed. The failure was trust management: we treated third-party OAuth apps as "just another integration" instead of as external infrastructure with direct access to our crown jewels.

The Vercel breach follows a pattern that security researchers are now calling the "toxic combination"—a permission breakdown between two or more applications bridged by an OAuth grant that no single application owner ever intended to authorize as one coherent risk surface.

Here's how the chain actually worked:

Step 1: Compromise the Third Party. Context.ai, an AI productivity tool, was breached. Not Vercel. Not Google. A small third-party app that one employee found useful. This is the supply chain reality: your security is only as strong as the weakest OAuth app connected to your identity provider.

Step 2: Harvest OAuth Tokens. The attackers didn't need to phish Vercel employees. Context.ai already held valid OAuth tokens for Google Workspace—tokens that had been granted months earlier during a routine "Sign in with Google" flow. When Context.ai was compromised, those tokens became the attacker's tokens.

Step 3: Pivot to Corporate Identity. With a valid Google Workspace token, the attacker assumed the employee's identity. Not an admin account. Not a service account. Just a regular user account that happened to have enough access to reach internal Vercel systems.

Step 4: Lateral Movement and Data Exfiltration. From the compromised account, the attacker moved laterally into Vercel's infrastructure and enumerated environment variables. Vercel emphasized these were "non-sensitive," but that's a distinction customers don't care about when their deployment credentials are involved.

This wasn't sophisticated APT tradecraft. It was an OAuth app doing exactly what it was authorized to do—except the credential holder had changed hands unnoticed.

Most security processes evaluate access one app at a time. That works when identities are human, permissions are static, and integrations are cataloged. OAuth apps violate all three.

They grant persistent, unattended access. Unlike human sessions that expire in hours, OAuth refresh tokens can remain valid for months or years. The employee who approved Context.ai in 2024 might have left by 2026. The token didn't.

Scopes are written by vendors, read by no one. When a user clicks "Allow," they're approving whatever scopes the vendor requested. Most users—and security teams—never audit whether an AI assistant truly needs read access to all Drive files, or whether a CI integration needs admin privileges to every repo.

The blast radius crosses organizational boundaries. An OAuth app doesn't just access one system. It bridges them. Context.ai connected to Google Workspace, which connected to Vercel's internal identity fabric. Security teams rarely trace downstream to what that access enables in other platforms.

Detection is nearly impossible with existing tooling. SIEMs detect abnormal user behavior. They don't detect when a SaaS provider's database is dumped and its OAuth tokens sold. Requests from compromised tokens look legitimate because, technically, they are.

You cannot protect what you cannot see. The first step is treating OAuth apps as infrastructure, not accessories.

1. Maintain a Living OAuth App Inventory.

Every OAuth grant in your organization should be documented: who approved it, what scopes it requested, what systems it connects, and when it was last used. Google Workspace, Microsoft 365, GitHub, Slack, and AWS all expose APIs to enumerate OAuth grants. Use them.

Here's a Python script that audits Google Workspace OAuth grants and flags high-risk scopes:

import json
from googleapiclient.discovery import build
from google.oauth2 import service_account

HIGH_RISK_SCOPES = {
    "https://www.googleapis.com/auth/admin.directory.domain.readonly",
    "https://www.googleapis.com/auth/admin.directory.user",
    "https://mail.google.com/",
    "https://www.googleapis.com/auth/drive",
    "https://www.googleapis.com/auth/cloud-platform",
}

def audit_oauth_grants(admin_email: str, credentials_path: str):
    creds = service_account.Credentials.from_service_account_file(
        credentials_path,
        scopes=["https://www.googleapis.com/auth/admin.directory.domain.readonly"],
        subject=admin_email,
    )
    service = build("admin", "directory_v1", credentials=creds)

    results = service.tokens().list(userKey=admin_email).execute()
    tokens = results.get("items", [])

    flagged = []
    for token in tokens:
        scopes = set(token.get("scopes", []))
        risky = scopes & HIGH_RISK_SCOPES
        if risky:
            flagged.append({
                "client_name": token.get("displayText", "Unknown"),
                "risky_scopes": list(risky),
                "all_scopes": list(scopes),
            })

    return flagged

if __name__ == "__main__":
    grants = audit_oauth_grants("admin@company.com", "service-account.json")
    for g in grants:
        print(f"[!] HIGH RISK: {g['client_name']}")
        print(f"    Scopes: {', '.join(g['risky_scopes'])}")

Run this weekly. If an app requests https://mail.google.com/ and it's not your approved email platform, revoke it immediately.

2. Enforce Principle of Least Privilege at the Identity Provider.

Configure your IdP to restrict which OAuth apps can be installed. Google Workspace supports admin-controlled app whitelisting. Microsoft 365 has Enterprise App consent policies. GitHub has OAuth App access restrictions. Use them. Default-allow is default-compromised.

3. Monitor for Token Abuse Patterns.

SIEM rules should trigger when OAuth tokens are used from new geographies, unusual user agents, or outside business hours. More importantly, monitor for token reuse across multiple sessions—legitimate SaaS apps don't typically clone tokens across disparate infrastructures.

4. Rotate and Expire.

OAuth refresh tokens should not live forever. Google Workspace supports setting maximum token lifetimes. Implement quarterly OAuth grant reviews. If an app hasn't been used in 90 days, revoke its access. The cost of re-approving a legitimate app is trivial compared to the cost of a breach.

5. Audit Environment Variable Exposure.

The Vercel breach specifically involved environment variable enumeration. Before sharing .env files, debugging logs, or deployment configurations, sanitize them. Even "non-sensitive" variables leak service names, region identifiers, and internal endpoint patterns that attackers use for reconnaissance.

The Vercel breach wasn't a zero-day. It wasn't advanced persistent threat tradecraft. It was a predictable outcome of treating OAuth apps as harmless utilities instead of as privileged infrastructure with direct access to production systems.

Your OAuth inventory is your new asset inventory. Every third-party app with a valid token is a potential lateral movement bridge. Every stale grant is a dormant breach path. And every unreviewed scope is a trust boundary waiting to collapse.

The attackers didn't hack Vercel's code. They hacked Vercel's trust model. If you don't know every OAuth app connected to your organization, what scopes they hold, and when they were last audited, you're not doing security. You're doing hope.

Start with inventory. Enforce least privilege. Set expiration policies. And for the love of all that is secure, stop treating "Sign in with Google" as a convenience instead of a architectural decision with production consequences.