Two different jobs after the code is written
Cursor announced Rollouts and Security Review on 23 September for Teams and Enterprise. Rollouts creates a monitoring plan around a pull request and checks its deployed behavior. Security Review looks for exploitable bugs in the context of the codebase; draft pull requests are skipped. Style and general quality checks remain a separate Bugbot role.
This is a September event covered here on 10 October. The launch’s introductory credit window is not presented as a current offer.
A successful deploy is only one input
Cursor’s current Rollouts documentation calls for repository access, deployment events and at least one connected observability tool. Without that telemetry connection, changes remain pending and issues cannot be detected. It tracks environments separately: a staging result does not establish a production result.
The docs describe checks at deployment and after 20 minutes, one hour, one day and three days. A missing deployment event can be supplied through its manual check flow. Rollouts does not merge, revert or roll back changes itself.
Turn one proposed change into a verification brief
Consider a hypothetical change that caches a product-search response. A useful evaluation would ask whether the intended cache behavior happened, not merely whether the release process exited successfully. Here is a worksheet a team could fill out before trialing the feature:
- Change and scope: record the commit, endpoint and environment. Define the response that must remain correct, including the fresh-data case.
- Expected effect: state a measurable expectation in your own terms, such as fewer repeated database reads under the same request pattern. Choose the comparison window before looking at the result.
- Available evidence: list the particular log, trace or metric that can answer that question, its access permissions and its sampling limitations. Mark missing evidence as missing.
- Regression check: include an error case or stale-result case that would matter to the user. A lower latency number alone would not answer whether the returned data is correct.
- Decision owner: name who inspects a finding and who can approve any resulting code or deployment change.
This hypothetical brief is original evaluation scaffolding. It is not a measurement of Cursor’s detection quality. To publish a result, retain the monitoring plan, observed signals, false alerts and unresolved gaps for the same change.
What this report establishes
The official sources establish announced scope and documented controls. They do not establish how reliably the bots detect problems in your application. We did not connect a repository, production telemetry or deployment pipeline, and did not execute a native security review. See the Cursor profile and our published test register for the evidence recorded elsewhere.
Sources and scope
Official sources read 10 October 2026. Facts above are attributed to the provider; the evaluation worksheets are proposed checks. This article does not report a native product test or assign a tool score.