Vercel-style OAuth trust paths expose NHI risk in AI tooling

At a glance

What this is: This is a breach analysis of how a sanctioned OAuth grant, a compromised AI assistant, and readable environment variables formed a multi-hop identity path into Vercel environments.

Why it matters: It matters because IAM, IGA, and PAM teams need to govern OAuth grants, NHI exposure, and AI tool access as one attack surface rather than separate admin tasks.

👉 Read Unosecur's analysis of the Vercel-style OAuth trust path and NHI exposure

Context

OAuth trust paths are now a practical identity security problem, not an abstract integration concern. In this incident, a routine approval for an AI assistant created persistent access that later became the path into production environments.

The governance gap is structural. Traditional IAM models still assume access is visible, human-paced, and reviewed often enough to matter, while non-human identities, OAuth grants, and environment variables accumulate outside those assumptions.

For identity teams, the relevant question is not whether the tool was approved, but whether the approval created durable access that could survive compromise elsewhere in the chain.

Key questions

Q: What breaks when an AI assistant is approved with broad OAuth access and later compromised?

A: The trust model breaks because the compromise does not need to defeat authentication again. A stolen OAuth grant can preserve access into mail, drive, directory, and downstream SaaS systems long after the original approval, turning a normal productivity integration into a durable attack path.

Q: Why do OAuth grants and NHI secrets create persistent exposure in cloud environments?

A: They outlive the person who approved them and often remain valid until someone explicitly revokes or rotates them. That persistence means a compromise can surface weeks or months after the original action, when no one is watching the original approval event anymore.

Q: What are the signs that environment variable handling is becoming a security risk?

A: Look for secrets stored in variables that are left at default sensitivity, reused across deployments, or readable by broad project roles. If developers treat variable creation as routine configuration instead of secret classification, the environment is already acting like a hidden credential store.

Q: How should teams respond when an OAuth-connected AI tool has been exposed?

A: Revoke the suspicious grant, rotate the credentials it could reach, and review all linked SaaS identities for abnormal access paths. Then narrow the tool's scopes so a future compromise cannot inherit broad workspace authority from a single approval.

Technical breakdown

How a routine OAuth grant becomes durable access

OAuth consent is often treated as a one-time administrative action, but the grant usually persists until it is explicitly revoked. In this case, the approved AI tool inherited broad Google Workspace scopes so it could read mail, calendar, drive, and directory data. That made the approval operationally useful and structurally risky. Once the tool itself was compromised, the attacker did not need to break authentication again. The stolen grant already represented legitimate, persistent access into the employee's workspace and everything connected to it.

Practical implication: inventory OAuth grants as standing access, not one-off approvals.

Why environment variables are identity assets, not just configuration

Environment variables often hold database URLs, API keys, auth tokens, and deployment credentials. That makes them non-human identities in practice because they authenticate systems to other systems. The article's key point is that sensitivity was opt-in, so non-sensitive variables were readable by default. That is not a minor misconfiguration. It is a trust model that assumes developers will manually classify secrets correctly every time, which is unrealistic at scale and especially brittle in fast-moving delivery pipelines.

Practical implication: classify environment variables by default and treat them as governed credentials.

Why traditional perimeter and endpoint controls miss SaaS identity compromise

The attack path stayed inside authenticated SaaS control planes, moving from an AI assistant to Google Workspace and then to Vercel environments. Perimeter tools saw sanctioned traffic, not malicious protocol abuse. Endpoint tools were equally blind because the compromise lived in cloud identity relationships, not local exploit activity. This is why SaaS identity compromise requires identity telemetry, grant review, and credential exposure monitoring rather than only network or device-based detection.

Practical implication: extend detection to OAuth, SaaS, and credential-exposure signals, not just endpoints.

Threat narrative

Attacker objective: The attacker sought persistent access to cloud and deployment credentials that could be used to reach production systems and sensitive secrets.

1. Entry occurred through a routine OAuth approval for an enterprise AI assistant that already had broad Google Workspace access.
2. Credential access followed when the assistant was compromised and the attacker inherited its persistent access into the employee's Workspace account.
3. Escalation and lateral movement occurred as the attacker pivoted from Workspace into Vercel internal environments and enumerated environment variables and other secrets.
4. Impact was the exposure path into deployment-related credentials and sensitive application configuration, creating a viable route to production access and downstream supply-chain risk.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth trust is now a standing-privilege problem, not an approval problem: The approval event is only the start of the risk, because the grant persists long after the person who approved it stops thinking about it. That makes the real governance unit the lifecycle of the grant, not the moment of consent. Identity programmes that still treat OAuth as a point-in-time decision miss the exposure window that attackers exploit. The practitioner conclusion is that consent, scope, and revocation must be governed as one continuous control domain.

