Ungoverned AI agents turn OAuth access into NHI breach paths

TL;DR: A compromised third-party AI agent and OAuth token can become a lateral movement path into internal environments and exposed credentials, as Vercel’s breach shows according to the company’s incident write-up. The lesson is that NHI governance has to cover discovery, ownership, and policy enforcement before an agent becomes an invisible access layer.

At a glance

What this is: This is a breach analysis showing how an ungoverned third-party AI agent with OAuth access became the entry point for broader access to internal environments and credentials.

Why it matters: It matters because AI agents now operate as non-human identities, and without inventory and policy control they can bypass the governance model most teams use for human users.

Key highlights:

• Vercel stores all customer environment variables encrypted at rest, but variables not designated as sensitive could still be read.

Context

AI agent governance is now an identity problem, not just an application control problem. When a third-party tool authenticates through OAuth and reaches internal systems, it behaves like a non-human identity with real authority, and conventional IAM programmes often lack the inventory and ownership needed to track that access.

The Vercel incident illustrates a common failure mode in NHI governance: access is granted indirectly through connected tools, but oversight remains tied to the human account that approved the integration. That gap is especially dangerous when environment variables, tokens, and API keys are reachable through paths nobody has classified as sensitive.

This starting position is not unusual. Many organisations are adding AI agents faster than they can map the identities, permissions, and trust relationships those agents create.

Key questions

Q: How should security teams govern third-party AI agents that use OAuth access?

A: Security teams should treat third-party AI agents as governed non-human identities, not informal integrations. Require inventory, named ownership, scoped OAuth permissions, periodic review, and a fast revocation path. The goal is to prevent delegated access from becoming an invisible privilege layer that can reach internal systems without clear accountability.

Q: Why do AI agents create more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: What is the difference between secret storage and secret governance for agents?

A: Secret storage is about where credentials sit. Secret governance is about who or what can reach them, under what conditions, and whether that access is intentional. For AI agents, governance matters more because a secret that is reachable in runtime can be used even if it is encrypted at rest.

Q: When does AI agent access become a board-level security concern?

A: It becomes board-level when an agent can reach production environments, administrative tools, or credential stores that can expand impact beyond the original use case. At that point, the issue is no longer a tooling decision. It is a governance and risk decision about how much organisational trust is being delegated to software.

Technical breakdown

How OAuth-connected AI agents become unmanaged NHI access paths

An OAuth-connected AI agent can inherit broad access without ever becoming a formal managed account in the IAM programme. The agent authenticates through delegated permissions, then operates continuously across systems, often through API calls and workspace integrations that look routine in logs. That creates a hidden trust chain: the human approves the app, the app receives tokenised access, and downstream systems treat those calls as legitimate. If the organisation has no inventory of agents, no ownership model, and no policy boundary for their actions, the agent becomes an unmanaged non-human identity with real reach.

Practical implication: Treat every third-party AI integration as a governed identity with explicit ownership, scope, and revocation controls.

Why environment variables and secrets often become the escalation point

Environment variables are convenient for application runtime, but they are also a common place for API keys, tokens, and database credentials to accumulate. In agentic workflows, those values can be exposed to any component that can read the runtime context or associated configuration. Encryption at rest does not help if the application path is authorised to read the variable after decryption. The security issue is not simply storage, it is reachable credential surface. Once a compromised agent can enumerate variables that were not classified as sensitive, escalation becomes a matter of chaining valid secrets rather than breaking cryptography.

Practical implication: Classify and isolate secrets by sensitivity, and assume agent reachability can turn ordinary configuration into escalation fuel.

What changes when monitoring shifts from alerts to policy enforcement

Traditional monitoring often detects suspicious behaviour after a downstream system raises an alert. Policy enforcement works earlier by defining what an agent may access, which actions it may perform, and which targets are out of bounds. That distinction matters because AI agents can move quickly and continuously, making late detection almost indistinguishable from no control at all. A policy layer creates auditability, but it also establishes a hard boundary for sanctioned behaviour. In NHI governance terms, the difference is between observing a breach path and constraining it before lateral movement begins.

Practical implication: Use enforceable policy controls for agent actions, not just log review after the fact.

Threat narrative

Attacker objective: The attacker aimed to convert delegated AI agent access into broader internal access and credential-enabled escalation.

