Vercel breach shows why agent authority needs continuous control

At a glance

What this is: This analysis examines how a third-party AI tool compromise turned a persistent OAuth grant into inherited access across Google Workspace and Vercel environments.

Why it matters: IAM teams need to treat agent authority as continuously governed delegated access, not a one-time consent event, because inherited privileges can outlive the original user decision.

Context

The core governance gap here is not password theft or a broken login flow. It is delegated authority that remains active after the original approval context has changed, which is a poor fit for human-era IAM assumptions.

In this case, the agent tool’s Google Workspace OAuth grant gave the attacker a path to inherited authority after the third-party tool was compromised. That changes the control question from who signed in to whether the grant should still exist and still be valid for the current task.

This is an autonomous access problem only if the tool can decide and act independently at runtime. The article supports a non-human identity and delegated-authority framing, not a full autonomous-agent classification.

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 do broad delegated credentials increase downstream environment risk?

A: Broad delegated credentials let a compromise move across identity domains without a fresh login challenge. If a third-party tool can act inside Google Workspace and that workspace touches cloud operational systems, the attacker can pivot from supplier compromise into internal data or environment access. Narrow scoping reduces how far inherited authority can travel.

Q: What do teams get wrong about OAuth consent for agents?

A: They assume consent to access a service is the same as consent to perform a specific action. In practice, OAuth proves capability, not intent. For agents, a send permission should still be followed by a separate approval step whenever the action can disclose sensitive content or create irreversible change.

Q: What should teams do first after a third-party integration is compromised?

A: Contain the integration immediately by revoking tokens, disabling related OAuth grants where needed, and checking for related activity across the same trust boundary. Then identify reachable data, review logs for lateral use, and rotate any secrets that may have been exposed through the connected workflow. The first 24 to 72 hours should focus on scope, not theory.

Technical breakdown

How inherited OAuth authority becomes a control bypass

OAuth consent creates delegated access that can persist well beyond the original approval moment. In this breach pattern, the user did not re-enter credentials, and the attacker did not need to defeat MFA or crack a password. Instead, the compromised third-party tool retained a broad grant that could be exercised against Google Workspace as long as the token or delegation remained valid. That is the failure mode: authorization is attached to the grant, not continuously re-evaluated against the current trust state of the agent and its supplier.

Practical implication: Treat broad OAuth delegation as a standing control surface, not a one-time onboarding step.

Why human session controls do not govern agent sessions

Human IAM assumes bounded sessions, visible re-authentication, and interactive intent checks. Agent access behaves differently: once the grant exists, the system can keep acting at machine speed without the behavioral checkpoints that normally expose risk. The article’s example shows why login-centric controls miss the real exposure. The issue is not whether the user was legitimate at consent time, but whether the delegated authority still matches the current business purpose after the vendor or tool has changed state.

Practical implication: Move control decisions to issuance and runtime enforcement instead of relying on the original sign-in event.

Why downstream cloud exposure follows from over-broad workspace grants

Once the attacker inherited the Workspace authority, they could pivot into Vercel-linked environments and read environment variables that had not been marked sensitive. That matters because delegated identity often becomes a bridge between SaaS control planes and cloud runtime data. The technical problem is not only the initial compromise of the third-party tool. It is that a broad grant created a path from one trusted identity domain into another, expanding the blast radius beyond the original use case.

Practical implication: Scope delegated access to the minimum APIs and data paths needed for the task.

Threat narrative

Attacker objective: The attacker wanted to inherit delegated authority and use it to access downstream environments and secrets without triggering fresh authentication.

1. Entry occurred when attackers compromised Context.ai, a third-party AI tool used by a Vercel employee.
2. Credential access was unnecessary because the attackers inherited the tool’s existing Google Workspace OAuth authority.
3. Escalation happened when that delegated access was used to pivot into Vercel environments and read exposed environment variables.
4. Impact was the loss of downstream trust across a broader identity chain, not a simple account takeover.

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.

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

NHI Mgmt Group analysis

Persistent OAuth grants create authority debt: The Vercel incident shows that delegated access does not expire when the business relationship, threat state, or vendor trust changes. A one-time grant can remain valid long after the original approval context is gone, which makes inherited authority the real risk. The practitioner conclusion is that consent is not governance unless it is continuously revalidated.

Human-session IAM assumptions fail for agent-mediated access: Enterprise IAM still behaves as if access is exercised by a person who signs in, works, and signs out. This case shows that a third-party tool can hold broad authority continuously and transfer risk across systems without another login event. The implication is that session-based controls alone cannot govern delegated machine access.

Agent authority needs continuous authorization, not just authentication: The defining problem is not whether the actor once authenticated correctly. It is whether each action remains justified under current policy after compromise, scope drift, or supplier failure. That makes runtime evaluation the governance boundary, and practitioners should stop treating consent screens as the end of control.

Over-broad delegation turns supplier compromise into platform compromise: Once the agent’s Workspace grant was inherited, the attack path crossed from a third-party tool into enterprise systems that trusted the same identity chain. That is a classic blast-radius problem in non-human identity governance. The conclusion is that third-party access must be judged by downstream reach, not by onboarding convenience.

Grant-level security is the named concept this breach sharpens: A grant-level exploit is where the attacker inherits already-approved authority rather than stealing fresh credentials. That concept matters because it collapses the gap between supply-chain compromise and identity abuse. Practitioners should recognise that the control point is the grant itself, not the user’s original authentication event.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Grant-level security is the real control boundary: Identity teams need to stop treating consent screens as durable trust decisions. The security question is whether a delegated grant still deserves to exist after the supplier, tool, or access pattern has changed.

This incident also widens the scope of third-party risk management for IAM programmes. If an external tool can inherit broad workspace authority, then offboarding, scope review, and runtime enforcement become connected controls rather than separate admin tasks.

For practitioners

• Inventory every broad OAuth grant to third-party tools Identify which agent or SaaS integrations hold persistent Google Workspace or similar delegated authority, then rank them by downstream reach into cloud environments and sensitive data.
• Replace standing delegation with scoped, short-lived authority Limit each integration to the minimum APIs, data objects, and time window needed for the task, so compromise of the tool does not automatically inherit broad workspace reach.
• Add runtime checks to privileged agent actions Require per-request validation for high-impact actions such as reading environment variables, changing workspace data, or crossing into production environments.
• Review third-party AI tools as supplier trust dependencies Treat each externally managed agent or integration as a supply-chain dependency whose compromise can transfer authority into your environment.

Key takeaways

• The breach shows that persistent delegated access can outlive the trust conditions that created it, which makes inherited authority a first-class identity risk.
• The exposure path was not a password compromise but a grant compromise that moved from a third-party AI tool into enterprise environments.
• Continuous authorization, tight scope, and supplier-aware revocation are the controls most likely to contain this failure mode.

Key terms

• Grant-level exploit: A grant-level exploit is an attack that abuses already approved delegated access instead of stealing a fresh password or token. In agent and integration ecosystems, the dangerous asset is the permission grant itself, because it can survive vendor compromise and continue authorising actions until it is revoked or narrowed.
• Persistent delegation: Persistent delegation is a long-lived permission relationship that allows one identity or tool to act on behalf of another over time. In NHI and agent contexts, it becomes risky when the original purpose has expired but the authority remains active, creating inherited access far beyond the original task.
• Inherited Authority: Inherited authority is the permission attached to an account, role, or workflow that lets the current holder perform actions on behalf of the organisation. In takeover scenarios, the attacker abuses that inherited authority to make valid requests rather than breaking the system directly.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

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.