Non-human identities are the hidden connective tissue of modern compromise: This incident moved because the attacker could traverse AI tooling, SaaS identity, and environment variables without ever needing a classic endpoint exploit. That is exactly why NHI governance is now inseparable from cloud and workspace security. Ephemeral trust debt: the longer a grant, token, or environment variable remains valid, the more it can be repurposed after the original business reason has faded. The practitioner conclusion is that visibility into NHI inventory is no longer optional.

Environment variable defaults create an identity blast radius: If non-sensitive is the default state, then the security model assumes every creator will remember to classify every secret correctly under delivery pressure. That assumption fails at scale. The breach shows that a default-readable variable can be as damaging as an exposed token once it is chained into a live deployment. The practitioner conclusion is to treat default readability as a governance defect, not a convenience choice.

Access review processes are not enough when the attack path is created outside the review window: Conventional recertification assumes there will be a stable object to review later. In this case, the relevant access path already existed, remained active, and became dangerous only after another identity was compromised. That breaks the premise behind periodic review as a sole safeguard. The practitioner conclusion is that review must be paired with continuous grant governance and credential exposure detection.

Identity security has become a trust-path discipline: The relevant question is no longer whether any single account was compromised, but how many trusted relationships were left open between approved tools, cloud identity, and deployment systems. That is a governance problem spanning IAM, NHI, and operational security. The practitioner conclusion is that teams need to map and score the paths, not just the identities.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams

What this signals

OAuth consent is becoming a hidden governance layer inside enterprise identity programmes. Once a tool is granted broad Workspace scopes, the exposure window lasts until revocation, not until the original business task ends, which means access review cadence alone is too slow to be relied on.

Ephemeral trust debt: the longer an OAuth grant, environment variable, or delegated AI tool permission stays live, the more valuable it becomes to an attacker after compromise. That changes the programme priority from periodic cleanup to continuous grant inventory and revocation discipline.

Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec. That gap matters here because default-readable configuration becomes an attack path when secrets classification is treated as optional.

For practitioners

• Audit OAuth grants as standing access Review enterprise OAuth approvals for broad Workspace, SaaS, and cloud scopes, then revoke anything that no longer has a current business need. Focus on AI assistants and productivity tools first because they often accumulate the widest access.
• Reclassify environment variables as governed secrets Treat database URLs, API keys, auth tokens, and webhook credentials stored in environment variables as managed credentials, not ordinary configuration. Require sensitivity by default and verify that deployment pipelines cannot read variables meant to stay secret.
• Monitor stealer-log exposure for employee credentials Add threat intelligence checks for employee credentials that appear in infostealer logs, and treat that as a trigger to revoke sessions, rotate credentials, and inspect OAuth-linked accounts. This closes the blind spot where valid credentials are already circulating before an incident is visible.
• Scope third-party AI tools to the minimum usable data Limit AI assistants to the specific Workspace objects and documents they actually need, then reassess those scopes whenever the vendor posture or integration pattern changes. Broad mail, drive, and directory access should be exceptional, not the default.
• Separate deploy credentials from long-lived workspace access Move toward short-lived federation for deployment access and avoid letting workspace-linked identities double as production credentials. The goal is to make compromise of an assistant or employee mailbox less useful to an attacker.

Key takeaways

• This breach shows that a routine OAuth approval can become a durable compromise path when the approved AI tool is later taken over.
• The incident chain moved through sanctioned identity relationships rather than malware or a zero-day, which is why conventional perimeter control missed it.
• Governance fails when grants, secrets, and environment variables are treated as separate tasks, because attackers only need one surviving trust path.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Environment Variable Secret: An environment variable secret is a sensitive value injected into a container through its runtime environment rather than a mounted file. This is operationally convenient, but it increases exposure because applications, logs, and diagnostic output can accidentally reveal the value during errors or debugging.
• Trust Path: A trust path is the sequence of systems a request passes through before identity controls or service access complete. It includes resolution, routing, verification, and policy enforcement, so weak controls anywhere in the path can undermine the assurance of the final access decision.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The step-by-step identity chain from employee OAuth approval to Workspace compromise and Vercel environment access
• The specific audit checks for Google Workspace, GitHub, and Vercel administrators
• The incident-response sequence for revoking grants and rotating exposed credentials in priority order
• The vendor's discussion of how default-readable environment variables changed the blast radius

👉 The full Unosecur post covers the identity chain, exposed secrets, and containment steps in detail.

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.