Vercel Security Review: Push Scanning, Pricing and Permissions

Vercel Security Review brings automatic vulnerability review to GitHub pushes for Pro and Enterprise teams. The public beta can surface findings and help prepare fixes. For a team shipping AI-generated code, the practical change is another opportunity to catch an authorization error before it becomes an incident.

Vercel announced the feature on November 2. The following setup and scope details come from its official documentation. The rollout checklist is my practical interpretation for teams evaluating it. Official announcement

What triggers a security review?

Once enabled, the service reviews pushes to connected GitHub repositories, including direct production-branch pushes. It normally compares changed code with a base. The documentation identifies an important exception for first reviews without a base, which read the full source. Monorepo scope follows the project’s root directory. Review scope

That makes repository structure an operational concern. Before enabling it across a monorepo, map which project owns each sensitive route. Shared authentication code and changes outside a project’s root deserve particular attention during a pilot. Confirm the observed coverage using a harmless test change and the resulting review record.

A completed deployment and a completed security review answer different questions. Keep a visible owner for findings that arrive while a release is progressing.

How do you enable it?

In Vercel Agent settings, enable Review Deployments Automatically, select all projects or specific projects, and save. The documentation allows up to 100 specific projects. Agent-assisted fixes also require Enable Chat. Setup instructions

Start with a project whose repository permissions and escalation path are understood. Record who reviews a finding, who can authorize a fix, and how that fix reaches production. A useful pilot follows a finding through investigation, a reviewed patch, tests, deployment and verification of the affected behavior.

For example, an invoice endpoint should be tested with two isolated test organizations. A repair should preserve legitimate access while preventing one organization from reading another’s records. Keep those tests free of real customer information.

Who can see the findings?

Findings can include source snippets containing sensitive information. Dashboard visibility depends on Vercel roles. Private and internal repository pull-request comments can expose findings to everyone with repository access. Public repositories receive a check linking to the dashboard while detailed findings remain there. Visibility and privacy

Review that audience before connecting a client repository. A developer with access to a private repository may have a different role from someone assigned to the Vercel project. Decide where security evidence belongs, how to redact copied examples and who owns triage.

The CLI command below provides another route to findings. Its availability alone does not establish that the current account has reviewed or resolved anything.

vercel security vulnerabilities

What does it cost?

Vercel’s launch announcement says reviews are free until November 10, 2026. Agent-made fixes remain billable. The documented paid rate combines provider inference costs with no markup and an additional $0.25 per million tokens. Launch offer, Agent pricing

Treat the offer as a dated evaluation window. Estimate spending from actual push frequency and review work, then check the team’s usage after representative changes. A small patch and a broad refactor can consume different amounts of model context. Include paid remediation in the evaluation budget.

Before expanding a pilot, capture the applicable rates and settings in the team’s own release notes. Recheck current pricing when the free review window ends.

What should a team verify before adopting it?

My recommendation is to evaluate the whole response to a finding. Confirm the repository, commit and environment involved. Reproduce the issue safely, inspect the proposed patch, and run checks through the application’s normal user paths. Assign a person to decide whether the result is ready to release.

Source analysis has limits. Vercel explicitly excludes runtime and penetration testing from this feature. An empty findings list should be considered alongside application tests, dependency checks, permission reviews and the system’s actual behavior. Documented limitations

For a team building a customer portal or SaaS product, the first useful outcome is a repeatable path from a finding to a verified repair. My website development work and the TransitFriends project provide related production-delivery context. Adoption should be measured by the issues a team can investigate and resolve with evidence.