Vercel’s OAuth compromise shows where agentic AI trust fails

At a glance

What this is: This is an analysis of Vercel's OAuth compromise path through a third-party agentic AI tool, showing how legitimate authorization became the entry point for account takeover and internal environment access.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern third-party OAuth grants and vendor-held tokens as an active trust boundary, not a passive productivity integration.

By the numbers:

• 30 percent of organisations experienced a SaaS or AI supply chain attack last year, highlighting how common these initial footholds have become.
• 87% cannot see sensitive data flows across applications, according to The Agentic Ecosystem Security Gap: 2026 CISO Report.
• 84.8% cannot detect OAuth token or API key abuse, according to The Agentic Ecosystem Security Gap: 2026 CISO Report.

Context

A third-party agentic AI connection can become a security boundary when it holds OAuth tokens that act on a user's behalf across Google Workspace, SaaS apps, or code repositories. In this case, the article describes how compromise of the vendor side turned a routine employee authorization into access that security teams did not directly monitor.

The governance gap is not that OAuth exists, but that broad, persistent authorization is often granted without a security review, then stored in a vendor backend outside the customer's visibility. That creates a trust dependency across identity, SaaS, and non-human access lifecycles that standard MFA and user-centric review processes do not cover.

The Vercel case is best read as a stress test for agentic AI governance. It shows that when an AI tool can hold and use delegated access across systems, the question is no longer whether the user approved the connection, but whether the organisation can see, constrain, and revoke the resulting non-human access path.

Key questions

Q: What breaks when third-party AI tools have broad OAuth access to enterprise systems?

A: Broad OAuth access turns a convenience integration into a standing credential. If the token is compromised, attackers can move through trusted channels without defeating the perimeter. The main failure is not authentication alone, but the lack of scope control, revocation discipline, and visibility into what the connected tool can actually reach.

Q: Why are OAuth tokens risky even when MFA is enforced for users?

A: MFA protects the user login, but OAuth tokens can keep working after the initial approval without repeated user authentication. If the token is long-lived or refreshable, access may persist independently of the user’s password changes, role changes, or departure from the organisation.

Q: How should security teams spot suspicious third-party access in SaaS environments?

A: Watch for new OAuth grants, unexpected scope expansion, token creation, and bursts of enumeration across connected applications. Those signals often appear before visible data theft. Teams should correlate identity logs, SaaS admin events, and connected-app activity so a vendor-side compromise does not look like normal user behaviour.

Q: What should teams do when a connected AI vendor is compromised?

A: They should revoke or quarantine the app, invalidate sessions and tokens, rotate any downstream credentials that may have been exposed, and review whether the vendor held offline refresh material or broad scopes. The key is to contain the delegated trust path before attackers can move from one authorized integration to broader access.

Technical breakdown

OAuth delegation turns user approval into standing vendor-held access

OAuth 2.0 is designed to let an application act on a user's behalf without sharing the user's password. In agentic AI tools, that delegation often becomes persistent because the vendor backend stores refresh tokens or similar authorizations to keep the service useful across sessions. That means the trust boundary moves from the employee's login session to the third-party operator's environment. If the vendor is compromised, the attacker inherits authorized access that still looks legitimate to the target services.

Practical implication: treat delegated OAuth grants for agentic AI tools as governed non-human access, not just user convenience.

Why MFA does not stop token-based access abuse

MFA strengthens interactive sign-in, but it does not invalidate already-issued OAuth tokens. Once a token is granted, the actor can often operate without prompting a new login, which is why the article says the access path was valid from every system's perspective. This is a classic separation between authentication at issuance and authorization during later use. For identity teams, that distinction matters because review controls built around logon events miss token replay, token theft, and vendor-held refresh material.

Practical implication: monitor token issuance, scope changes, and revocation events separately from human authentication telemetry.

Environment variables become sensitive when connected systems can enumerate them

Environment variables are often treated as low-risk configuration, but in connected cloud and application estates they frequently contain API keys, deployment secrets, and service credentials. The Vercel incident shows how an actor who reaches internal environments can enumerate values that were not marked sensitive and use them to widen access. That is not just data exposure. It is a privilege-expansion mechanism because configuration stores often carry the next set of credentials needed to move laterally.

Practical implication: classify environment variables as part of the secret estate when agentic tools or third-party access can enumerate them.

Threat narrative

Attacker objective: The attacker sought to turn delegated third-party access into broader internal access and credential exposure that could support further compromise.

1. Entry occurred through compromise of a third-party agentic AI vendor that already held OAuth-authorized access for an employee.
2. Credential harvesting followed when the attacker appears to have used a compromised OAuth token to access the employee's Google Workspace account.
3. Escalation came from moving into internal Vercel environments and enumerating environment variables that were not marked sensitive.
4. Impact included exposure of some credentials for a limited subset of customers and potential downstream expansion beyond the initial account.

