Vercel launches Security Dashboard to audit production project configurations

Vercel announced on August 26, 2026, via its official changelog, the general availability (GA) of the Security Dashboard, a security posture audit tool that is now available on all plans, including the free tier. The idea is to bring together in one place the security state of each account and project hosted on the platform, something that used to be scattered across several configuration screens or simply wasn't monitored at all.

The framing of the problem is honest and recognizable for anyone working with Next.js and front-end at scale: as teams grow and code agents speed up project creation, small misconfigurations pile up unnoticed. A preview deployment that ended up public, an environment variable that should have been marked sensitive and wasn't, a team member without 2FA. None of these items brings the application down, but all of them silently widen the attack surface.

What the tool flags

The Security Dashboard scans the account for misconfigurations and ranks them by risk, from most severe to least. Among the findings it detects automatically are:

• Team members without 2FA enabled;
• Long-lived credentials that could be replaced with OIDC (identity federation, which generates short-lived tokens instead of static secrets);
• Public preview deployments, meaning preview environments accessible to anyone with the URL;
• Environment variables not marked as sensitive and stale variables.

Each finding in the interface links directly to the configuration screen that resolves the issue, which reduces the friction between discovering and fixing. Findings that are just noise for the team can be muted, and the entire result can be exported to CSV for triage or reporting. This CSV detail is what brings the tool closer to compliance workflows: you can attach the evidence to an audit process or bring it into an incident response conversation without needing to take screenshots.

The angle that matters: the CLI and the agents

The most interesting part of the announcement, from an automation standpoint, is the new CLI command. Running vercel security check in the terminal executes exactly the same checks as the interface and prints the full list of misconfigurations right there.

What changes the game is the design built for code agents. With vercel security check --findings, an agent can read what failed, apply the fix, and run it again to confirm. Vercel lists fixes an agent is already capable of applying on its own:

• Turning on Git fork protection;
• Marking an environment variable as sensitive;
• Replacing a static credential with OIDC federation.

For more surgical changes, you can restrict the check to a specific project with --project, generating a leaner set of changes. And the detail that makes a difference in pipelines: in CI or any non-interactive context, the command writes the report as JSON to stdout automatically, with no need for an extra flag. This means the output already comes structured to be consumed by another process, whether an agent or a GitHub Actions step that breaks the build if there's a critical finding.

In practice, the minimal flow to get started is running the first scan through the dashboard interface or triggering the command locally:

vercel security check
# structured output for automation
vercel security check --findings
# limiting to a single project
vercel security check --project meu-app

Why this matters for Brazilian developers

The scenario described by Vercel itself, projects being born too fast because of agents, is exactly what many teams here experience today. The promise of "security shift-left" usually runs into the lack of a tool that already sits where deployment happens. Having the check built into the hosting platform, without installing a third-party scanner or maintaining a separate integration, considerably lowers the barrier to including security in the workflow.

There are two clear uses. The first is compliance: the CSV export and severity ranking provide the raw material for reports required in audits, something relevant for anyone handling sensitive data or needing to demonstrate controls to clients. The second is incident response: when something goes wrong in production, having a quick inventory of open misconfigurations helps reduce the time to identify what was exposed.

The integration with agents also aligns with the direction Vercel itself has been taking, with the Agent Stack and Vercel Agent. The idea of an agent reading the findings in JSON, applying the fix, and revalidating is the kind of automation that, if it works well, saves the tedious work of hunting toggle by toggle through the settings.

Trade-offs and what remains open

Some caveats are worth noting before treating this as a silver bullet. The tool is Vercel-specific: it audits the posture of the account and projects on the platform, not the application code. It's not a SAST, it doesn't replace dependency analysis, and it doesn't look at vulnerabilities in your bundle or libraries. It covers the platform configuration layer, which matters but is only one slice of a real application's security.

For anyone not hosting on Vercel, there's obviously nothing here, and lock-in is the implicit cost: the more a team leans its security process on this dashboard, the more tied it becomes to the platform. It's also worth taking a critical look at delegating fixes to agents: vercel security check --findings applying fixes automatically is convenient, but replacing a static credential with OIDC or turning on fork protection are changes that can affect deploys in progress. In critical environments, it makes sense to review the agent's changeset before merging, rather than letting the automatic fix run without supervision.

The full documentation and the step-by-step for the first scan are on the Security Dashboard docs page referenced in the announcement. Vercel's material doesn't yet detail how often the checks run automatically or whether there are proactive alerts when a new misconfiguration appears between scans, something that would make a difference for continuous monitoring rather than on-demand checking.