Cursor Rollouts and Security Reviewer: Agents That Watch Your Deploys, Plus How They Fit Cursor Projects

Most AI coding tools stop at the moment code is written. Cursor Rollouts starts where they stop.

On September 24, 2026, Cursor introduced Rollouts: agents that "write a monitoring plan, then watch changes as they deploy," so "regressions are caught before users see them." A companion update makes Security Reviewer 21% faster. Both are available today on Teams and Enterprise plans, with usage credits included for 10 days.

This guide covers how Rollouts works, what Security Reviewer checks, how both fit with Cursor's recent releases (Projects, cloud agents on your own infrastructure), and how to trial them safely.

TL;DR

How Rollouts works, step by step

Cursor's changelog describes a lifecycle with four stages.

1. A PR opens. Rollouts reads the diff and the systems it touches, then writes a monitoring plan as a PR comment. The plan identifies risks, intended effects, signals to check and instrumentation gaps. Teams can edit the plan directly in the comment.

2. The change deploys. Rollouts wakes on deploy events for the change's commit and runs the plan against your logs, metrics and traces.

3. Per-environment tracking. Each environment is tracked separately, so a change can be verified in staging and still be flagged in production.

4. Report and response. Each change gets a status: verified healthy, regression detected, or inconclusive. If it detects a regression, Rollouts names the change it suspects and notifies the author. Depending on configuration, it can open a revert PR for review or hand the finding to a cloud agent for a fix.

The image Cursor shared shows the pattern: a card reading "Rollouts created plan 3h ago," with a plan that checks JS errors on rollout-related routes, and a severity indicator. That is the product: a plan, a watcher, and a verdict.

Why the monitoring plan is the interesting part

Anyone can point an AI at an error dashboard. The novelty is the plan written at PR time, when the agent has the most context about what the change is supposed to do.

A good plan states:

• Intended effect: "checkout latency should drop for cart sizes over 20 items."
• Risk: "the new cache key may collide across tenants."
• Signals: "error rate on /checkout, p95 latency, cache hit ratio, tenant-scoped 403s."
• Instrumentation gaps: "no metric exists for cache key collisions."

The last item is the quiet win. If a plan says "we cannot verify this because nothing measures it," reviewers can ask for instrumentation before the merge, not after an incident. Because the plan is a PR comment, humans can edit it, which makes review a conversation.

What Rollouts does not do

Cursor is explicit about the guardrail: Rollouts does not autonomously merge or roll back. It proposes a revert PR or delegates a fix. That is the right default for production, and it matches how teams adopt agents: read access first, write access with review, autonomy last.

Also note the stated statuses include inconclusive. An agent that admits it lacks enough signal is more useful than one that always says "healthy." Track how often you get inconclusive verdicts; a high rate usually means missing telemetry, not a weak agent.

Security Reviewer: what changed

Security Reviewer scans every PR for exploitable issues. Cursor's list includes SQL, command and template injection, authentication bypasses, secrets in source code, SSRF, unsafe deserialization and vulnerable dependencies. Each finding includes severity, attack path and proposed fix, and teams can set custom rules for codebase-specific enforcement.

The update: it now finishes 21% faster, in 3.8 minutes on average, down from 4.8. Reporting on the launch also cites a 60 to 70% comment acceptance rate; treat that as a vendor-side metric and measure your own. Speed matters because reviewers merge when checks finish; a review that takes five minutes gets skipped, and one that takes under four is more likely to be waited for.

If you use AI for security review at the prompt level, our security review prompt library pairs well. And for the risk side, see the incident coverage of an AI agent linked to breaches at seven companies.

How this fits with Cursor Projects and cloud agents

Cursor has shipped a stack in three weeks:

The pieces connect. Projects can coordinate implementation; cloud agents do the work in isolated VMs (see event-driven cloud agents); Rollouts watches the result in production and can send a regression back to a cloud agent. That closes a loop: plan, build, verify, fix.

Cursor's changelog navigation references a Projects post, but the Rollouts page gives no Projects-specific detail. Do not assume built-in coupling beyond what is stated: the documented handoff is from Rollouts to a cloud agent. For the wider trend of event-driven agents that wake on signals, see harness engineering concepts.

What people are asking

"Is this only for big teams?" It launched on Teams and Enterprise. One reply said their side projects run on the free tier, meaning they are not the target buyer. Check plan details before planning a rollout.

"What does it cost after the trial?" Not stated. The 10-day credits cover roughly 50 changes for Teams and 500 for Enterprise; ask sales for post-trial pricing.

"Does it replace my observability stack?" No. It reads from Datadog and similar telemetry. It automates the checking you should be doing after each deploy.

"Can it break production?" Per Cursor, it does not merge or roll back autonomously. The risk is a wrong verdict, not an unauthorized action.

"How does it compare with Claude Code?" Both tools are moving into background and cloud workflows; see Claude Code vs Cursor vs Copilot and Claude Code cloud sessions going GA. Rollouts targets post-merge verification, which is a different slot from writing code.

How to trial it in the 10-day window

1. Pick low-risk services with good telemetry. Rollouts can only verify what you measure.
2. Connect source control and telemetry first; confirm environments map correctly.
3. Review the first five plans by hand. Edit them to see how the agent responds.
4. Track verdict quality. Count true positives, false alarms and inconclusive results.
5. Test the revert path in staging: does the revert PR make sense?
6. Time Security Reviewer against your current CI checks. Does it fit inside your PR loop?
7. Decide before credits end whether it earns a budget line.

What "verified healthy" should mean to you

A verdict is only as good as the signals behind it. Before you trust a green check, ask three questions.

• Was the signal specific? A verdict based on global error rate can miss a regression that hits one route or one tenant. Prefer plans that name the routes, queues or feature flags the change touched.
• Was there enough traffic? A deploy on a quiet service may never exercise the new code path. "Healthy" on zero requests is not evidence.
• Was the comparison fair? Good verification compares against a baseline: the same environment before the deploy, or a canary versus stable. Ask what baseline Rollouts used for each plan.

Treat inconclusive as a to-do, not a failure: add the missing metric, generate synthetic traffic, or extend the watch window. Over a few weeks the pattern of inconclusive results is a map of your observability gaps.

Where it can go wrong

• Noisy telemetry. If your dashboards are full of ignored alerts, an agent will inherit the noise.
• Plans that overreach. A plan that lists twenty signals for a one-line change wastes attention. Edit it down.
• Multi-service changes. A change that spans repositories is harder to attribute; check how the suspected-change logic behaves when two PRs deploy close together.
• Alert fatigue. Notifying the author is useful only if the message is specific and actionable.
• Security Reviewer disagreement. Automated findings still need triage. Decide who owns false positives, and use custom rules to encode decisions once.

Bottom line

Rollouts is a smart place to put an agent: after the merge, where teams are least attentive and incidents are most expensive. The design choices, a plan written at PR time, per-environment verdicts, an honest "inconclusive," and no autonomous rollback, are sensible. Success depends on your telemetry quality. Use the 10-day credit window to measure, not to guess.

Details reflect Cursor's September 24, 2026 changelog and press coverage. Availability, credits and features may change.

Related reading

• Cursor Projects: persistent agents with shared context
• Cursor cloud agents on your own infrastructure
• Cursor event-driven cloud agents in isolated VMs
• Cursor agent swarms: model economics
• Claude Code cloud sessions GA
• Top AI prompts for security review
• Top 10 harness engineering concepts
• Official: Cursor changelog: Rollouts and Security Reviewer