The Vercel breach shows why secrets perimeters must shrink

At a glance

What this is: A post-mortem on the Vercel breach that maps a four-stage attack chain from third-party OAuth compromise to readable production secrets.

Why it matters: It matters because IAM, PAM, and secrets governance now have to treat SaaS identity, workload identity, and secret storage as one exposure surface.

👉 Read Infisical’s analysis of the Vercel breach and secrets security playbook

Context

A secrets perimeter is the set of systems that can read production credentials in cleartext or reversible form. In this case, the breach showed that perimeter is wider than most teams assume because it includes SaaS identity providers, third-party OAuth apps, hosting control planes, and local developer workflows.

The identity governance problem is not just where secrets are stored. It is who and what can reach them, how far access propagates once a control plane is compromised, and whether the same privilege model covers human users, NHI workloads, and agentic tools. The article is useful because it makes that blast radius concrete.

The starting point is atypical in one sense and typical in another. The specific victim and third-party chain are unusual, but the underlying failure pattern is common across modern platform engineering stacks.

Key questions

Q: What breaks when production secrets are readable inside a hosting control plane?

A: The control plane stops being a delivery layer and becomes a secrets oracle. If an attacker can read environment variables or reversible secret values, one compromise can expose multiple credentials at once. That turns a single platform incident into a broad blast-radius event because storage and possession are no longer separated.

Q: Why do connected OAuth apps increase identity risk in secrets-heavy environments?

A: Connected apps extend trust beyond the core IAM boundary, often with broad and persistent permissions. If one of those apps is compromised, the attacker can inherit access into SaaS accounts and then pivot into downstream platforms that trust those identities. The risk is not the app alone, but the delegated path it creates.

Q: How do security teams reduce blast radius for application secrets?

A: They reduce the number of systems that can reveal a secret and shorten the time a credential remains valid. The most effective pattern is runtime delivery backed by machine identity, then dynamic or aggressively rotated credentials for anything that must exist beyond a single session. That way, compromise does not automatically equal reusable access.

Q: Who should be accountable when a third-party identity chain exposes production credentials?

A: Accountability should sit with the teams that own connected-app governance, SaaS identity policy, and secrets lifecycle controls together. A breach that crosses Workspace, a third-party tool, and a hosting platform is not a single-team problem. The right framework is shared ownership across identity, platform, and security operations.

Technical breakdown

Third-party OAuth compromise as the entry point

The initial access path began with a third-party AI tool that had a Google Workspace OAuth app installed by an employee. Once that app was compromised, the attacker moved through delegated SaaS trust rather than directly attacking the target environment. This is a classic identity pivot: the attacker abuses a legitimate authorization relationship to inherit access. The important detail is that OAuth scopes and SaaS integrations often outlive the security assumptions that justified them at install time. In practice, every connected app is part of the enterprise identity surface, whether or not it sits inside the IAM team’s normal review cycle.

Practical implication: review and restrict third-party OAuth grants as part of identity governance, not as an app security side task.

Workspace compromise turned into account takeover

After the OAuth pivot, the attacker took over the employee’s Google Workspace account and then accessed the employee’s Vercel account through that trusted identity. This shows how one delegated identity can become a bridge into another platform when SSO, account linking, or federated trust is too permissive. The important technical issue is not just authentication success. It is the absence of strong step-up controls, session binding, and entitlement segmentation when a sensitive account can be reached through an upstream SaaS identity. Once an attacker controls the human account, downstream platform access can look fully legitimate.

Practical implication: apply stronger conditional access and account-linking controls where SaaS identity can unlock production-adjacent systems.

Readable environment variables created a secrets blast radius

The final stage was lateral movement inside the environment and enumeration of non-sensitive environment variables, including values that decrypt to plaintext on read. That matters because a hosting control plane holding production credentials in readable form creates a reversible secrets store, not a true containment layer. The architectural weakness is simple: if a platform operator or attacker can read the variable, the secret is effectively exposed. This is why secrets storage, delivery, and runtime access have to be separated. The smaller the set of systems that can reveal a credential, the smaller the blast radius when one of them is compromised.

Practical implication: remove readable production secrets from control planes and move to short-lived delivery and vault-backed runtime access.

Threat narrative

Attacker objective: The attacker’s objective was to inherit delegated trust, reach a production-adjacent account, and enumerate secrets that could widen access inside the environment.

1. Entry occurred through compromise of a third-party AI tool that had a Google Workspace OAuth app installed by an employee.
2. Credential access followed when the attacker used the compromised Workspace identity to take over the employee’s account and then access the linked Vercel account.
3. Impact came from lateral movement inside the Vercel environment and enumeration of environment variables that could decrypt to plaintext on read.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

The secrets perimeter is no longer the vault, it is every system that can read a production credential. The Vercel incident shows that a single hosting platform, a SaaS identity provider, and a connected third-party tool can form one continuous exposure path. That means secrets governance has to be measured by readable surface area, not by how many credentials were migrated into a central store. Practitioners should treat every reversible secret location as part of the same control domain.

