Vercel breach shows why agent authority needs continuous control

At a glance

What this is: A Vercel breach exposed how a compromised third-party AI tool can inherit broad OAuth authority and read downstream environment data.

Why it matters: It matters because IAM, NHI, and PAM teams now have to govern delegated agent authority as a standing access problem, not a one-time login event.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read SecureAuth's analysis of the Vercel breach and agent authority risks

Context

Agent authority is the delegated ability for a software identity, including an AI tool or connected service, to act on behalf of a user or system. This breach matters because the authority was not stolen through password theft. It was inherited through a broad, persistent OAuth grant that outlived the context in which it was approved, which is a familiar failure mode in NHI governance.

The primary identity security problem is not a failed login. It is a standing delegation model that assumes trust at consent time remains valid later, even after the connected tool has been compromised. That assumption breaks down quickly when AI-connected services can act continuously across enterprise platforms and downstream environments.

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 OAuth grants create such a large attack surface for AI tools?

A: OAuth grants can persist across long-running sessions and often authorize more than the immediate task requires. That makes them attractive to attackers because compromise of the connected tool can translate directly into legitimate-looking access across enterprise platforms and downstream systems.

Q: How do security teams know whether delegated access is actually governable?

A: Look for a distinct workload identity, a separate role, and a durable event trail that preserves which application initiated the action. If the platform cannot distinguish the service from the human in logs, the delegation model is not governable at investigation time.

Q: Should organisations treat AI-connected tools like privileged accounts?

A: Yes. If a software delegate can act across core business systems, its access should be governed like a privileged identity with explicit ownership, scope limits, review cadence, and revocation criteria. Otherwise, the organisation is relying on trust that it cannot continuously verify.

Technical breakdown

How broad OAuth delegation becomes inherited authority

OAuth delegation gives a third-party application an access token or scope that lets it act within a user’s permitted boundaries. In this case, the dangerous part was persistence: the grant remained valid after the AI tool was compromised, so the attacker did not need to crack a password or bypass MFA. They inherited a pre-approved authority chain. That is structurally different from session theft because the token’s legitimacy was not in question, only the trust placed in the delegate. When delegation is broad and durable, compromise of the delegate becomes compromise of every downstream action it can perform.

Practical implication: scope delegated access tightly and treat every third-party OAuth grant as a governed identity relationship, not a convenience feature.

Why human IAM controls fail against agent sessions

Human IAM models expect intermittent login, MFA, and step-up checks at meaningful decision points. Agent sessions behave differently: they authenticate once, then continue at machine speed with little or no re-evaluation. That means the control plane often sees a valid session, not a hostile one, even when the agent’s behaviour has drifted. Traditional conditional access can miss this because the original authentication was legitimate and the session looks normal from a protocol perspective. The failure is not authentication strength alone. It is the lack of runtime authorization against the current action and current intent.

Practical implication: move from login-centric controls to per-action authorization and session-level policy enforcement for connected AI tools.

What environment variable exposure reveals about secret boundary design

Environment variables often carry operational secrets, API keys, and integration tokens, but many teams do not classify all of them as sensitive or apply equivalent runtime protections. In this incident, the attacker read variables that were not marked sensitive, which shows how governance labels can become operational blind spots. Once an attacker has inherited a trusted workspace identity, the difference between marked and unmarked data becomes a policy gap rather than a technical safeguard. If downstream systems rely on the assumption that only explicitly sensitive values matter, compromise scope expands fast.

Practical implication: classify environment variables by blast radius, not by convenience naming, and protect them as part of workload identity governance.

Threat narrative

Attacker objective: The attacker aimed to inherit trusted delegated access, pivot into enterprise and customer environments, and extract operational secrets and data.

1. Entry occurred when attackers compromised a third-party AI tool that had been granted broad access to a user’s Google Workspace account.
2. Escalation happened when the attacker inherited the OAuth authority attached to that tool and used it to pivot into Vercel environments.
3. Impact followed when the attacker read exposed environment variables and extended access into downstream systems that trusted the delegated identity.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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 agent authority is now the primary NHI risk surface for AI-enabled enterprises. The breach shows that security teams are no longer only governing service accounts and API keys. They are governing persistent authority granted to software entities that can be compromised upstream and still remain operationally trusted downstream. The implication is that NHI governance must track who can act, for how long, and on whose behalf, not just which credential exists.