Breaches seen in the wild

• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
• GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated AI access has become an NHI trust boundary, not a user convenience feature. The article shows that a third-party agentic AI platform held OAuth tokens on behalf of a user and that those tokens became the operational path into Google Workspace. That means the real security object is the delegated non-human authority, not the human login that initially approved it. Practitioners should now treat agentic AI grants as governed access relationships with their own lifecycle.

Standing authorization is the broken assumption in this incident. Access review processes were designed for access that remains visible long enough to be recertified, but vendor-held OAuth tokens can persist outside the customer's review cycle. That assumption fails when the actor or platform can use the authorization later, in another environment, without a fresh human decision. The implication is that governance must account for where the authorization lives, not just who approved it.

Environment variables and config stores are part of the identity attack surface when third-party access can enumerate them. The Vercel case shows that once an attacker reaches internal environments, non-sensitive configuration labels do not prevent credential discovery. This is not just a secret hygiene issue. It is an identity governance problem because downstream access often depends on values embedded in runtime configuration. Practitioners should stop assuming config data is outside privilege control.

Agentic AI creates a multi-tenant blast-radius problem for the identity stack. The same tool can sit between a user, multiple SaaS systems, and a vendor backend that stores tokens for later execution. That coupling means one compromise can span human identity, NHI credentials, and third-party service trust in a single chain. Security teams need to evaluate authorizations as ecosystem relationships, not isolated app consents.

Identity visibility must move from login events to token and scope governance. The article's lesson is that the critical security signal was not a failed password check, but a valid token being used in the wrong trust context. That aligns with OWASP-NHI and NIST CSF thinking around entitlement visibility and least privilege. Practitioners should focus on who can mint, hold, and reuse delegated access across systems.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Delegated AI access now behaves like a persistent third-party identity layer. Teams should assume any tool that can read mail, tickets, code, or CRM data may also be holding reusable authorization outside the customer's direct control. That changes the governance question from "did the employee approve this?" to "can we see and revoke every delegated grant before a vendor compromise turns it into access?"

Access review cycles alone will not surface short-lived or vendor-held token abuse because the review event is separated from the execution event. The practical response is to move more of the control point to issuance time, scope approval, and token revocation rather than relying on later certification.

Identity blast radius: when one connected tool can traverse Workspace, SaaS, and environment variables, a single trust break can span multiple control domains in one incident. Practitioners should align IAM, NHI governance, and SaaS administration around that compound exposure rather than treating each app connection as isolated.

For practitioners

• Map all third-party agentic AI OAuth grants Inventory every AI tool connected to Google Workspace, Salesforce, code repositories, and similar systems, then record scopes, admin consent, and token owners. Separate human approvals from vendor-held authorization so you can see which connections create standing access.
• Revoke or constrain broad OAuth scopes Block or require approval for 'Allow All' style permissions, especially where refresh tokens let the vendor act after the employee session ends. Reissue access only through narrower scopes that match the actual business task.
• Classify environment variables as credential-bearing Scan production, staging, and preview environments for KEY, TOKEN, SECRET, PRIVATE, PASSWORD, AUTH, BEARER, JWT, and CLIENT_SECRET patterns, then move anything credential-like into the secret manager. Treat non-sensitive labels as unreliable when connected systems can enumerate values.
• Separate token monitoring from sign-in monitoring Track OAuth issuance, app consent changes, scope escalation, token creation, and revocation as distinct events from MFA and password logins. That gives security teams a way to detect abuse that never triggers another interactive authentication.
• Build a rapid third-party blast-radius playbook Predefine who can suspend apps, revoke sessions, rotate downstream secrets, and review connected service accounts when a vendor-side compromise is suspected. The goal is to contain delegated access before it can be reused across environments.

Key takeaways

• The core issue is not that OAuth exists, but that agentic AI vendors can hold standing delegated access outside the customer's direct visibility.
• The incident shows how compromise of a third-party AI platform can turn one authorised connection into account access, internal enumeration, and credential exposure.
• Teams that can inventory, restrict, and revoke delegated grants quickly will reduce the blast radius of the next vendor-side compromise.

Key terms

• Delegated OAuth Access: Delegated OAuth access is a permission model where an application acts on behalf of a user or workspace after consent is granted. In NHI terms, the app becomes a non-human identity with real reach, so scope, revocation, and monitoring matter as much as the original account credentials.
• Vendor-Held Tokens: OAuth refresh tokens or similar credentials stored and reused by a third-party service so it can act later without asking the user again. The security problem is not the token format itself, but the fact that compromise of the vendor environment can expose valid access to the customer estate.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Token Lifecycle: Token lifecycle is the full sequence of issuing, refreshing, expiring, revoking, and reauthorizing a credential. For delegated access, lifecycle state is the real indicator of whether a connection is still legitimate, because a valid-looking token can still be stale, disconnected, or out of scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.