TL;DR: Akeyless says the Vercel incident shows how a third-party OAuth grant to Context.ai, combined with long-lived environment variables and API keys, let an attacker pivot from a compromised employee account into internal systems and expose customer secrets. The breach is less about code defects than about identity sprawl and static credentials that outlive their intended trust boundary.
At a glance
What this is: Akeyless analyses the Vercel incident as a supply-chain-style identity breach in which a third-party OAuth token and static secrets enabled attacker pivoting into internal systems.
Why it matters: IAM, PAM, and NHI teams need to treat OAuth consent, environment variables, and AI-agent access as one identity supply chain because a single over-scoped grant can outlive the control assumptions around it.
👉 Read Akeyless's analysis of the Vercel OAuth breach and static secret exposure
Context
This breach is really about identity governance, not application code. The attack path started with a third-party OAuth consent, then moved through a compromised workspace account and into internal systems where static secrets lived long enough to be reused.
For IAM and NHI programmes, the important lesson is that OAuth grants, environment variables, and runtime credentials are part of the same trust chain. When each is governed separately, attackers only need one durable credential path to pivot.
The article frames a familiar modern problem: identity sprawl now includes SaaS consent, AI-tool access, and long-lived secrets in production systems. That combination makes traditional boundaries between human access, service access, and machine access too easy to cross.
Key questions
Q: What breaks when broad OAuth consent is left in place for third-party tools?
A: Broad consent turns a third-party app into standing delegated privilege. If that token is later stolen or reused, the attacker inherits whatever workspace access the original grant allowed, often without triggering password or MFA checks. The real failure is not the token alone but the missing lifecycle review around who owns the grant and why it still exists.
Q: Why do long-lived environment variables increase breach impact?
A: Because they preserve usable credentials inside production systems long after the original purpose has changed. Once an attacker reaches them, they can often reuse the values across internal services, databases, and deployment paths. That makes the compromise more durable and more valuable than a one-time access event, especially when rotation is slow or inconsistent.
Q: When should organisations replace static secrets with ephemeral credentials?
A: Use ephemeral credentials whenever a workload can tolerate short-lived access and the secret would otherwise persist across deploys, environments, or teams. That is especially important for CI/CD pipelines, privileged APIs, and automation that touches sensitive data. Ephemeral access reduces exposure, but only if the organisation also enforces revocation and monitoring.
Q: What should teams do when AI tools are allowed to retrieve credentials?
A: Treat the tool as a governed non-human identity with explicit ownership, scoping, and revocation. If it can fetch or forward credentials, it sits inside the same delegated-access chain as service accounts and SaaS integrations. The control question is whether the organisation can remove that access quickly when the tool, user, or business need changes.
Technical breakdown
How OAuth tokens become durable access paths
An OAuth token is not a password in the usual sense, but it can function like one when scopes are broad and the grant is rarely reviewed. In this incident, a valid token bypassed password and MFA prompts because the service accepted the token as proof of delegated access. That is why consent screens are not just a user-experience issue. They create long-lived delegated authority that often outlives the original user intent, especially when third-party tools are approved once and then forgotten.
Practical implication: Review delegated OAuth scope as an access-control surface, not just an app approval list.
Why environment variables and static API keys remain high-value targets
Environment variables often store credentials outside the codebase, but that does not make them less exploitable. Static API keys, database credentials, and deployment secrets can be copied, reused, and monetised long after issuance, which is why they behave like standing privilege. In this breach, the issue was not secret discovery alone but secret persistence inside production systems. The attacker’s value came from finding credentials that still worked across internal workflows and customer environments.
Practical implication: Treat environment-stored secrets as production credentials with a lifecycle, not as configuration data.
Why just-in-time secrets change the attacker’s economics
Just-in-time credentials shift the security property from secrecy to usability window. A credential issued for one session and destroyed automatically after use can still be stolen, but it is far harder to replay at scale. That matters because attackers monetise durable access, not short-lived transactions. The Vercel case shows the difference between a secret that keeps working and a secret that dies with the session. The latter limits both lateral movement and post-compromise reuse.
Practical implication: Replace long-lived runtime secrets with session-scoped issuance wherever production workflows permit.
Threat narrative
Attacker objective: The attacker wanted durable access to internal systems and reusable production secrets that could be sold, reused, or leveraged for further intrusion.
- Entry occurred through a third-party OAuth consent that granted broad Google Workspace access to a user account.
- Credential reuse and token validity allowed the attacker to bypass password and MFA controls through legitimate delegated access.
- From the workspace foothold, the attacker enumerated internal paths and pivoted into Vercel systems to reach customer environment variables.
- Impact followed as exposed secrets, sample data publication, and attempted resale of stolen records on a criminal forum.
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.
- Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
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
Identity supply chain is now the real attack surface: The industry has treated OAuth consent, SaaS integrations, and runtime secrets as separate control problems for too long. In practice, they form one identity supply chain that attackers can traverse from delegated access to production credentials. The Vercel case demonstrates that the control boundary is not the app, it is the chain of trust connecting humans, third-party tools, and machine-held secrets. Practitioners need to govern the whole chain as one lifecycle.
Static secrets create identity blast radius, not just secret sprawl: A long-lived API key or environment variable is not simply a configuration weakness. It expands the blast radius of every delegated access path that reaches it, because once stolen it can be replayed far beyond the original authorization event. That makes secrets lifecycle management a governance issue, not only a vaulting issue. Teams should measure how long a secret remains useful, not merely whether it is encrypted at rest.
OAuth consent review must be treated like privileged access review: Broad workspace scopes granted to third-party tools are effectively standing delegated privilege. They deserve the same lifecycle controls as admin entitlements, including ownership, review, and revocation when the business need changes. The failure mode here is not just over-permissioning, it is untracked delegated authority that survives long after the user forgets why it was granted.
AI-agent access inherits every weakness in the surrounding identity model: If AI tools are allowed to request, store, or relay credentials, they become another hop in the same trust chain. That means the security problem is not the agent label itself, but the absence of scoped issuance and revocation around the agent's delegated access. The field should stop asking whether the agent is trusted enough and start asking whether the identity model can survive one compromised hop.
Ephemeral credential trust debt is the concept this breach exposes: Organisations accumulate trust debt whenever they rely on credentials that remain valid after the business purpose that created them has moved on. The Vercel incident shows that this debt is paid by attackers, who turn old grants and stale secrets into current access. The implication is blunt: lifecycle control, not storage control, is what determines how far a compromise can travel.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 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: Zero Trust for AI Agents
What this signals
Identity supply chain governance will become a core IAM discipline: The Vercel pattern shows that consent grants, SaaS integrations, and runtime secrets are no longer separable control domains. Security teams should expect review programs to shift toward end-to-end delegated access, not isolated app approvals.
Ephemeral credential trust debt: every static secret that outlives its purpose increases the eventual blast radius of a compromise. When credentials can be issued and destroyed per session, the attacker’s usable window shrinks and incident response becomes more surgical.
According to the 2026 Infrastructure Identity Survey, 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job. That gap matters here because AI-agent access inherits the same delegated-consent risks as any other third-party identity path.
For practitioners
- Audit broad OAuth grants Identify every third-party app with workspace-wide or overly broad consent, then revoke grants that no longer have an active business owner or current use case.
- Inventory static production secrets Find API keys, database credentials, and deployment secrets older than 90 days, then classify them by where they are used and how long they remain valid.
- Separate sensitive runtime variables Move production-granting values into dedicated sensitive handling so they are not managed like ordinary environment configuration.
- Adopt short-lived credential issuance Replace reusable secrets with just-in-time credentials wherever services, databases, SSH, or agents can request access on demand.
- Govern AI-agent identities like any other NHI Require ownership, scope review, and revocation for agents that can retrieve or relay credentials, because they extend the same delegated-access chain as service accounts.
Key takeaways
- The breach shows that third-party consent, static secrets, and production access can combine into one reusable attack path.
- The critical weakness is not code exploitation but durable credentials that remain valid after the original trust decision has aged out.
- Short-lived issuance, lifecycle review, and scoped delegated access reduce how far a compromise can spread.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Old OAuth grants and static secrets outlived the trust decisions that created them. |
| NHI-02 — Secret Leakage | The incident centered on exposed and reusable credentials in workspace and runtime systems. | |
| NHI-07 — Long-Lived Secrets | Static API keys and environment variables remained valid long enough to be monetised. | |
| Recommendation — Revoke stale delegated access and retire secrets when the business purpose ends. Detect leaked OAuth tokens and environment secrets, then remove their reuse paths. Replace long-lived credentials with short-lived issuance for production access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack chain depended on token reuse and pivoting from workspace access into internal systems. |
| Recommendation — Map delegated token abuse to credential access and monitor for downstream pivot activity. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central to preventing reusable secrets from persisting. |
| Recommendation — Apply authenticator management to rotate and retire reused access credentials quickly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Broad OAuth scopes and delegated access permissions were the initial control weakness. |
| Recommendation — Review and constrain entitlements granted to third-party apps and AI tools. | ||
Key terms
- OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
- Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
- Just-in-time Credential Issuance: Just-in-time credential issuance creates access only when a request meets policy and then limits how long the credential remains valid. It reduces standing exposure, but it still depends on strong policy, accurate context, and reliable revocation handling.
- Identity supply chain: An identity supply chain is the network of trusted accounts, roles, tokens, and delegated permissions that connect one system to another. When one link is compromised, attackers can inherit access downstream and use legitimate trust relationships to spread impact across environments.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- The attack timeline linking the Context.ai compromise to Vercel's downstream exposure
- The specific differences between sensitive and non-sensitive environment variables in the affected workflow
- The JIT secret model examples for databases, cloud providers, SSH, and AI agents
- The remediation logic behind rotating static credentials older than 90 days
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.
Published by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org