Mark Vercel secrets as Sensitive before build logs expose them
Vercel now redacts Sensitive Environment Variable values from build logs, but only when the variable is marked Sensitive and the value is 32 characters or longer.
Confirmed: Vercel now masks certain Sensitive Environment Variable values when they appear in deployment build logs. The control is narrow: the variable must be marked Sensitive, the value must be at least 32 characters, and the masking applies to build logs rather than runtime logs or client bundles.
Caption: Official Vercel image for the build-log redaction changelog. Source: Vercel.
What changed
Vercel published the change on July 9, 2026. During deployment builds, if a Sensitive Environment Variable value of 32 characters or longer appears in the build log, Vercel replaces it with [REDACTED].
The Build Logs view indicates that masking happened, and Vercel records an Activity Log event with the environment variable key, project, and deployment. Vercel says the Activity Log event does not include the value.
Two system variables get stronger treatment: VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN are redacted in build logs regardless of value length.
| Item | Covered by the new masking? | What to check |
|---|---|---|
| Sensitive env var, 32+ characters | Yes, in build logs | Confirm the variable type is Sensitive |
| Sensitive env var under 32 characters | No general masking claim | Use long, high-entropy values where possible |
VERCEL_AUTOMATION_BYPASS_SECRET / VERCEL_OIDC_TOKEN | Yes, any length | No manual setup for these system variables |
| Runtime/function logs | Not covered by this changelog | Add application-level redaction |
NEXT_PUBLIC_ client variables | Not covered | Move secrets server-side |
Why this is early
This is not a leak or rumor. The primary source is Vercel's own changelog, and the implementation details are repeated in Vercel's Sensitive Environment Variables documentation.
It is early because many teams will see the headline and assume all Vercel secrets are now protected in logs. That is not what Vercel announced. The practical work is to audit which variables are actually Sensitive-type and which leak paths remain outside build-log masking.
Key takeaways
- Vercel build logs now redact values for Sensitive Environment Variables when the value is 32 characters or longer.
- Sensitive variables are non-readable once created, but existing normal variables do not automatically gain the same protection.
- The feature records redaction events without storing the secret value in the Activity Log.
- Runtime logs,
NEXT_PUBLIC_exposure, committed secrets, and malicious build-time code still need separate controls. - Teams should enforce Sensitive-type variables for Production and Preview secrets, then rotate anything that was previously exposed.
Availability and access
Vercel's documentation says Sensitive Environment Variables can be created for Preview and Production environments at the project or team level. Existing variables must be removed and re-added with the Sensitive option enabled if you want them to use that type.
Owners can also enable an Environment Variable Policy that makes newly created Production and Preview variables Sensitive by default. That policy is the operational lever to check after the changelog: without it, teams still depend on each developer choosing the Sensitive toggle correctly.
Practical LinkLoot angle
Treat this as a secrets-audit trigger, not a reason to relax. Start with Vercel projects that deploy from CI, run verbose build scripts, or share build logs in support and debugging channels.
The fast review is simple: list Production and Preview variables, identify anything credential-like that is not Sensitive, re-create it as Sensitive, rotate old values, and check the first deployment logs after the change. For broader agent and automation workflows, pair this with LinkLoot's AI workflow automation guide so build-time credentials are scoped before agents or CI scripts touch them.
What to verify before you act
- Confirm whether each real secret is marked Sensitive, not merely named like a secret.
- Check value length for short tokens that might not meet the 32-character masking gate.
- Review runtime and function logging separately; this changelog covers build logs.
- Audit every
NEXT_PUBLIC_variable because client-bundled values are public by design. - Enable team policy for new Preview and Production variables if your organization relies on Vercel for secret storage.
Source check
Confirmed by: Vercel's changelog confirms the July 9 build-log masking change, the 32-character gate, the [REDACTED] replacement, the Build Logs indication, Activity Log event metadata, and selected system-variable redaction.
Confirmed by documentation: Vercel's Sensitive Environment Variables docs confirm the same build-log behavior, explain that Sensitive values are non-readable once created, and describe project-level, team-level, and policy-based setup.
Early signal / context: Digital Applied independently analyzed the rollout and its limits. Its security discussion contains adversarial terms, so LinkLoot used it only for corroborating context after checking the core claims against Vercel's own pages.
No. Vercel's stated rule covers Sensitive Environment Variable values of 32 characters or longer, plus selected system variables.