1. Entry occurred through a compromised third-party AI tool with Google Workspace OAuth access tied to a Vercel employee.
2. The attacker used that delegated access to reach internal environments and read environment variables that were not marked as sensitive.
3. Those variables contained API keys, tokens, and database credentials that enabled further escalation across Vercel infrastructure.

NHI Mgmt Group analysis

Ungoverned AI agents are now a primary NHI governance risk, not an edge case. The Vercel incident shows that delegated access can outpace the controls teams built for human identities. When agents connect through OAuth, service accounts, and API tokens, they create authority that is real even when it is not formally inventoried. Practitioners should treat every agent integration as a governed identity lifecycle problem.

Identity blast radius is the right concept for understanding agent exposure. The dangerous part of this breach path was not only initial access, but the amount of infrastructure reachable once the agent was trusted. NHI governance has to measure how far a compromised agent can move, what secrets it can enumerate, and which downstream systems inherit that trust. Teams should reduce blast radius before they attempt to perfect detection.

Inventory without ownership is not governance. A list of connected AI tools does not solve the problem if nobody is accountable for scope, review, and revocation. Organisations need a named owner for each agent, a defined business purpose, and a revocation path when the integration no longer fits policy. Practitioners should close ownership gaps first, because unmanaged ownership becomes unmanaged access.

Secret exposure paths must be modelled as agent access paths. If an AI system can read runtime variables, it can often reach credentials that were never meant to be broadly accessible. That shifts secret management from a static storage problem to a dynamic access problem. Security leaders should align secret classification, runtime controls, and agent policy so that readable does not automatically mean usable.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to the same research.
• For a broader view of how identity trust breaks down across real incidents, see The 52 NHI breaches Report for case patterns and root causes.

What this signals

Identity governance is being stretched by agentic workflows faster than most programmes can absorb. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the trust boundary is already porous before an incident occurs. Teams that still separate application risk from identity risk will miss the way AI agents inherit authority through delegated access rather than direct provisioning. The practical response is to fold agent inventories, ownership, and revocation into the same governance motion that already covers privileged access and access review.

Shadow AI becomes a structural issue when agent access is opaque. The Vercel-style failure mode is not just that a tool exists, but that nobody can quickly answer what it touches and who owns it. That makes runtime discovery and policy enforcement more valuable than one-time approval workflows. Security programmes should prepare for agent sprawl as an operating condition, not an exception case.

For practitioners

• Map every third-party AI integration Build a current inventory of all third-party AI agents, OAuth apps, and workspace connectors, then record the identities they use, the systems they can reach, and the business owner responsible for each connection.
• Restrict delegated access by default Limit OAuth scopes to the smallest viable permission set and require a review before any agent gains access to internal environments, environment variables, or admin-level APIs.
• Classify secrets by reachable impact Separate ordinary configuration from sensitive credentials, and assume any value readable by an agent or integration can be used for escalation if it is not explicitly isolated.
• Add policy enforcement to monitoring Use controls that block unapproved agent actions in real time, especially access to environments, tool invocation, and credential retrieval, then review the resulting audit trail for exceptions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Key takeaways

• AI agents can function as non-human identities with delegated authority that conventional IAM programmes do not reliably govern.
• Once an agent can reach internal environments and readable variables, secrets can become the escalation path rather than the end state.
• The right control model is inventory, ownership, scoped access, and enforceable policy, because visibility alone does not constrain blast radius.

Key terms

• Non-Human Identity: A non-human identity is any machine-used credential or account that can authenticate and act in a digital environment. In practice, this includes service accounts, API keys, tokens, certificates, and AI agents. The governance challenge is that these identities often move faster and with less visibility than human users.
• OAuth Delegation: OAuth delegation is the act of granting an application access to systems or data on behalf of a user or organisation. It is common in modern integrations, but it can create broad downstream authority if scopes are too wide or the connected application is compromised.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and credentials that become reachable if an identity is compromised. For AI agents and other NHIs, it is a useful way to measure governance quality because the main risk is often not the initial compromise, but how far the access can spread.
• Secret Exposure Surface: Secret exposure surface is the set of places where credentials can be read, copied, or misused by systems and integrations. It includes environment variables, configuration stores, runtime memory, and connected tools. Reducing the surface means limiting both storage and reachability, not just encrypting data at rest.

Deepen your knowledge

AI agent inventory, identity ownership, and secret governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for delegated access and runtime exposure, it is worth exploring.

This post draws on content published by Vercel: the April 2026 incident analysis of an ungoverned AI agent breach path. Read the original.