TL;DR: The Vercel breach began with a third-party OAuth consent grant that stayed valid long enough for attackers to reuse it after the third-party provider was compromised, allowing pivot into internal systems and customer API keys, according to Apono. The incident shows that standing privileges, not just exposed tools, determine blast radius in modern IAM and NHI governance.
At a glance
What this is: Apono’s analysis of the Vercel breach shows how a third-party OAuth grant with standing access let attackers pivot from a compromised supplier into internal systems and customer API keys.
Why it matters: IAM, PAM, and NHI teams need to treat OAuth grants, SaaS integrations, and delegated third-party access as governed privileges, not one-time convenience choices.
Context
The security issue here is not the AI tool itself but the governance model around third-party OAuth consent. When a user grants broad Workspace access to an external app, that delegation can outlive the business need, survive account compromise, and become a standing privilege path into internal systems.
In this case, the relevant identity is the delegated OAuth grant, which behaves like a non-human identity once issued. The breach shows how OAuth consent, SaaS access, and internal resource exposure become one control plane when the grant is broad, persistent, and not lifecycle managed.
The article’s starting point is typical of modern SaaS environments, where convenience defaults often outrun access governance. That makes the Vercel case a useful example of how delegated access can become the real blast-radius driver even when the initial compromise lands elsewhere.
Key questions
Q: What breaks when OAuth grants are never revisited after initial setup?
A: Stale grants preserve access long after the original business need has changed, which means a compromised token can still reach systems no one actively intended it to reach. Without periodic review, employees can accumulate third-party permissions that become invisible but highly reachable attack paths.
Q: Why do broad OAuth scopes increase breach impact?
A: Broad scopes turn one consent decision into multiple reachable resources, which gives an attacker a much larger blast radius if the app is compromised. Mail, drive, calendar, and directory access can expose credentials, internal documents, and organisational structure. The wider the bundle, the more likely the compromise becomes a workspace-level incident rather than a single-app event.
Q: How can security teams tell whether OAuth consent is becoming an access governance problem?
A: Watch for grants that persist across months, vendors with idle but valid tokens, and users who can approve broad scopes without separate review. Those signals show consent is functioning as permanent access rather than temporary delegation, which means lifecycle controls and recertification are missing.
A: Security teams should treat exposed application secrets as a credential incident, not just a vendor issue. The first response is to inventory every affected secret, rotate or revoke it, review sign-in and audit logs for unusual activity, and reduce permissions to the minimum needed. Teams should also restrict management access and validate whether any downstream data access occurred.
Technical breakdown
How standing OAuth grants become inherited access
OAuth is a delegated authorisation model, not a password replacement. When a user clicks Allow All, the app receives a token with the scope the user approved, and that token can keep working until it is revoked or expires. In this case, the third-party app later became compromised, but the important point is that the OAuth grant had already inherited the employee’s trust boundary. That is why the attacker did not need a fresh login to pivot. The grant itself was the durable access path, and its scope defined how far the compromise could travel.
Practical implication: Treat OAuth grants as privileged credentials with lifecycle controls, not as harmless user settings.
Why standing access widens the blast radius in SaaS environments
Standing access means a privilege remains continuously usable even when nobody is actively using it. In SaaS and cloud environments, that creates a hidden attack surface because any stolen token, compromised account, or abused integration can keep reaching internal resources long after the original business action ended. Zero Standing Privileges changes the model by making access time-bound and task-scoped, so a compromise has less opportunity to move from one system to another. The Vercel chain shows how a delegated grant can become the bridge from third-party compromise to internal environment access.
Practical implication: Remove persistent access paths where delegated grants can survive beyond the task they were meant to serve.
Why API keys become reachable after lateral movement
Once attackers reach an internal environment, the next target is often sensitive configuration and secrets such as API keys. These are not just files or variables, they are reusable credentials that can extend compromise into other systems, vendors, or production workflows. The article highlights that the environment variable layer becomes dangerous when access to it is standing rather than exceptional. If the attacker can enumerate or extract those values without a separate approval boundary, the original breach quickly turns into broader credential abuse across the organisation.
Practical implication: Separate secret access from ordinary account access so API keys are never exposed by default to a compromised identity.
Threat narrative
Attacker objective: The attacker aimed to turn a compromised third-party OAuth grant into internal access and reusable customer credentials.
- Entry began with a third-party OAuth consent grant that gave an external app standing access to the employee’s Workspace account.
- Credential access followed when the third-party environment was compromised and the attacker reused the existing OAuth token to authenticate as the employee.
- Escalation occurred when that delegated access let the attacker pivot from Workspace into Vercel’s internal environment and reach sensitive configuration.
- Impact was the theft of customer API keys and broader internal access that expanded the blast radius beyond the original third-party compromise.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
- Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Standing OAuth access is now a privileged access problem, not just an application consent problem. The breach worked because a delegated grant held persistent authority after the business transaction that created it was long over. That is a PAM and lifecycle failure, not a mere SaaS configuration issue. Practitioners should treat OAuth consent as governed privilege with the same seriousness as any other non-human credential.
Ephemeral business need and standing access are structurally incompatible. OAuth grants were designed for delegation, but not for indefinite reuse across changing risk conditions. Once the grant outlives the immediate task, the identity boundary stops matching the operational boundary. The implication is that teams must stop assuming a token remains safe just because the original user is legitimate.
Zero Standing Privileges is the right control lens for third-party SaaS access. The breach shows that access review after the fact is too late when a token can be stolen and reused between review cycles. The relevant governance assumption is that delegated access persists long enough to be observed and recertified, and that assumption is failing in modern SaaS estates. Practitioners need to rework how they define approved access windows.
Environment variables and API keys become collateral when delegated identity can reach them without friction. The incident reveals that secret protection is inseparable from identity scope. If a compromised OAuth grant can enumerate internal secrets, then secret classification alone is not enough to contain blast radius. Teams should read this as a reminder that privilege boundaries, not labels, determine exposure.
Delegated third-party identity needs lifecycle offboarding as much as joiner-mover-leaver does. A grant that is never revoked is an identity that never leaves, even when the tool is forgotten or the vendor changes risk posture. That is how shadow access accumulates quietly across Workspace, Microsoft 365, and adjacent SaaS estates. Security programmes should govern that residual access as part of NHI lifecycle discipline.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: API Key Management Guide
What this signals
Delegated access now behaves like a non-human identity lifecycle problem. Once an OAuth grant is issued, the question is not whether the original user was legitimate but whether the grant still deserves to exist. That shifts governance from login events to privilege persistence, which is where many programmes still have no explicit control owner.
Zero Standing Privileges is increasingly the only clean way to make third-party SaaS access revocable in practice. If a grant can survive vendor compromise, user inactivity, and long gaps between reviews, then it is standing privilege by another name. Security teams should design access policy around expiry, not around the convenience of a one-time consent click.
Identity blast radius is now set by inherited scope. The breach demonstrates that compromise does not need to start inside your own perimeter if a delegated app can inherit broad authority into it. Programmes that govern OAuth, API keys, and SaaS access as separate problems will keep missing the combined control gap.
For practitioners
- Audit standing OAuth grants Inventory every enterprise OAuth consent that can touch Workspace, SaaS apps, or internal environments, then identify which ones remain valid long after the original use case ended.
- Enforce time-bound delegation Move from permanent Allow All permissions to scoped, time-limited grants that expire unless re-approved for a specific task or workflow.
- Separate secret access from workspace access Require a distinct privilege boundary for enumerating environment variables, API keys, and other secrets so a compromised delegated app cannot reach them by default.
- Add offboarding to third-party access reviews Revoke dormant vendor tokens, unused app consents, and stale SaaS integrations on a regular lifecycle cadence, not only when users leave.
Key takeaways
- The breach exposed a governance failure in standing third-party OAuth access, not just a supplier security incident.
- A single broad grant can persist long enough to let attackers pivot from supplier compromise into internal systems and customer API keys.
- Time-bound delegation, explicit revocation, and separate secret-access boundaries are the controls that reduce this blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The breach shows dormant delegated access was never revoked when it outlived its business purpose. |
| NHI-05 — Overprivileged NHI | The employee's grant carried broader access than the task required, enabling lateral movement after compromise. | |
| NHI-07 — Long-Lived Secrets | The token remained valid long enough to be stolen and reused after the supplier breach. | |
| Recommendation — Revoke stale OAuth grants and vendor tokens on a lifecycle schedule instead of leaving them standing. Scope delegated access to the minimum resources needed and deny blanket consent by default. Shorten OAuth token lifetime and require reauthorization for sensitive delegated access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens and API keys are authenticators whose lifecycle must be managed across issuance and revocation. |
| Recommendation — Apply authenticator management controls to issued OAuth grants, token expiry, and revocation. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attacker reused a valid token and then moved from third-party compromise into internal systems. |
| Recommendation — Map delegated-token abuse to credential access and lateral movement detections. | ||
Key terms
- Standing OAuth Grant: A standing OAuth grant is a persistent authorization that lets an application act on a user's behalf without repeated approval. In security terms, it behaves like a reusable credential, so its scope, duration, and ownership need lifecycle controls just like any other privileged access artifact.
- Zero Standing Privileges (ZSP): A security posture where no identity, human or non-human, holds persistent access rights. Access is provisioned dynamically on demand and automatically revoked after use. ZSP is the gold standard for NHI access control.
- Delegated access lifecycle: Delegated access lifecycle is the governance of non-human components that act on behalf of others, including onboarding, permission scoping, recertification, and offboarding. For MCP servers, it means treating the server itself as a governed identity object with a defined blast radius.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org