Delegated SaaS trust is now a primary secrets risk, not a peripheral integration issue. The breach used an OAuth-connected tool to bridge into Workspace and then into the target platform, which means the control failure sits in grant hygiene and account linkage, not just endpoint security. This is exactly where identity programmes still separate employee access, app trust, and platform entitlements when the attack path does not. The implication is that review processes must cover connected-app trust paths as first-class identity dependencies.

Readable environment variables are a blast-radius amplifier, not a storage convenience. Once the control plane can reveal a secret on read, the platform has become an oracle for production access. That breaks the assumption that a hosting provider is only a delivery layer. The right governance question is how many systems can reveal a credential, how quickly a compromise can enumerate them, and whether the path from storage to use is still reversible at all.

Runtime secret delivery must replace static secret visibility if teams want meaningful containment. The article’s playbook points toward a smaller exposure surface built around ephemeral tokens, machine identity, and vault-backed delivery. That aligns with OWASP-NHI and zero trust thinking because the point is not merely rotation, but limiting which identities can ever materialise a secret. Practitioners should assume the old model already failed and redesign around narrow, auditable, time-bound secret access.

Ephemeral credential trust debt: The deeper issue is that many modern stacks still assume a secret can be safely stored where it can later be read back. That assumption fails as soon as the control plane itself becomes a target, because visibility and possession collapse into the same event. The implication is that identity governance has to move from storage controls to access-path controls.

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.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• Read The 52 NHI Breaches Report for case studies that show how compromised identities turn into repeatable intrusion paths.

What this signals

Identity teams should expect SaaS trust chains to become the new secrets perimeter. The practical programme change is to govern connected apps, federated accounts, and runtime credential delivery as one lifecycle, not three disconnected projects. That is where NHI governance, human access policy, and workload identity controls begin to converge.

The secret-sprawl problem is also becoming a lifecycle problem. If a credential can be read from a control plane, copied into a developer workstation, and later resurfaced in a pipeline, then offboarding and access review are only partial controls unless they remove every readable copy.

For teams planning the next phase of hardening, the best signal is not how many secrets were rotated last quarter. It is whether any production credential still exists in a place where a platform operator, connected app, or compromised session can retrieve it intact.

For practitioners

• Audit every readable secret location Inventory all places production secrets can be read back, including hosting control planes, CI/CD stores, developer laptops, and shared docs. Remove any location that can reveal a secret outside the vault path.
• Tighten third-party OAuth governance Review connected apps, their scopes, and their ownership, then remove grants that do not have a current business need or clear lifecycle ownership. Treat OAuth grants as privileged access paths.
• Move workloads to machine identity Use OIDC, cloud-native workload identity, or projected service account tokens so CI and production workloads authenticate without long-lived bearer tokens. Issue access only at runtime and only for the requesting identity.
• Replace readable environment variables with short-lived delivery Use vault-backed injection or dynamic secrets so applications receive credentials at execution time rather than storing reusable values in environment variables. Keep anything that must remain static out of systems that can expose it on read.
• Add anomaly detection for secret enumeration Alert on bulk reads, unusual source IPs, and secret access patterns that do not match workload schedules. Feed the audit stream into the SIEM and correlate with identity events from upstream SaaS providers.

Key takeaways

• The breach shows that delegated SaaS trust and readable control-plane secrets can combine into one contiguous attack path.
• The scale of the problem is broader than one incident because the same exposure pattern exists across hosting platforms, CI/CD, and connected apps.
• The limiting control is not faster rotation alone but shrinking the number of systems that can reveal a production credential.

Key terms

• Secrets perimeter: The secrets perimeter is the full set of systems that can reveal a production credential in readable form. It includes vaults, control planes, CI/CD platforms, developer endpoints, and any integration that can materialise a secret at runtime. Governance should measure how far a credential can travel, not just where it is stored.
• Delegated SaaS trust: Delegated SaaS trust is the practice of allowing one application or identity provider to grant access into another through OAuth, SSO, or linked accounts. It is useful for productivity, but it also creates an inherited trust chain that attackers can abuse when the upstream app or account is compromised.
• Runtime secret delivery: Runtime secret delivery means injecting credentials only when an application or workload starts or requests them, rather than storing them in reusable files or dashboards. This reduces persistence, limits exposure, and supports stronger containment because the credential exists for use, not for browsing.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step hardening sequence for centralising secrets, runtime delivery, and rotation across multiple environments
• Concrete configuration examples for OIDC, cloud auth, and Kubernetes auth that remove long-lived bootstrap tokens
• Implementation detail for dynamic database leases, revocation statements, and audit-log streaming to a SIEM
• Practical migration advice for keeping Vercel as a delivery target while moving secrets into a vault-backed source of record

👉 Infisical’s full post covers the Vercel attack chain, runtime secret delivery, and migration steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 lifecycle governance in your organisation, it is worth exploring.