One-time consent is a broken governance assumption for agent-era identity. It was designed for a world where approval and use were tightly coupled, and where a grant could reasonably be revisited before it caused major harm. That assumption fails when the actor is a connected AI tool that runs continuously and inherits authority without a fresh authentication challenge. The implication is that identity programmes must treat consent as the start of governance, not the end of it.

Agent authority creates an identity blast radius that exceeds the original business case. A user may approve a tool for a narrow workflow, but the underlying grant often allows broader access than the use case justifies. Once that delegate is compromised, the blast radius follows the token, not the intended task. Practitioners should interpret this as a lifecycle and privilege design problem, not simply a phishing or account takeover event.

Continuous authorization is becoming the dividing line between mature and obsolete identity control. Human-centric checkpoints do not map cleanly to software that acts at machine speed and can chain requests without interruption. The field is moving toward per-action enforcement, attested identity, and bounded delegation because the old assumption of stable, reviewable privilege no longer holds. Teams that still rely on static approval inherit static risk.

Environment variables are a governance boundary, not just an implementation detail. When a trusted delegate can read unmarked variables, the access model is already too broad. The practical lesson is that data exposure, runtime identity, and delegated authorization now have to be governed together, or the weakest of them will define the breach outcome.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same report.
• For a broader breach pattern library, see The 52 NHI breaches Report for recurring control failures and root causes.

What this signals

Agent authority is becoming a governance category of its own: teams need to map which software delegates can inherit access, how long that authority persists, and where revocation actually takes effect. In practice, this is less about the novelty of AI and more about whether existing IAM and PAM processes can still see the real actor before the session has already done the damage.

The operational signal is that consent-based integrations now create hidden blast radius unless they are continuously re-authorized. As organisations expand connected AI usage, the control gap will move from login security to delegated-use governance, which is exactly where NHI programmes have to become more precise.

For practitioners

• Inventory every third-party OAuth grant Map which connected tools can act inside core platforms, what scopes they hold, and whether those scopes are still justified by the current business use case.
• Replace standing delegate trust with bounded authorization Limit agent and third-party scopes to the minimum required task, then enforce short-lived, task-scoped access instead of durable grants that survive beyond the session.
• Classify environment variables by blast radius Treat API keys, backend credentials, and operational tokens in environment variables as governed secrets, regardless of whether they are marked sensitive in the platform UI.
• Add runtime checks for delegated actions Evaluate each action against current policy at the API edge so inherited authority can be blocked when behaviour diverges from the approved use case.
• Review offboarding for software delegates Extend JML and access review processes to connected AI tools and integrations so revoked business need translates into revoked authority.

Key takeaways

• This breach shows that compromised AI tools can inherit valid enterprise authority without stealing a password or bypassing MFA.
• The risk scales because broad OAuth grants and unmarked environment data can turn a single delegated access path into a multi-system exposure event.
• Teams need continuous authorization, bounded delegation, and secret classification that follows blast radius rather than UI labels.

Key terms

• Agent Authority: The permission an AI agent receives to act on behalf of a verified person. In this model, authority is inherited rather than original, so governance must trace the agent back to the human intent, device context, and current trust state that authorised it.
• 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.
• Bounded Delegation: Bounded delegation is the practice of limiting how far authority can move from one identity to another, and under what conditions. For agentic systems, the boundary must cover tool choice, execution timing, and downstream hops, or accountability quickly becomes ambiguous.
• 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.

What's in the full article

SecureAuth's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step account of how the Context.ai compromise led to inherited Google Workspace authority and downstream access.
• The article's full timeline of the grant-level exploit, including how persistent delegation changed the attack path.
• SecureAuth's explanation of continuous authority, attested identity, and per-request enforcement in practice.
• The source material also includes the product framing around agent authority and runtime governance.

👉 SecureAuth's full post covers the grant-level exploit, the downstream environment exposure, and the control model it recommends.

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.