Cursor Adds Rollouts and Security Reviewer for Teams and Enterprise

What happened

Cursor, the AI coding tool, launched two automated bots that work after your code is written, not during it. Cursor’s announcement describes Rollouts, which watches a change from the moment its pull request opens to the moment it’s live in production, and Security Reviewer, which scans pull requests for security bugs and proposes fixes.

The September 23 launch announced both bots for Teams and Enterprise plans. Cursor Pro was not included in that launch availability.

Why it matters

Rollouts needs three things connected before it can do anything: your source control (like GitHub), your deploy system, and a telemetry platform, meaning a tool that already tracks your app’s metrics and error traces, such as Datadog, Grafana, or Honeycomb. If you don’t already have one of those wired up, Rollouts has nothing to compare against.

For teams that do have that in place, here’s the workflow. Before a pull request merges, Rollouts reads the code change and writes a monitoring plan: what could go wrong, what the change is supposed to do, and which parts of your telemetry can’t actually confirm whether it worked. You can edit that plan before merging.

After the change deploys, Rollouts compares your live metrics against how things looked right before the deploy, which Cursor calls the baseline. If it spots a problem, what happens next depends on how you configured it: it pings whoever wrote the code, pauses a progressive rollout (sending the new version to a small slice of users before everyone gets it), or opens a pull request that reverts the change and waits for a human to approve it. Cursor is explicit that a revert always waits for your approval. It does not merge that on its own.

Cursor says Rollouts is designed to catch a regression, something that used to work and broke because of a change, when it affects one part of your app in one region before a company-wide alert fires. Cursor also says it distinguishes deliberate behavior changes from bugs and flags monitoring gaps before merge. That last feature addresses a common failure: a change ships, nothing alerts, and weeks later someone discovers it broke something nobody was watching for.

Security Reviewer works differently. It reads every pull request looking for specific categories of bugs: ways user input could reach your database or system commands unsafely (the kind of bug that lets an attacker inject their own commands), broken login or permission checks, secrets like API keys accidentally left in code, and dependencies, meaning the outside code libraries your app relies on, that have known security holes. For each one it finds, it explains the severity, how an attacker could actually exploit it, and offers what Cursor calls a one-click fix.

Here, “one-click fix” means Cursor proposes code for you to review and apply. Treat every fix as a suggested change to read before you accept it, the same way you’d read a fix a junior engineer proposed. Security-sensitive code is exactly the code where a plausible-looking but subtly wrong fix causes more damage than the bug it replaced.

Who should care

Teams already running Cursor on a paid Teams or Enterprise seat, with a deploy pipeline and a metrics tool already in place. If that’s not your setup, this is still worth knowing about: it’s a signal that coding agents are expanding past writing code and into watching what that code does after it ships.

What builders should do next

If you have access to these bots, enable them from the automations tab in your Cursor dashboard, one bot at a time. Confirm repository access and permissions for Security Reviewer, then read its first few findings and proposed fixes before accepting any. Check whether the attack path applies to your app and whether the fix preserves intended behavior.

For Rollouts, don’t accept the auto-generated monitoring plan as-is on your first pull request. Check it against a change you already understand well, and confirm it correctly flags any part of your app that your telemetry doesn’t actually cover. If it misses a known gap, adjust the plan and instrumentation before depending on it for changes you understand less well.

Post-merge monitoring still needs human review

These bots extend agent work into security review and deployment monitoring. The guardrail that matters most here is real: reverts wait for a human. Read the monitoring plan and proposed revert or security fix before approving it. An approval requirement gives a reviewer a checkpoint; it does not establish that the proposed action is correct.

End of article