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

At a glance

What this is: This analysis shows how a routine OAuth grant, compromised AI tooling, and misclassified environment variables can create an identity-driven compromise path without exploiting code or endpoints.

Why it matters: It matters because IAM and NHI teams need controls that continuously govern grants, tokens, and secrets across SaaS and AI workflows, not just human login events.

By the numbers:

• In 2025, 75% of organisations expressed strong confidence in their secrets management capabilities, yet the average estimated time to remediate a leaked secret was 27 days.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Unosecur's analysis of the Vercel OAuth compromise and NHI exposure

Context

AI tool adoption has turned OAuth grants, environment variables, API keys, and service connections into part of the enterprise identity surface. The problem is not just access, but persistence: once a grant is approved, it often remains active far longer than the business context that justified it. For IAM and NHI practitioners, that creates a governance gap that traditional joiner-mover-leaver processes do not cover.

The Vercel incident described in the source article is a useful case study because it ties together human approval, compromised SaaS access, and exposed non-human credentials. The starting position is increasingly typical in modern engineering environments, where AI assistants and workflow tools are granted broad scope to function. What is atypical is how clearly the chain exposed the weaknesses that many organisations still leave unmanaged.

Key questions

Q: How should security teams govern OAuth grants used by AI tools?

A: Treat OAuth grants as standing non-human identities, not temporary app settings. Require owner assignment, sensitivity review, scope minimisation, and periodic reauthorisation. If the app can read mail, files, or directory data, it should be on a review schedule and revocable without waiting for an incident.

Q: Why do AI assistants increase non-human identity risk?

A: AI assistants often need broad delegated access to be useful, which means a compromise can expose more than one system at once. They can also sit between users and SaaS controls, making the grant itself the real attack surface. That is why they need identity governance, not just vendor approval.

Q: What is the difference between secret rotation and access review?

A: Secret rotation replaces the credential itself, while access review checks whether the identity should still have the privilege at all. Both are necessary, but access review reduces standing exposure and rotation limits reuse after compromise. In practice, reviews should trigger rotation when a grant or secret is no longer justified.

Q: How can organisations reduce blast radius when an AI tool is compromised?

A: Limit the tool's scope, separate high-risk functions from general collaboration data, and make revocation fast enough to matter. Pair least privilege with short-lived tokens, clear ownership, and logging that links the agent, the user, and the downstream system. Containment only works when those paths are visible.

Technical breakdown

Why OAuth grants become durable attack paths

OAuth was designed to let applications act on a user's behalf without sharing passwords. The security trade-off is that a one-time approval can create long-lived delegated access across mail, storage, calendar, and directory data. In AI tooling, that scope is often broad because the tool needs enough context to be useful. Once the grant exists, compromise of the third-party application can turn into access to the user and then to downstream systems that trust that identity. For NHI governance, the grant itself becomes an identity object that needs inventory, review, and revocation discipline.

Practical implication: Track OAuth approvals as privileged identities and review them on a schedule, not only during incident response.

How environment variables become production secrets

Environment variables are often treated as configuration, but in production they frequently hold secrets such as database URLs, signing keys, webhook tokens, and API credentials. The risk increases when systems treat sensitivity as opt-in, because the default state can be readable unless a developer explicitly marks the value otherwise. That creates a mismatch between how engineers think about a variable and how attackers use it. In NHI terms, the secret is not just stored data, it is an authenticating identity with access scope that can be enumerated, copied, and replayed.

Practical implication: Classify every environment variable that grants access as a secret and enforce sensitive-by-default handling.

Why AI tools behave like first-class identities

An AI assistant that can read mail, calendar, files, and internal documents is not just software. It is an agentic identity with delegated execution authority and the ability to traverse trust boundaries on behalf of a human. That matters because compromise of the agent can create indirect access to systems that were never intended to be reachable through a single human account. This is where NHI governance and agentic AI security overlap. The control question is no longer whether the user is authenticated, but whether the agent's permissions, token lifetime, and downstream access paths are proportionate to the task.

Practical implication: Treat AI assistants as governed principals with bounded scope, session-level monitoring, and explicit revocation paths.

Threat narrative

Attacker objective: The objective was to move from a trusted AI workflow into reusable credentials and environment access that could support broader platform compromise.

1. Entry through a compromised AI assistant that already held delegated Google Workspace access via OAuth.
2. Escalation after the attacker used the Workspace foothold to reach the employee's Vercel-linked environment and enumerate secrets.
3. Impact through exposure of readable environment variables, access tokens, and downstream configuration tied to production systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Identity sprawl, not code weakness, is the real control failure. The article's core lesson is that modern environments are being compromised through sanctioned identities that were approved for convenience, not through novel exploits. That pattern is increasingly common because OAuth grants, API keys, and AI tool tokens are hard to see and easy to accumulate. Practitioners should stop treating these objects as administrative clutter and start treating them as attack paths.

