Skip to content
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

The short version

Cursor's Security Review beta (April 30, 2026) puts a prompt-injection scanner inside the editor where it can see the agent tool wiring, not just the diff. That context is the whole pitch, and the reason it is not yet a Snyk replacement.

Table of Contents

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

Cursor's Security Review beta, shipped April 30, 2026 to Teams and Enterprise, is not another SAST tool. The thing that makes it worth turning on is positional. The reviewer runs inside the editor process, so it reads the diff, the prompt that produced the diff, and the MCP tool definitions the agent can call, all in the same pass. A standard scanner sees only the diff. That is why Cursor can flag a prompt-injection vector buried in an agent tool description, and why it cannot yet replace the dependency and CVE coverage you already pay for. Treat it as a second reviewer that understands AI-generated code, not as a security platform.

Two agents ship in the beta, both off by default, both Teams and Enterprise only. Below: what each one actually inspects, where the editor-context advantage is real versus marketing, and a rollout sequence that does not flood your team with beta-grade noise in week one.

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. Scheduled, not per-PR. It sweeps the full repo for known vulnerabilities (CVE matches against your dependency graph), outdated dependencies, and configuration drift. Route findings to Slack and your security team sees them without ever opening Cursor. Frequency is configurable.

Both agents can call MCP servers for existing SAST, SCA, and secrets scanners. If your team already runs Snyk, Semgrep, or GitGuardian, you wire that signal into Cursor's review rather than running a parallel scan. The agents draw from the same usage pool as Composer and Cloud Agents, so there is no separate billable surface. Admins enable each from the dashboard.

Enable Security Reviewer in shadow mode first by giving it a custom instruction that suppresses comment posting while you read the findings list. The instruction block lives in the agent config:

# Cursor admin dashboard > Security > Security Reviewer > Custom Instructions
mode: shadow            # log findings, do not post inline comments
severity_floor: medium  # drop low-severity nits during tuning week
categories:
  - auth_regression
  - prompt_injection
  - agent_tool_approval
output:
  channel: slack
  target: "#sec-cursor-shadow"

To wire an existing scanner in through MCP, register the scanner's MCP server in the workspace and grant Security Reviewer tool access:

# Register an MCP server so Security Reviewer can call it during PR review
cursor mcp add semgrep \
  --command "semgrep-mcp" \
  --scope workspace \
  --grant security-reviewer

Why it matters

The mechanism is the story. A conventional SAST tool taints user input and traces it to a sink. It has no model of "this string is a tool description an agent will read as instructions," because that is not a code path, it is a prompt-construction path. Cursor's reviewer sits where the prompt is assembled. It can see that a Notion MCP server's tool description interpolates page content that an external user controls, and that the agent has shell access. That is a prompt-injection-to-RCE chain a diff-only scanner structurally cannot model, because half the chain is in the prompt template, not the diff.

This matters now because AI-generated code lands in a large and growing share of merges, and it fails differently than hand-written code. Hardcoded credentials, overpermissive auth checks, and tool-wiring that trusts model output all skew higher in AI-assisted PRs. Most mid-market teams (100 to 500 engineers, no dedicated PR-security reviewer) catch none of this until it ships.

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 candid limit: this is beta and Cursor has published no precision or recall numbers for Security Reviewer. Beta security tooling over-reports low-severity findings as a rule, because false negatives are the reputational risk and false positives are not. Budget the first two weeks for tuning, not for clean output. The recommendation below assumes that tuning cost.

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.

The call, and what flips it

Turn Security Reviewer on if you are already on Cursor Teams or Enterprise and you ship AI-generated code through PRs without a dedicated security reviewer. The marginal cost is a tuning week against a class of bug (prompt injection through tool wiring) that nothing else in a typical mid-market stack catches. That is a good trade.

The recommendation inverts in two cases. If your security posture rests on GitHub Advanced Security with custom CodeQL queries and Actions-integrated gating, Cursor's beta does not replace that depth, and running both during beta doubles triage with no published precision to justify it. Wait for GA and the numbers. And if your codebase has little or no agent tool wiring (no MCP servers, no prompt templates, conventional CRUD), the editor-context advantage is mostly inert and a tuned Snyk plus Semgrep covers the same ground with a known false-positive profile. The feature earns its keep in proportion to how much agent code you actually ship.

Cursor ships the agents off by default in the Teams and Enterprise dashboard; Pro accounts do not get them in this release.

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.

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