Vercel secrets exposure shows where platform blind spots break IAM

At a glance

What this is: This is an analysis of the April 2026 Vercel breach and the control gaps that let readable environment variables and weak identity settings widen exposure.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern secrets and access paths across platforms that sit outside traditional cloud visibility, not just inside AWS, Azure, or GCP.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Prowler's analysis of the April 2026 Vercel breach and secrets exposure

Context

Vercel is a useful example of a wider governance problem: modern application platforms can hold credentials, tokens, and deployment access paths outside the visibility of traditional cloud controls. In this breach, the critical issue was not just compromise of a third party, but the difference between secrets that were readable and secrets that were protected from plaintext exposure. That makes the incident relevant to secrets governance, identity enforcement, and NHI risk management alike.

For IAM teams, the important lesson is that platform access is now part of the identity perimeter. If SSO is not enforced, preview environments can reuse production secrets, and environment variables are stored in weak modes, a single account compromise can expose infrastructure-level credentials. The starting position here is unfortunately typical: convenience-first configuration, weak lifecycle discipline, and controls that exist but are not consistently turned on.

Key questions

Q: What breaks when secrets can still be read back in a platform dashboard?

A: The main failure is that secret storage becomes readable access, which means any account compromise or excessive team permission can expose credentials immediately. That defeats the assumptions behind secrets management, because a secret is no longer protected by a separate vault boundary. Teams should treat readable secret modes as a high-risk control gap, not a cosmetic configuration choice.

Q: Why do preview deployments increase credential exposure risk?

A: Preview deployments often run automatically and can inherit secrets that were meant only for production. If those credentials are reused across environments, a malicious pull request, fork, or build-step modification can leak them during execution. The risk rises when fork protection, branch restrictions, and secret scoping are weak at the same time.

Q: What do SaaS teams get wrong about building SSO in-house?

A: They often underestimate the maintenance burden. Building SSO means supporting evolving standards, customer-specific IdPs, signing keys, token formats, and future lifecycle changes. The result is not just engineering effort, but ongoing identity debt that compounds with every enterprise deal.

Q: Who is accountable when a secrets platform compromise exposes downstream credentials?

A: Accountability sits with the teams that own the vault, the identity model, and the secrets lifecycle. NIST CSF and NHI governance practices both imply that the control plane must be treated as a critical trust asset, because its failure can cascade into many other privileged systems.

Technical breakdown

Why plain-text environment variables behave like a weak secrets store

Platforms such as Vercel often use environment variables to hold API keys, database credentials, and deployment tokens. The security difference is not the presence of the variable, but how the value is stored and returned. If a value is stored as plain text, anyone with sufficient account access can read it back in the dashboard or API. If it is stored as sensitive, the platform prevents plaintext retrieval. That makes the storage mode itself a governance control, not just a convenience setting. In practice, this turns platform configuration into part of the secrets management stack, even when the platform is not a traditional vault.

Practical implication: treat environment variable classification as a secrets-control decision, not a developer preference.

How preview deployments create secret exposure paths

Preview deployments expand attack surface because they often run automatically from pull requests and may inherit production-scoped credentials. If production secrets are available in preview, an external contributor or compromised repo can abuse the build path to exfiltrate values during execution. The risk is not the build itself, but the combination of automation, broad secret scope, and insufficient fork or branch protections. This is a classic example of NHI blast radius: the same credential can be reused in multiple runtime contexts that were never meant to share trust boundaries.

Practical implication: isolate preview credentials from production and constrain which deployment contexts can see them.

Why SSO enforcement is the control that closes the account path

SSO enabled is not the same as SSO enforced. Without enforcement, users can still authenticate through local or personal credentials, which bypasses identity provider policies such as MFA and conditional access. In this incident pattern, compromise of an individual account was enough to bridge into the platform. That means account-level identity governance is still decisive even in a cloud-native workflow. For teams, the technical question is not whether a platform supports federation, but whether it actually removes alternate login paths and stale access routes.

Practical implication: verify that federation is mandatory, not optional, and remove fallback authentication paths.

Threat narrative

Attacker objective: The attacker aimed to extract and monetise customer secrets that could be used for follow-on access to cloud, code, and data systems.

1. Entry occurred through a third-party AI tool compromise that led to takeover of a Vercel employee's Google Workspace account. Credential reuse then carried the attacker from the identity layer into the platform.
2. Escalation followed when the attacker pivoted inside Vercel and enumerated customer environment variables, including values stored in plaintext-readable modes.
3. Impact was the exposure and attempted sale of customer secrets that could unlock cloud accounts, databases, and deployment pipelines.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Platform identity is now part of secrets governance. The breach demonstrates that IAM does not end at the cloud boundary. When environment variables, deployment settings, and federation controls sit inside a developer platform, the platform itself becomes part of the identity control plane. Teams that still treat those settings as secondary configuration are missing the real trust boundary. The practitioner conclusion is simple: if a platform can return secrets in plaintext, it is already part of your identity risk model.

Readable secret modes create a standing exposure window. The named concept here is plaintext-return exposure: any configuration state where a secret can be retrieved in human-readable form after initial creation. That state defeats many assumptions behind traditional secrets governance, because compromise does not require vault escape or deep privilege escalation. It only requires access to the platform account or an adjacent identity path. The breach worked because that exposure window existed at all. Practitioners should treat any readable secret mode as a governance failure, not a convenience trade-off.

