Cursor's changelog entry announcing Rollouts and Security Review states the ceiling plainly: "Rollouts does not merge or roll back on its own today." That's the fact worth reading before anything else, because "it can open revert PRs" sounds like autonomous action if you stop reading one sentence early.
Cursor Rollouts and Security Review are two separate bots that happen to share a launch date. One watches deploys. The other reviews pull requests for security bugs. Mixing them up is easy, since Cursor announced both on the same day and both plug into the same Automations tab.
What Cursor shipped on September 23, 2026
Cursor's changelog entry for the launch puts both bots on Teams and Enterprise plans only, with 10 days of free usage credits after enabling: roughly 50 changes for Teams, about 500 for Enterprise. Neither bot exists on Pro or free tiers.
Rollouts is the deploy-health bot: it monitors what happens after a change ships. Security Review is the PR-scanning bot: it reads every diff before merge and flags security issues. They share a launch date and a billing pool, and that's about where the overlap ends.
What Rollouts actually does
Rollouts writes its monitoring plan before merge, as a comment on the pull request itself: what it'll watch, and in which environment. Once a deploy event fires, it wakes up, checks logs, metrics, and traces for that environment, and returns one of three verdicts: verified healthy, regression detected, or inconclusive.
When it flags a regression, Rollouts has exactly three moves available: ping the PR's author, pause a progressive rollout, or open a revert PR that sits waiting for approval. None of those three merges or reverts anything on its own. A person still clicks approve.
Rollouts connects to GitHub or Cursor's own Origin for source control, a CD system for deploy events, and Datadog and other telemetry providers for the health signals it reads. Feature-flag integration is listed as coming soon, so it isn't live at launch. If a team doesn't already have deploy telemetry wired up, Rollouts has nothing to check.
What Security Review actually does
Cursor's changelog lists a fixed set of bug classes Security Review scans for on every pull request: SQL, command, and template injection; auth and authz bypass; secrets and credentials left in source; SSRF; unvalidated redirects; unsafe deserialization; and vulnerable dependency changes. Cursor's blog post on the launch lists more beyond that set, including LDAP injection and insecure defaults in infrastructure and config, so the changelog's list isn't the full picture. For each finding, Security Review leaves one review comment with a severity rating, the attack path, and a proposed fix.
Teams can extend that with their own context. Cursor's security agents documentation says teams can give the agent custom instructions describing which issue types to prioritize and what a project's own security expectations are; Cursor doesn't publish a worked example of what those instructions look like. Out of the box, Security Review only knows the checklist above. The custom layer is where it starts catching what's actually risky in a specific codebase.
One naming note worth making once: Security Review isn't Bugbot. Bugbot is Cursor's existing, separate product for style and quality; style and quality stay with Bugbot, and Security Review's job is scoped to security only. Teams already running Bugbot end up with a second, narrower bot running alongside it.
What this overlaps with, and what it doesn't replace
Whether an AI bot should gate deploys or security review is a policy question. AI in the engineering workflow: tools, permissions and policy collects HighCircl's coverage of agent permission policies across other tools; Rollouts and Security Review raise the same question for two more products.
Security Review does roughly the same job as any SAST tool already sitting in a pipeline: read the diff, flag the bug classes, leave a comment. What's different is where it lives: built into the product developers already write code in, with a review comment instead of a dashboard alert. How to set up GitHub Copilot code review in 2026 covers the same pattern in broader terms; Security Review is the security-only version, with custom rules standing in for Copilot's wider scope.
Rollouts overlaps with deploy-health and observability tooling more narrowly. It consumes Datadog and other telemetry rather than generating new signals of its own, and it makes decisions on top of data a team already collects. It's a decision layer sitting on top of monitoring a team already has.
What to gate before turning either bot on
Four things worth setting before enabling either bot.
Branch protection with required human approval on every repo path either bot can touch, configured independently of whatever Cursor's own defaults happen to be. Cursor Projects: what changes when an agent decides when work starts sets the same requirement for a different Cursor product: a vendor's default permissions are a starting point; a team's own policy is what actually holds.
For Security Review, write the custom instructions before rollout: what issue types matter most, what the project's own security expectations are. The built-in checklist (injection, auth bypass, secrets, SSRF, deserialization, dependency changes) is generic until a team adds that context, and Cursor doesn't publish a worked example of what good instructions look like.
For Rollouts, decide in advance which regression signals trigger a ping, which trigger a paused rollout, and which trigger a revert PR. Cursor leaves that configurable, and an undocumented default is exactly the kind of thing that drifts once three engineers configure three repos three different ways.
A named incident owner and an audit trail: both bots sit close enough to deploys and merges that "the bot flagged it" can't be where accountability ends. When your CI agent becomes a privilege escalation path: an audit checklist makes the broader case: a bot watching deploy events and a bot reviewing every PR are both CI-adjacent agents with real permission surface, whether or not either one can merge on its own.
What it costs
The free credits run out after 10 days. After that, Cursor's documentation on how the two bots bill usage says usage is "charged to the team's usage pool," with both running as shared team service accounts rather than drawing from individual seats.
Cursor hasn't published a per-scan or per-bot rate anywhere. That gap matters: an engineering lead deciding whether to enable either bot past the trial can't run an actual cost-benefit number against a price that doesn't exist yet. Budget for the 10-day trial, and ask Cursor directly before committing a team beyond it.
FAQ
What are Cursor Rollouts and Security Review?
Two separate bots Cursor shipped on September 23, 2026, for Teams and Enterprise plans only. Rollouts watches deploys and checks whether a change stays healthy after it ships. Security Review scans every pull request for a fixed list of security bug classes and leaves a review comment on what it finds.
Does Cursor's Rollouts bot deploy or revert code without a human approving it?
No. Cursor's own changelog entry says Rollouts does not merge or roll back on its own today. When it detects a regression, it can ping the PR's author, pause a progressive rollout, or open a revert PR, but a person still has to approve any of those before code actually changes.
What does Cursor's Security Review bot check for, and how is it different from Bugbot?
Per Cursor's changelog, it checks for injection (SQL, command, template), auth and authz bypass, secrets left in source, SSRF, unvalidated redirects, unsafe deserialization, and vulnerable dependency changes (Cursor's blog post lists more, including LDAP injection); teams can also give it custom instructions on which issue types to prioritize. Bugbot is a separate, existing Cursor product that covers style and quality; Security Review covers security only.
What does it cost to use Rollouts and Security Review after the free trial?
Cursor gives Teams about 50 changes and Enterprise about 500 changes of free credit for 10 days. After that, usage is billed to a team's shared usage pool rather than individual seats, but Cursor hasn't published a per-scan or per-bot rate.