Cursor Security Review is a bot that reviews each pull request in the context of your code and posts a single comment with the exploitable security bugs it finds, each with its severity, attack path, and a proposed fix. Cursor launched it on September 23, 2026 alongside Rollouts, a second bot that monitors each change after deployment. Both are available now in Teams and Enterprise plans.
Cursor presents them as bots for the “last mile” of code delivery. Most AI coding tools compete on writing code; these two work on what comes next: whether it’s safe to merge and whether the change behaved well once it reached production.
What vulnerabilities does Cursor Security Review detect?
Security Review looks for bugs that an attacker could exploit, not style issues. According to the launch announcement, it covers:
- SQL, command, and template injection.
- Authentication and authorization bypass, including checks that a refactor stopped running without anyone noticing.
- Secrets and credentials uploaded to the repository.
- SSRF and unvalidated redirects.
- Unsafe deserialization.
- Dependency changes that introduce known vulnerabilities.
It traces where user input enters and where it flows, and that’s what sets it apart from a pattern-based linter. Each finding includes severity, attack path, and proposed fix. If you dismiss a finding by stating your reason, it won’t appear again in that same PR. Draft PRs are skipped.
You can also add team-specific rules, for example which clients external calls must pass through or which tables are never queried from a request handler. Security Review applies them to every PR.
How do you activate Security Review in Cursor?
It’s activated from the Security Agents page in Cursor’s Automations panel, choosing the repositories you want to review. The documentation describes it as one of two types of agent managed by Cursor. Setup covers:
- Triggers: Automations triggers based on Git, including pull request and merge request events.
- Security checks: a set of built-in checks you can enable or disable one by one.
- Custom instructions: what to prioritize and your project’s specific security expectations.
- Tools and MCPs: a Security Reviewer can’t be saved until it has at least one tool or MCP connected, for example one that sends findings to a Slack channel or your issue manager.
Security Agents run on Cursor’s Cloud Agents and don’t require additional environment setup if you use Cursor’s cloud.
Can you review security before pushing?
Yes. The /review-security skill (or the more general /review) runs the same Security Agent from your own agent session, before the code leaves your machine. By default it reviews all changes relative to the base branch, both committed and uncommitted. You can ask it to look only at uncommitted changes, or point it to a different base branch if yours isn’t the default.
Skills are available in Cursor 3.7 or higher, at cursor.com/agents, and in the Cursor CLI. It’s the fastest of the three cycles: you see the findings before any reviewer does.
How do you run a vulnerability scan on code already in the repository?
That’s what the second type of agent is for, the Vulnerability Scanner. Instead of reacting to each PR, it scans code at rest on a cron-like schedule, finding old issues and what PR review missed. Its findings appear in a list called Flagged Vulnerabilities:
- Findings are grouped by repository.
- You can filter them by severity (Critical, High, Medium), status, and feedback (Useful, False Positive, Unimportant).
- Each finding has a Fix in Cursor button that launches a cloud agent to fix it.
Together that’s three layers: the skill before push, the reviewer on the PR, and the scanner on what’s already merged.
The panel also shows vulnerabilities found, issues fixed, and a resolution rate. The documentation clarifies that an LLM decides whether something was “fixed” by reviewing subsequent diffs, so it’s worth reading that metric as an estimate.
Is Security Review a SAST tool?
It serves a similar function, although Cursor doesn’t use that term: at the time of publishing this note, its documentation doesn’t describe it as SAST. A classic SAST (Static Application Security Testing) analyzes source code without running it, typically with predefined rules and patterns. Security Review also reads code without running it, but with other differences:
- It reads it in the context of the PR and the rest of the codebase.
- It traces the path of user input.
- It proposes a concrete fix.
- It accepts team rules written in natural language.
If you already have a SAST in your pipeline, it makes sense to treat Security Review as an additional layer and compare its findings with your current tool’s for a while, rather than replace it outright.
Security Review or Bugbot?
They divide the work. Security Review reports exploitable bugs; code style and quality remain Bugbot’s responsibility, Cursor’s general code review bot. If you already use Bugbot, Security Review works alongside it, not in its place. We covered Bugbot’s transition to Cursor’s own model in this earlier note.
To see how other tools solve the same problem, check out our guide to Copilot Code Review and the one on code review with Claude Code and other agents.
What does Cursor Rollouts do after deployment?
Rollouts checks whether a change actually did what it should once deployed, and it does this for each environment separately. Cursor describes it as its own version of Firetiger’s Change Monitors, rebuilt with its Bot Development Kit.
- When the PR opens, Rollouts reads the diff and writes a rollout plan. The plan includes the risks it detects, the effect the change should have, the signals it will review, and the instrumentation gaps that would make it hard to verify.
- On GitHub, GitLab.com, and Bitbucket Cloud, the plan is published as a comment on the PR.
- To change it, mention the bot’s handle in a PR comment and tell it what to watch or ignore. Only those with write permissions in the repository can do this.
- When the commit is deployed, Rollouts executes the plan against your logs, metrics, and traces. It reviews at the moment of deployment and again at 20 minutes, 1 hour, 1 day, and 3 days. Since each environment is tracked separately, a change can be verified in staging and flagged in production.
- When it detects a regression, it names the suspicious change, opens an issue, and alerts the author. From the issue you can press Fix to launch a cloud agent, or close it with a reason.
Rollouts never merges, reverts, or rolls back on its own. The announcement mentions an optional reversion PR, but at the time this note was published, the documentation only describes the issue flow with the Fix button.
How do you enable Rollouts?
You enable it from the Rollouts card in Automations, in four steps:
- Repositories: you choose which ones to watch, up to 200, on Origin, GitHub, GitLab.com, or Bitbucket Cloud.
- Deployment events: your pipeline notifies when each production deployment starts and ends, using a Cursor API key saved in your CI secrets. You can add those calls yourself or let a setup agent open a PR that adds them.
- Telemetry: connect at least one observability tool, like Datadog. Without it, changes stay pending and Rollouts can’t detect anything.
- Notifications: for example, direct messages or a Slack channel. Slack notifications are not available in Privacy Mode.
By default, Rollouts skips changes that only touch documentation, formatting, lint, typos, or tests. You can rewrite that rule in natural language. Integration with feature flags is announced as “coming soon”.
Is Cursor Security Review free?
No: both bots require a Teams or Enterprise plan, and Security Agents are charged against the team’s usage pool, not against each person’s pool. For teams to test Rollouts with real changes, Cursor includes usage credits for 10 days from the September 23 launch: about 50 changes for Teams and 500 for Enterprise. At the time this note was published, that promotion is still active until approximately October 3.
What is Cursor?
Cursor is an AI code editor and programming agent developed by Anysphere. It’s built around agents that plan, write, and review code in your repositories: locally, in the cloud, and from the CLI. Security Review and Rollouts extend it beyond the editor, to the PR and deployment pipeline. If you’re new to Cursor, start with our introduction.
Why does it matter?
Agents already write a significant portion of the code that reaches review, so the bottleneck has moved to verifying it. Cursor’s bet, visible from Automations, is that the same agents review the result: before the push, in the PR, and after deployment. The approach keeps a person in the loop. Nothing is merged or reverted without someone deciding.