Preview pipelines need NHI-grade access separation. Preview builds often inherit more trust than they should, especially when production credentials are shared across environments. That is an NHI problem as much as an appsec problem because the same tokens are being reused across automated runtimes, human accounts, and build systems. OWASP NHI guidance and secrets governance both point to the same conclusion: runtime scope must be narrower than deployment scope. The practitioner conclusion is to separate preview and production identities before the next compromise makes that distinction visible.

SSO enforcement matters more than federation checkbox coverage. The breach path shows that enabling federation without enforcing it leaves a usable bypass in place. That creates a false sense of control maturity, especially in SaaS and platform environments where teams assume the identity provider is automatically in charge. It is not. Identity governance only works when alternate login paths, stale tokens, and owner-role sprawl are removed. The practitioner conclusion is to audit actual enforcement, not policy declarations.

This incident is a reminder that cloud-native platforms can become secrets warehouses. As developers move more application logic into hosted frontend and build platforms, secrets move with them. That shifts the governance burden from only cloud account hygiene to platform-specific access review, deployment protection, and credential scope control. The field implication is that modern secrets governance has to include non-traditional platforms, or attackers will keep exploiting the gap between where secrets live and where controls are enforced. The practitioner conclusion is to expand identity governance to every runtime that can surface credentials.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• Forward view: Review the Guide to the Secret Sprawl Challenge to connect readable secret exposure to broader lifecycle and remediation controls.

What this signals

Plaintext-return exposure is the governance problem this breach makes visible. When a platform can return secret material after creation, the control boundary has already moved from storage to account access, which means IAM, access review, and secrets policy all have to be evaluated together. For practitioners, that means reviewing every runtime that can surface credentials, not just the vault that created them.

The programme signal is to extend identity governance into hosted developer platforms and build systems. That includes enforced federation, scoped credentials for previews, and access review for owner roles, invitations, and stale tokens. Teams that already track secret sprawl should align those findings with the 52 NHI Breaches Analysis and the MITRE ATT&CK Enterprise Matrix to keep exposure, credential access, and escalation in the same review cycle.

This is also a reminder that NHI governance cannot stop at the infrastructure account. API keys, deployment tokens, and environment variables are runtime identities, and their scope has to be narrower than the platforms that hold them. If your review process does not ask whether a secret can be read back in plaintext, it is not testing the real failure mode.

For practitioners

• Enforce sensitive-only storage for secrets Classify every environment variable that matches secret patterns such as _KEY, _TOKEN, _PASSWORD, or _PRIVATE_KEY as non-readable by default. Review platform settings so values cannot be returned in plaintext after creation.
• Separate preview and production credentials Use distinct credentials with limited scope for preview builds so a compromised pull request cannot reach production API keys or database tokens. Confirm that preview contexts cannot inherit production environment variables.
• Make federation mandatory at the platform layer Require SSO enforcement rather than optional federation, and remove any local-login or personal-account bypass that can sidestep MFA and conditional access rules. Recheck this after every platform policy change.
• Review platform access as part of secrets governance Include team roles, pending invitations, owner assignments, and stale tokens in access reviews for hosted app platforms. If a user or token can read deployment variables, it belongs in the same review cycle as other privileged access.

Key takeaways

• The breach shows that a single readable secret setting can turn a platform account compromise into a credential exposure event.
• The scale of the problem is wider than one vendor, because secrets, federation, and deployment scope now intersect across developer platforms and identity controls.
• Teams should respond by enforcing non-readable secret storage, separating preview from production, and making SSO mandatory rather than optional.

Key terms

• Plain-Text Secret Exposure: A state where a credential, token, or API key can be retrieved in human-readable form after it has been created. In practice, this means the platform or system itself has become part of the attack surface, because anyone with sufficient access can extract the value without breaking encryption.
• Preview Deployment Secret Leakage: A failure mode where non-production builds inherit credentials that should have remained isolated from production. It matters because automated preview pipelines can execute untrusted code, so any shared secret scope becomes a direct exfiltration path rather than a harmless convenience.
• Federation Enforcement: The difference between allowing single sign-on and requiring it for every login path. Enforcement removes fallback authentication routes, which is critical because optional federation still allows personal accounts, stale tokens, or weaker local credentials to bypass identity policy.
• AI Control-Plane Blast Radius: AI control-plane blast radius is the range of data, actions, and behaviours that can be affected when one AI control fails. It extends beyond records and credentials to include prompts, tool invocation paths, retrieval sources, and backend configuration.

What's in the full article

Prowler's full post covers the operational detail this analysis intentionally leaves for the source:

• The Vercel provider check list that maps platform settings to specific security findings and severities.
• The exact remediation guidance for plain-text environment variables, preview deployment exposure, and SSO enforcement.
• The scan workflow for running Vercel checks in Prowler Cloud or from the CLI, including export formats and configuration options.
• The per-check documentation behind firewall, domain, project, security, and team controls.

👉 The full Prowler post covers the Vercel control mappings, remediation steps, and platform checks in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the operational realities of modern application platforms.