OAuth is the New MCP: Lessons From the Vercel - Context AI Incident
The Vercel incident is being described as a third-party breach. That is true, but incomplete. The real story is that OAuth scopes have become agentic capabilities, and most organizations still treat third-party SaaS access as a checkbox.
The incident, simplified
Based on Vercel’s public security bulletin, the compromise chain looked like this:
This chain matters because it is not a single bug. It is a graph problem:
- People connect “helpful” tools to high-trust identity providers
- OAuth scopes silently become standing privileges
- Attacker steals tokens and becomes the app
- Vendor and customer systems interpret that as normal behavior
The safest breach path is the one that looks like normal product usage. OAuth is not a login feature. It is a delegation mechanism. In 2026, delegation is an attack surface.
Why this is an agentic security problem, not just an IAM story
Agentic systems popularized a concept security teams already knew but did not operationalize at scale:
- Capabilities are what matter, not “apps”.
- Toolchains are supply chains.
- Standing privileges are liabilities.
OAuth scopes are effectively “tools” that a third-party system can call on your behalf. When those scopes include read access to documents, email, drive, calendars, or admin APIs, you have created a privileged integration that behaves like an agent.
Put bluntly
If you would not let a code-executing MCP server read your Drive, do not let a Chrome extension do it either.
Where the blast radius hides: “non-sensitive” secrets
Most modern developer platforms store environment variables. Some values are explicitly marked as sensitive and encrypted with stricter rules. Others are treated as plaintext or decryptable under normal product flows.
The Vercel bulletin explicitly recommended rotating values that were not marked as sensitive. That is the second lesson:
- Organizations routinely store secrets in places labeled “not secret”.
- Attackers do not care what your UI labels them.
- Any value that can unlock an API, database, or signing operation is a secret.
OWASP Agentic Top 10 (2026) mapping
This incident chain maps cleanly to agentic risks, even if no LLM was involved at execution time.
- ASI03 (Identity and Privilege Abuse): OAuth delegation turns a third-party system into a privileged actor.
- ASI04 (Agentic Supply Chain): the third-party tool becomes upstream of your identity and data plane.
- ASI07 (Insecure Inter-Agent Communication): if you model OAuth token usage as “messages” and “calls”, you realize most orgs do not have integrity, provenance, or anomaly detection at the delegation boundary.
A practical control model: treat OAuth like production code execution
Below is a pragmatic way to move from “we have SSO” to “we can survive OAuth compromise.”
| Control | What it blocks | What to implement |
|---|---|---|
| Scope minimization | Over-broad delegated access | Only allow whitelisted OAuth scopes for third-party apps. Deny “read all drive” by default. |
| Token governance | Long-lived and invisible delegation | Set maximum token lifetime. Rotate and revoke on a cadence. Require re-consent for high-risk apps. |
| App inventory | Shadow AI and shadow integrations | Maintain a live catalog of OAuth apps: owner, scopes, last used, and business justification. |
| Anomaly detection | “Normal-looking” attacker behavior | Alert on new OAuth apps, new scopes, unusual access patterns (bulk reads, new geos, unusual clients). |
| Secret classification | Secrets stored as plaintext “non-sensitive” config | Continuously scan env vars for secret material. Default secrets to protected storage. |
| Containment playbook | Slow incident response cycles | Pre-approved steps: revoke app, rotate tokens, invalidate sessions, audit env var reads, quarantine projects. |
If your organization cannot answer “which OAuth apps can read our Drive” in under 10 minutes, your SaaS identity plane is already a supply chain.
The mindset shift
The agentic era did not invent new security problems. It made two existing problems impossible to ignore:
- Delegation is power.
- Power needs continuous governance.
OAuth is just delegation with a friendly UI.