On this page
Vercel’s November 3 announcement says Security Review is free until November 10, 2026, as part of a public beta for Pro and Enterprise teams. Generating fixes with Vercel Agent remains separately billed. A free review is not a free repair workflow, and an AI-generated fix is not automatically merged into production.
The announcement does not specify a cutoff time or time zone, or explicitly promise all of November 10 in any particular region.
Eligibility and activation
Security Review is part of Vercel Agent, but it is not automatically enabled for every Vercel account. A team Owner turns on Review Deployments Automatically in Agent settings, chooses Projects to Review, and saves the configuration. The selection defaults to all projects; a specific-project selection supports up to 100 projects.
The beta is limited to Pro and Enterprise teams. Turning on reviews and selecting projects is also distinct from allowing Agent chat. Enable Chat must be on before the Vercel Agent repair button appears, and access to that repair flow depends on permission to use Agent chat.
Push events, usually changed code
Reviews start from GitHub pushes, not only pull requests. Direct pushes and force pushes to a production branch are covered too. Projects affected by a single push are reviewed together, so counting open pull requests is not a reliable way to count review activity.
Normally, a review compares source against a base and examines what changed rather than rescanning the whole repository. For deployment reviews, the base is the previous deployment of the same branch, with a fallback to the GitHub API when no previous deployment exists. When there is no base, such as a project’s first review, the service reads the full source. Monorepo reviews are scoped to each project’s root directory.
Reviews normally cover changes since the base. Push frequency and code changes also affect usage under regular billing.
Where findings appear, and who can read them
Findings appear in the Vulnerabilities dashboard, and reviewed commits get a GitHub check. For private or internal repositories, findings can also become comments when the commit’s branch has an open pull request. Anyone with access to that repository can read those comments, potentially a wider audience than the dashboard permits.
The dashboard grants access across projects to Owner, Member, Developer, and Security roles. Contributors see only assigned projects; Billing and Viewer roles do not see findings. Owner and Member roles can edit team or project security policies. These are distinct permissions, not a single all-purpose security-review role.
Findings can contain source snippets and sensitive data. On public repositories, only the check and dashboard link are posted, keeping unpatched vulnerability details in the dashboard. The documentation does not enumerate specific GitHub App permission scopes; whether the integration is read-only or requires additional permissions is not specified.
Separate review pricing from repair pricing
The limited-time review offer comes from the November 3 announcement. The documentation describes the regular charging structure: provider inference at the underlying token rate with no markup, plus a Vercel Token Rate of $0.25 per million tokens. The announcement identifies input, cached, and output tokens.
The $0.25 figure is an additional platform token rate, not the complete price for a million tokens. Provider inference is another component. There is no single fixed per-review price in these materials; push frequency and the amount of changed code influence cost.
Fixes made with Vercel Agent are charged at the Vercel Agent rate even during the free-review period. The waiver covers reviews for eligible teams; Agent-generated fixes remain separately billed.
A repair proposal still needs human approval
For a connected Git repository, Fix with Vercel Agent opens a chat with the finding already described. The documented flow checks whether the vulnerability remains, applies a minimal fix, runs type checks, lint, and tests, then opens a pull request against the affected branch. A person reviews the change and merges it when satisfied; nothing merges on its own.
Without a connected Git repository, the documented alternative is a preview deployment and downloadable patch, not an automatically opened pull request or an immediate source change.
Findings are evidence to assess, not a security certificate
Severity labels are AI-generated estimates, not scores against a fixed rubric. A Closed status means a later review no longer detected the issue; it does not confirm that the issue was fixed. Policies can provide application context, but can also cause reviews to miss vulnerabilities they would otherwise report.
Security Review analyzes source code, not the running application, and does not perform runtime or penetration testing or replace a security audit. Its practical role is an additional source of findings to investigate, with human judgment still needed for severity, repair correctness, and release decisions.