A pull request can pass review and still fail after deployment. Cursor’s new Rollouts bot connects the code change to what happens in each environment, while Security Review looks for exploitable bugs before the merge. Neither feature removes the need for a human decision at the release boundary.
Two bots for different moments in the release cycle
Cursor introduced Rollouts and Security Review on September 23, 2026. Both are available on Teams and Enterprise plans. Security Review examines non-draft pull requests in codebase context and comments on findings it judges exploitable. Rollouts starts from the pull request, creates a monitoring plan, then checks the deployed change against signals from each environment.
This is different from asking a coding agent to fix a failing test. Security Review makes a claim about an attack path before deployment. Rollouts makes a claim about the health of a specific change after it reaches staging or production. Those claims are useful prompts for investigation, not independent proof that a codebase is secure or a release is healthy.
How Rollouts follows a change
When a pull request opens, Rollouts reads the diff and affected systems and posts a plan with expected effects, possible risks, and the logs, metrics, or traces it will inspect. The team can edit that plan. After a deployment event for the commit, the bot evaluates each environment separately and reports a state such as healthy, regression detected, or inconclusive. A staging result does not replace a production result.
The critical detail is how it responds to a regression. Depending on configuration, Rollouts may notify the author, open a revert pull request, or hand a finding to a cloud agent for a proposed fix. Cursor says it does not merge or roll back on its own today. Keep human approval, change management, and the incident process explicit. An automatically drafted revert is still a change that can introduce its own failure.
To test Rollouts, connect a noncritical repository, deployment system, and telemetry provider. Choose a change with a visible intended effect, then check whether the plan names the right signal and the right environment. Test an intentionally inconclusive case too—for example, missing instrumentation—so the bot does not turn absence of evidence into a green badge. Cursor lists GitHub or Origin source control, deployment integrations, and Datadog and other telemetry providers; it still describes feature-flag integration as forthcoming.
What Security Review adds to PR checks
Security Review focuses on security issues rather than style and quality, which remain Bugbot’s remit. Cursor says it looks for paths such as injection, authorization bypasses, committed secrets, SSRF, unsafe deserialization, and dependency vulnerabilities. A finding includes a severity, an attack path, and a proposed fix. Teams can add codebase-specific rules and dismiss findings with a reason on the pull request.
That scope sounds broad, but the launch note does not publish an independent detection rate or false-positive rate. Compare a sample of findings with a human security review. Confirm that the alleged source, path, and sink are reachable in your deployment, and test the proposed fix. A silent bot result is not evidence that you’ve excluded every vulnerability class.
A release checklist that keeps the boundary clear
Before a pilot, decide who may edit monitoring plans, who receives regression alerts, who approves revert pull requests, and where security findings are triaged. Measure the useful signals: true regressions found, time to confirm, false alarms, missed incidents, and time spent reviewing security comments. If a bot cannot see the production telemetry or a draft PR is skipped, record that gap rather than counting it as coverage.
Cursor’s earlier Projects release concerns longer-lived agent coordination. Rollouts and Security Review address a narrower, more operational question: can a team see how a particular change behaves and spot plausible exploit paths before shipping? The answer depends on connected signals, review discipline, and the decision authority the team retains.
