Guide intermediate

Cursor Security Review (April 30, 2026): PR Vulnerability Scanning Lands in Beta for Teams and Enterprise

Published May 5, 2026 · by Pondero Editorial

Cursor shipped Security Review in beta on April 30, 2026. Two agents inspect pull requests for auth regressions, privacy risks, and prompt injection, plus run scheduled vulnerability scans across the repo. Here is what changes for engineering teams using Cursor.

This article contains affiliate links — disclosure.

Table of Contents
Pondero, operated by Hildebrandt AI LLC, earns a commission from some links on this page. This does not influence our editorial decisions. Read our affiliate disclosure

Cursor Security Review (April 30, 2026): PR Vulnerability Scanning Lands in Beta for Teams and Enterprise

In short. Cursor shipped Security Review in beta on April 30, 2026 to Teams and Enterprise customers. Two agents do the work. Security Reviewer inspects every pull request for auth regressions, privacy risks, prompt injection attacks, and unsafe agent tool approvals. Vulnerability Scanner runs scheduled passes across the codebase for known CVEs, outdated dependencies, and config drift. Both agents share existing seat usage pools and can be wired to MCP servers for SAST, SCA, and secrets scanners.

What Changed

The April 30 release adds two new agents to the Cursor admin dashboard. Both are in beta on Teams and Enterprise plans only, and both are off by default.

Security Reviewer. This agent runs on pull requests. It posts inline comments at specific diff locations covering five categories the changelog calls out: security vulnerabilities, auth regressions, privacy and data-handling risks, agent tool auto-approvals, and prompt injection attacks. The fifth category is the one most teams have been waiting for. Cursor projects increasingly include agent-driven code (LLM calls, MCP tool wiring, prompt templates), and conventional SAST tooling does not flag prompt injection vectors. Security Reviewer treats those as first-class findings.

Vulnerability Scanner. This agent runs on a schedule rather than per-PR. It looks at the full repo for known vulnerabilities (CVE matches against your dependency graph), outdated dependencies, and configuration issues. Findings can be routed to Slack so security teams see them outside the Cursor UI. Frequency is configurable.

Both agents are customizable via trigger adjustments, custom instructions, tooling integration, and output sharing settings. The most important capability for established security teams: both agents can call MCP servers for existing SAST, SCA, and secrets scanners. If your team already runs Snyk, Semgrep, GitGuardian, or a comparable tool, you can wire that signal into Cursor’s review rather than duplicating the scan.

Cost-wise, the agents draw from the same usage pool as Composer and Cloud Agents. There is no separate billable surface. Admins enable each agent from the Cursor dashboard.

Why It Matters

The PR review angle is the headline. Most teams in our ICP (mid-market, 100 to 500 employees, ops-heavy) do not have a dedicated security engineer reviewing every PR. They rely on a mix of GitHub-native checks, the occasional dependency bot, and senior reviewer pattern-matching. The catch is that 2026 PRs include AI-generated code in 60% to 80% of merges, and that code has different failure modes than human-written code. Hardcoded credentials, overpermissive auth checks, and prompt injection vectors in agent tooling all skew higher in AI-assisted PRs.

Security Reviewer is positioned to catch exactly that drift. Because it runs inside Cursor, it sees the full prompt, the diff, and the agent tool wiring at the same time. A traditional SAST tool sees only the diff. That broader context is the reason Cursor’s review can flag prompt injection in MCP tool definitions, not just in user-facing input handling.

Vulnerability Scanner is more conventional in scope but valuable because it runs without infra setup. Plenty of mid-market teams skip Snyk or Dependabot on private repos because the wiring takes a half-day and the noise level is high. Cursor’s scheduled scan inherits the existing repo connection and posts to Slack. The deployment cost is approximately zero if you are already on Cursor Teams or Enterprise.

The MCP integration is the third thing worth flagging. If you already pay for Snyk, Semgrep, GitHub Advanced Security, or a secrets scanner, Cursor’s review can call them via MCP and roll their findings into the same comment thread. That replaces the standard pattern of posting four separate bot comments per PR (one per scanner) with one consolidated review. Reviewer fatigue is a real failure mode in security workflows, and consolidation helps.

The gap to flag: this is beta. Cursor has not published precision/recall numbers for Security Reviewer, and beta-stage tools tend to over-report low-severity findings. Plan to tune the trigger settings and custom instructions in the first two weeks rather than expecting clean output day one.

How to Roll It Out

If you are on Cursor Teams or Enterprise, the agents are available in the admin dashboard under the Security section. The setup sequence we would recommend:

  1. Enable Security Reviewer in shadow mode first. Run it on PRs but suppress comment posting for a week, or post comments to a private branch. Read the findings list with one of your senior engineers and tune the trigger adjustments to drop low-signal categories.
  2. Wire your existing SAST or SCA via MCP before the public rollout. If Snyk or Semgrep is already running, give Security Reviewer access to those scanners. The first-pass findings will look much better when they include known signal from your existing stack.
  3. Set Vulnerability Scanner to weekly, not daily. Daily scans on a 100k-file repo will saturate the dependency-update queue. Weekly is enough cadence for non-zero-day issues, and zero-days should be caught by your Dependabot or vendor-direct alerting anyway.
  4. Route findings to a single Slack channel with explicit owners. The failure mode for any new scanner is that findings land somewhere with no owner and pile up. Assign one engineer the role of triaging Cursor security findings for the first month.
  5. Re-evaluate after 30 days. Beta tools change quickly. If the precision improves, expand to all PRs. If it does not, scope back to high-risk paths (auth code, payment flows, agent tool definitions).

Pricing is included in the Teams and Enterprise tiers. Beta access does not require a separate quota or addon. Individual Pro accounts do not get the agents in this release.

If you want to compare how this stacks up against GitHub’s own security tooling, GitHub Advanced Security on private repos remains the most direct competitor. The trade-off is the AI-aware reviewing context Cursor brings against the deeper repo and Actions integration GitHub provides.

For Cursor’s broader admin story, see our coverage of Cursor’s enterprise admin controls from May 4, which adds the model allow-lists and soft spend caps that pair well with the security agents. The Cursor 3.2 multitask canvases write-up covers the agent runtime that Security Reviewer is built on.

If you are still picking between coding agents, our Cursor vs Copilot guide is the right starting point. Copilot’s own enterprise coverage continues in our GitHub Copilot Individual plan changes post.

Try Cursor on Teams or Enterprise to access the Security Review beta. The agents are off by default in the dashboard.

This post is part of Pondero’s daily coverage of AI tool updates. See all coding guides.