Three years ago I got paged at 2am because a config change dropped a timeout from 30 seconds to 3, and nobody noticed until a downstream queue backed up hard enough to trip an alert two services away. The PR that caused it had two approvals. Both reviewers read the diff, saw a number change, and moved on — neither of them had the mental model of “this timeout interacts with that retry policy three services over” loaded in their head at 4pm on a Thursday. That’s not a reviewer failing. That’s what code review actually is: a snapshot judgment on a diff, made by someone who cannot simulate production in their head no matter how senior they are.

So when Cursor announced two new agents on September 23 — Rollouts and Security Reviewer — my first reaction wasn’t skepticism. It was recognition. Both are aimed at exactly the gap that paged me that night: the stuff a diff-level read cannot catch, either because the risk is a security-shaped one buried in mundane code, or because the risk only shows up once real traffic hits it.

What these two agents actually do

Security Reviewer runs on every PR and reads the change with the surrounding codebase as context, not in isolation. The pitch that matters here isn’t “it checks for bad patterns” — every linter does that — it’s that it traces where user input actually flows to, the sink, rather than pattern-matching known-bad shapes. That’s the difference between catching eval(userInput) — trivial, any static analyzer gets that — and catching user input that gets concatenated three function calls deep into a query string that only becomes a SQL injection because of how a helper function upstream handles escaping. It covers injection (SQL, command, template, LDAP), broken auth, hardcoded secrets, unsafe deserialization, unvalidated redirects, vulnerable dependencies, and insecure infra defaults. Each finding comes with a severity rating, the attack path, and a one-click fix. Cursor’s own numbers: average review time dropped from 4.8 to 3.8 minutes per PR, and comment acceptance went from 45-50% up to 60-70%.

Rollouts is the more interesting one, because it doesn’t stop at merge. Before the PR lands, it reads the diff and writes a monitoring plan — what to watch, what regressions would look like, where the instrumentation gaps are. You can edit that plan by hand before it ships. After deploy, it pulls live signals from Datadog, Grafana, or Honeycomb and compares them against the pre-deploy baseline, trying to separate “this metric moved because the feature is supposed to do that” from “this metric moved because something broke.” Cursor’s example is a good one: it catches a regression confined to a single endpoint in a single region — the kind of thing that never trips a global alert threshold because the blast radius is too small to move the aggregate number. When it thinks it’s found a real regression, it can ping the PR author, pause a progressive rollout, or open a revert PR that waits for approval.

Both are Teams and Enterprise tier only, which tells you something about who Cursor thinks should be making this call — not solo devs, but orgs with existing on-call and review processes to slot this into.

Where I actually land on this

Security Reviewer, I’m comfortable with, once the severity threshold for interruption is tuned. Its worst failure mode is a false positive that wastes ten minutes, or a false negative that a human would’ve caught anyway — the same failure modes a strict linter has, just with better precision on the false-positive side if Cursor’s traced-sink claim holds up under real use. Nobody dies if it hallucinates a vulnerability. Someone re-reads a diff.

Rollouts is where I want to slow down, specifically at “create revert PRs awaiting approval.” Read that phrase twice — “awaiting approval” is the safety valve, and it’s the right default. An agent that can unilaterally revert production without a human in the loop is a different product than the one Cursor shipped, and a much scarier one. But “awaiting approval” only holds up if the humans downstream treat that approval step as real judgment rather than a rubber stamp — and we already know from watching how people handle permission prompts in general that approval fatigue is a real, measured phenomenon, not a hypothetical. A revert PR that shows up looking authoritative, with graphs and a confident narrative about which commit caused the regression, is exactly the kind of thing a tired on-call engineer approves at 3am without re-deriving the causal chain themselves. The agent didn’t remove the human from the loop. It just made the human’s job “trust this plausible-looking analysis” instead of “diagnose the regression,” which is a real shift in what’s being verified.

Here’s the failure mode that actually worries me: a false positive on a real incident. Say a genuine regression hits at the same time as an unrelated, benign metric shift — a scheduled batch job, a marketing push driving traffic to a specific region, whatever. Rollouts correlates the wrong deploy to the real regression, because correlation-based regression detection will do that under enough noise. It opens a revert PR against the wrong commit, confidently, with a graph. Now you’ve got two problems: the actual incident, still live, and an on-call engineer whose attention just got redirected to reverting the wrong thing because the tool handed them a plausible-looking answer instead of an open question. Automated regression detection is a great triage signal. It’s a bad final verdict, and the UI should not let it read like one.

The policy I’d actually put around this

If I were rolling these out on my own team, here’s roughly where I’d draw the lines:

security_reviewer:
  pr_comment_only:
    - low
    - medium
  page_human_on_open:
    - high
    - critical
  auto_block_merge:
    - critical: hardcoded_secret
    - critical: auth_bypass
  # false negative on a critical finding is the real cost here,
  # so critical gets a human even if the fix looks trivial

rollouts:
  auto_actions_allowed:
    - ping_pr_author
    - annotate_dashboard
  requires_human_approval:
    - pause_progressive_rollout   # cheap to reverse, but still traffic-affecting
    - open_revert_pr              # per Cursor's own default — keep it
  never_auto_execute:
    - merge_revert_pr             # this is the one line that must stay human, always
  confidence_threshold_to_notify: 0.7
  minimum_baseline_window: 30m    # don't correlate against a baseline shorter than your
                                   # noisiest known recurring traffic pattern
  concurrent_incident_check: true # if there's already an open incident, downgrade
                                   # to "annotate the incident channel," not a fresh revert PR

The one rule I wouldn’t compromise on: the revert PR gets filed automatically, but it never merges automatically, and it never merges during an already-open incident without someone explicitly looking at the correlation the agent used, not just the conclusion. If your team can’t staff that five-minute human check at 3am, that’s a real gap in your on-call setup — one this tool is exposing, not creating — and the fix is better on-call coverage, not a lower bar for auto-merge.

Practical checklist if you’re turning either of these on this quarter:

• Set Security Reviewer’s page threshold at critical/high only — everything else stays a PR comment, or you’ll train people to ignore the pings within a week.
• Require a named human to click merge on any Rollouts-generated revert PR. No exceptions, no “if confidence > 95% auto-merge” carve-out — that carve-out is exactly where the false-positive-during-a-real-incident scenario bites.
• Check whether Rollouts flags an open incident before opening a second one. If it can’t do that yet, someone on your team owns manually checking for that overlap before approving any revert it proposes.
• Review the monitoring plan Rollouts drafts before merge, don’t just accept it — that’s the one human-editable step Cursor left in, and skipping it defeats the point of having it be editable.
• Track false-positive rate on both agents for the first month like you’d track a new alerting rule’s noise ratio. If nobody’s watching that number, you won’t know you have a problem until the wrong revert PR gets rubber-stamped.