TL;DR: A Vercel compromise exposed customer environment variables that were stored as plain text, while sensitive variables remained unreadable, showing how one configuration choice can determine blast radius, according to Prowler. The incident proves platform access, preview deployment scope, and SSO enforcement now matter as much as cloud-native secret rotation.
At a glance
What this is: This is Prowler’s analysis of the Vercel breach, where readable environment variables created the exposed set and sensitive variables remained protected.
Why it matters: It matters because IAM, SSO enforcement, and secret classification now shape the blast radius of platform compromises as much as perimeter security does.
Context
Environment variables have become a practical secret store for modern development platforms, but that convenience creates a governance gap when teams rely on defaults instead of classification, scope, and enforcement. In this case, the security question was not whether a platform could be compromised, but which stored values would still be readable if it was.
The identity angle is direct. If platform access is not tied to enforced SSO, if preview deployments can see production secrets, and if NHI-style credentials such as API keys and tokens are stored without lifecycle discipline, a compromise of one account can expose many downstream systems. That is a governance failure, not just a platform issue.
Key questions
Q: What breaks when environment variables are stored as readable secrets on a platform?
A: Readable secrets turn a platform account compromise into infrastructure exposure. If API keys, tokens, or database credentials can be returned in plaintext, the attacker does not need to break the downstream system first. The control failure is classification and scope, because the platform is acting as a secrets store without the protections expected of one.
Q: Why does enforced SSO matter when developers use SaaS deployment platforms?
A: Because enabled SSO without enforcement still leaves a direct login path outside the identity provider. That weakens MFA policy, conditional access, and offboarding control. When the platform accepts both federated and direct authentication, the organisation has a second trust path that attackers can exploit after one account is compromised.
Q: How should teams separate preview and production access in web app platforms?
A: Treat preview builds as lower-trust execution environments and never let them inherit production credentials by default. Use separate secrets, scoped tokens, and deployment rules that prevent forked or externally influenced builds from accessing production data. The aim is to prevent a preview path from becoming a production exfiltration route.
Q: When should organisations rotate secrets after a platform breach?
A: Rotate immediately when there is credible exposure of readable environment variables, direct dashboard access, or any path that could have revealed reusable credentials. Waiting for proof of misuse extends the compromise window. The right decision is to assume any readable secret can be copied and used elsewhere before the platform incident is fully contained.
Technical breakdown
Plain, encrypted, and sensitive environment variables
Vercel’s environment variable model creates three different exposure outcomes. A plain variable can be read back in the dashboard and API responses, while a sensitive variable is designed never to return in plaintext after creation. That distinction matters because many teams treat environment variables as a generic secret store without classifying which values should be reversible. In practice, the platform’s permission model and the variable type together define whether an attacker can recover usable secrets after account compromise. This is a classic example of configuration determining confidentiality more than cryptography alone.
Practical implication: Treat secret type selection as an access control decision, not a convenience setting.
Preview deployments and secret scope
Automatic preview builds expand the attack surface because they can execute with the wrong credential scope if production variables are shared into non-production environments. In a multi-branch workflow, a preview deployment is still an execution path, so any secret available there can be copied, printed, or exfiltrated during build time. That is especially risky where external contributors can influence build behaviour. The failure mode is not the preview feature itself, but the absence of environment separation between trusted production credentials and lower-trust build contexts.
Practical implication: Segregate preview and production secrets so a build path cannot inherit more privilege than it needs.
Enforced SSO and team access sprawl
Enabled SSO is not the same as enforced SSO. If members can still authenticate with personal credentials, the organisation has two identity planes and the weaker one becomes the attack path. The article also points to common lifecycle weaknesses, including excessive Owner roles, stale invitations, and missing directory sync. Those conditions create a residual access problem: even when identity policy exists on paper, accounts and privileges persist outside the intended governance boundary. That is where platform access stops being an IAM control and starts becoming an exposed asset.
Practical implication: Close every alternate login path and remove stale team access as a standing control, not a periodic cleanup.
Threat narrative
Attacker objective: The attacker’s objective was to harvest reusable secrets that could unlock customer infrastructure, source code, and related cloud services.
- Entry began with a third-party AI tool compromise that let the attacker pivot into a Vercel employee’s Google Workspace account.
- Credential access followed when the attacker used that account to log into Vercel and reach customer environment variables.
- Impact occurred when readable variables were enumerated and exfiltrated, creating exposure for API keys, database credentials, and other downstream secrets.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
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
Platform secrets management is now an IAM problem, not just a DevOps problem. When a platform stores credentials as readable environment variables, the security outcome depends on identity enforcement, privilege scope, and how those secrets are classified. That means IAM teams cannot treat developer platforms as outside their remit. The practical conclusion is that platform access reviews must include secret exposure paths, not only user logins.
Blast-radius control is the real control objective in platform compromise scenarios. Once a platform account is breached, the question becomes which stored values remain unreadable and which can still be recovered in plaintext. The article shows that sensitive typing reduced exposure while plain typing expanded it. Practitioners should treat secret type, deployment scope, and team access as one governance layer, not three separate concerns.
Implicit trust in preview environments creates a hidden privilege inheritance model. Preview builds often inherit production assumptions that were never meant to travel into lower-trust contexts. That is where non-human credentials become particularly fragile, because API keys and tokens can be reused far beyond their intended scope. The control failure is not merely excessive exposure, but the absence of environment-bound authorization boundaries.
Identity enforcement must match operational reality or it becomes advisory only. A platform can advertise SSO while still allowing direct sign-in paths, pending invitations, and stale memberships to persist. In that state, the organisation has policy without enforcement. The practitioner takeaway is that access governance for SaaS development platforms should be measured by the accounts that can actually authenticate, not by the presence of a configured IdP link.
What this signals
Readable secret exposure is now a governance boundary problem. Platform teams often assume that a secret stored inside a managed service is automatically protected, but this breach shows that the stronger control is whether the value can ever be returned in plaintext. Security programmes should map every developer platform to the same secret handling standards used for core cloud accounts.
Secret type is becoming a blast-radius control. The article’s core lesson is that the difference between plaintext-returning variables and non-returnable variables determines how much damage follows an account compromise. That makes secret classification a policy decision, not a developer preference, and it should be reviewed alongside access scope and offboarding.
Environment-bound privilege needs the same attention as human IAM. When preview deployments can reach production credentials, the platform is effectively extending privilege across trust zones. Teams should watch for any workflow where a non-production execution path can read, copy, or leak production material.
For practitioners
- Audit environment variable classification Identify every variable that looks like a secret and verify it is stored in the most restrictive type available, especially keys, tokens, passwords, and private keys.
- Separate preview and production credentials Remove production secrets from preview deployment scopes and use limited-scope credentials for branch builds and forked pull requests.
- Enforce SSO across the team Require SSO for all members, remove alternate authentication paths, and review Owner assignments, stale invitations, and directory sync gaps.
- Rotate reusable credentials after platform exposure Treat any readable environment variable as compromised if platform access is in doubt, then rotate API keys, database credentials, and deployment tokens in connected systems.
Key takeaways
- Readable environment variables can turn a platform compromise into a broad secrets exposure event if they are not classified and scoped correctly.
- The breach shows that one setting can decide whether stolen data is plaintext-recoverable or effectively unusable to an attacker.
- Teams should prioritize enforced SSO, secret-type governance, and environment separation as the controls that most directly shrink 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 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-02 — Secret Leakage | The article centers on readable environment variables exposing secrets through a platform compromise. |
| NHI-04 — Insecure Authentication | The attack path relied on identity compromise and weak enforcement of federated access. | |
| NHI-07 — Long-Lived Secrets | Reusable environment variables and tokens widen the blast radius after exposure. | |
| Recommendation — Scan platform-managed secrets for plaintext exposure and revoke anything that can be read back. Enforce federated authentication and remove alternate login paths that bypass the IdP. Inventory long-lived secrets and replace them with scoped, rotated credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and lifecycle control are central to limiting reuse after exposure. |
| AC-2 — Account Management | Team sprawl, stale invitations, and lingering access are part of the failure pattern. | |
| Recommendation — Apply authenticator management to rotate exposed secrets and retire stale tokens promptly. Review account lifecycle controls so pending and dormant access cannot persist unnoticed. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident shows why entitlement scope and environment access boundaries determine blast radius. |
| Recommendation — Align platform permissions and deployment entitlements to the minimum access needed for each environment. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack combined account compromise with movement into platform-held credentials. |
| Recommendation — Map the compromise path to credential access and lateral movement so detections cover both stages. | ||
Key terms
- Plain Environment Variable: An environment variable stored so its value can be read back in cleartext by authorised users or API calls. In platform security, this is effectively a reversible secret store and should never hold credentials that would be harmful if exposed.
- Sensitive Environment Variable: A sensitive environment variable is a configuration value stored with extra protection because it contains a secret such as an API key, token, database credential, or signing key. The control is important because exposure often comes from read access, not from the value existing in the environment.
- Preview Deployment: A temporary build or runtime environment created from a branch or pull request before production release. It improves developer speed, but it can also become a secret-exposure path if production credentials or higher-trust access are available inside that lower-trust context.
- SSO Enforcement: A control state where all users must authenticate through the organisation’s identity provider instead of alternate local or personal login paths. It matters because enabled SSO without enforcement still leaves bypass routes that weaken MFA, conditional access, and offboarding.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is a fit for practitioners who need to connect identity controls to real-world platform and access risk.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org