Ephemeral access does not solve trust debt if the upstream grant remains persistent. Just-in-time access can reduce exposure windows, but it does not fix the deeper problem when the delegated identity itself is over-scoped or never reviewed. The article shows that a single approval can unlock a long chain of access across SaaS, cloud, and deployment systems. The practical conclusion is that lifecycle control must begin at the grant, not at the endpoint.

AI agents now sit inside the NHI trust model, not beside it. When an assistant can read corporate data and act through connected services, it should be governed as a non-human identity with explicit policy, telemetry, and revocation. That shifts the centre of gravity from account management to delegation management. Security teams that keep AI tools outside their NHI inventory are leaving an unmonitored principal in the environment.

Secrets classification is a governance issue, not a developer preference. The article's environment-variable detail matters because default visibility can turn normal configuration into exposed production access. Teams need policy that forces sensitivity marking, secret rotation, and redeployment when values change. The broader implication is that NHI risk often begins with classification failure long before an attacker touches a system.

Blast radius control is becoming the decisive metric for AI-era identity security. Once an attacker can move from one trusted service to another, the question is not whether compromise is possible but how far it can travel before containment. That makes inventory, ownership, and rapid revocation the real operational differentiators. Practitioners should design for fast isolation, not perfect prevention.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 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 same pattern reinforces why teams should also study The 52 NHI breaches Report for recurring identity-led compromise paths and control failures.

What this signals

Ephemeral credential trust debt: organisations are adding short-lived tools on top of long-lived approvals, which means the trust relationship outlives the task. That is why AI assistant governance should be reviewed alongside NHI lifecycle controls and not handled as a separate collaboration issue. For teams building roadmaps, the priority is revocation speed, grant inventory, and scope reduction before another automation layer is added.

The operational signal is that secret exposure and identity exposure are converging in the same control plane. With 43% of security professionals concerned that AI systems may learn and reproduce sensitive patterns from codebases, the problem is no longer limited to leaked values. Teams should align NHI inventory, secrets management, and agent oversight so that a compromised tool cannot silently become a trusted bridge into production.

If your programme still relies on periodic human reviews alone, the attack path described in the article will remain hard to see. Pair governance with telemetry from the systems that actually hold delegated access, then map those findings back to ownership and revocation workflows. That is the practical way to reduce blast radius in environments where AI tools and service identities are now intertwined.

For practitioners

• Inventory all OAuth grants as governed identities Export app access inventories from Google Workspace and other SaaS platforms, then review every grant that has mail, drive, directory, or admin scope. Revoke stale integrations, require security approval for sensitive scopes, and assign an owner to each remaining grant.
• Mark secrets sensitive by default Review environment variables, CI/CD secrets, and application config so any value that can authenticate to another system is classified as a secret. Require explicit sensitive labels, rotate exposed values, and redeploy workloads after replacement so old credentials do not remain live.
• Shorten the lifetime of delegated access Move from long-lived keys and durable app approvals toward short-lived credentials and federated access where possible. Use Google OIDC federation or equivalent trust patterns so access can be bounded to task duration and revoked centrally when risk changes.
• Monitor AI tools as first-class principals Place AI assistants and workflow agents into the NHI inventory, then monitor their token use, scope changes, and unusual access paths. If an agent can read internal data or act on behalf of users, it needs the same oversight applied to service accounts and other privileged NHI types.

Key takeaways

• Routine OAuth approvals can create durable attack paths when AI tools and SaaS accounts are over-scoped.
• Environment variables, tokens, and delegated grants are identities, not administrative details, and they need lifecycle control.
• The strongest response is faster containment through inventory, sensitivity classification, and revocation discipline.

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: A non-human identity is any credentialed entity that authenticates to systems without a person directly typing a password, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities need lifecycle control because they often carry privileged, persistent, and poorly reviewed access.
• Identity Blast Radius: Identity blast radius is the amount of downstream access an attacker can reach after compromising a single identity or grant. It is a practical measure of how far a trust path can travel across SaaS, cloud, and production systems before detection or revocation stops it.
• Agentic AI Principal: An agentic AI principal is an AI system that can execute actions and access tools on behalf of a user or service account. It behaves like a governed identity because its permissions, token lifetime, and data reach determine how much harm a compromise can create.

What's in the full article

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

• The full step-by-step response sequence for preserving audit evidence before making changes.
• The exact OAuth client ID and Google Workspace navigation path used to validate exposure.
• The prioritised credential rotation order across GitHub tokens, Vercel variables, and deployment secrets.
• The vendor's remediation checklist for scoping down GitHub App access and reviewing OAuth grants.

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

Deepen your knowledge

AI agent governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI assistants and SaaS grants from a similar starting point, it is worth exploring.