Security Agents and Rollouts in Cursor: Security Checks and Release Monitoring

In Cursor Automations, you can configure code security checks and release monitoring. Security Agents review pull requests (PRs) and scan the entire repository on a schedule. Rollouts monitors a change after deployment, is available on Teams and Enterprise plans, and requires connected telemetry: logs, metrics and traces.

Below are the setup steps based on Cursor's official documentation, how Security Agents usage is accounted for, plan restrictions, and the differences from Bugbot and the manual /review-security command.

Information about using Ailoot is available in the documentation.

What are Security Agents in Cursor?#

The agent type determines how a check starts:

• Security Reviewer is triggered by Git events: a pull request or merge request.
• Vulnerability Scanner runs on a cron schedule and scans the codebase independently of PR activity.

Cron lets you schedule recurring scanner runs.

How to enable Security Reviewer and Vulnerability Scanner#

Steps

1. Open Security Agents in Automations (the section is described in the Security Agents documentation).
2. Choose the agent type: Security Reviewer (PR review) or Vulnerability Scanner (scheduled scanning).
3. For Security Reviewer, configure a Git trigger: a pull request or merge request event. For Vulnerability Scanner, configure a cron schedule.
4. Enable or disable the built-in security checks: both agent types have them, and you can adjust the set to suit the task.
5. Connect a tool or MCP server: these let the agent connect to the systems where the team manages its security work. This is required for Security Reviewer: you cannot save it without at least one tool or MCP connection. Vulnerability Scanner can be saved without them and sends its findings to the Flagged Vulnerabilities list.
6. Save the agent.

Tools and MCP let you send vulnerabilities found by the agent to a Slack channel, an issue tracker or another connected system.

Verification

The Automations history shows when each agent ran, which tools it used, how the run ended and how long it took. For a Security Reviewer check that ran on Cursor's hosting, look in Recent Runs on the Security Agents page: you can open the review session in read-only mode.

Vulnerability Scanner findings appear in Flagged Vulnerabilities on the Security Agents page and each scanner's page. The list is grouped by repository; you can filter findings by scanner, status, feedback and severity. Each has a Fix in Cursor action that starts a cloud agent to fix the vulnerability.

Errors

If Security Reviewer cannot be saved, check that at least one tool or MCP connection is configured: saving fails without one.

Who pays for the checks: Security Agents usage#

According to the documentation, Security Agents usage is deducted from the team's usage pool. The agents run under the team's shared service account, so they do not consume an individual member's allowance.

The documentation page does not specify prices or which plans include Security Agents. Before enabling them across all repositories, check availability in your account and see how much the first runs consume from the team's pool.

How Security Reviewer differs from /review-security and Bugbot#

These mechanisms have similar goals, but they start in different ways.

/review-security and /review can be run manually from the agent before pushing code to a remote repository. By default, /review-security checks the branch's changes against the base branch, including both changes already saved in commits and changes not yet committed. You can ask it to limit the review to the latter. The commands are available in Cursor 3.7 and later, on cursor.com/agents and in the Cursor CLI. You decide when to run the review.

Security Reviewer is an agent in Automations that runs automatically on a Git trigger.

Bugbot is a separate Cursor product for PR review. According to the documentation, it looks for bugs, vulnerabilities and code quality problems, leaving comments with explanations and suggested fixes. It runs automatically whenever a PR is updated, or manually.

Security Agents are designed for security checks: they have built-in checks, scheduled scans of the entire repository, and a Flagged Vulnerabilities list with statuses and severity levels. The documentation does not compare the quality of findings from Bugbot and Security Agents.

Rollouts: monitoring after deployment#

What Rollouts does

When a pull request is opened, Rollouts reads the changes and the affected systems and creates a deployment monitoring plan. The plan lists the risks it identified, the expected effect of the change, signals to check, and gaps in data collection that make the change difficult to verify. On GitHub, GitLab.com and Bitbucket Cloud, the plan appears as a PR comment.

Rollouts runs checks on deployment events and compares the plan against logs, metrics and traces. Each environment is tracked separately: a change can pass the checks in a test environment and still be flagged as problematic in production. Checks run at deployment time, then after 20 minutes, 1 hour, 1 day and 3 days.

If a regression is found, Rollouts identifies the change it suspects caused it, opens an issue and notifies the author. On the issue page, the Fix issue button starts a cloud agent. Rollouts does not merge, revert or roll back changes itself.

How to configure Rollouts

1. In Automations, click Enable on the Rollouts card in From Cursor.
2. Choose the repositories to monitor. You can specify up to 200 repositories in the settings.
3. Configure deployment events: Rollouts needs to know when each production deployment starts and finishes. To do this, create a Cursor API key and store it in your build system's (CI) secrets as CURSOR_API_KEY. There are then two options: add the calls to the deployment process manually (the commands are in the Send deployment events section of the Rollouts documentation), or ask the setup agent to do it. The agent will open a PR containing these calls. Merge that PR to finish setup.
4. Connect telemetry, such as Datadog. At least one connected tool is required.
5. Choose how PR authors will receive notifications.

Restrictions that are easy to overlook

Without connected telemetry, changes remain pending and Rollouts cannot detect problems. If the project does not yet have Datadog or a similar monitoring system, you will need that first.

Slack notifications are unavailable in Privacy Mode. A team administrator must add Rollouts to Slack first.

Who needs this, and who should wait#

If you work alone, check whether Security Agents are available in your account before enabling them: usage comes from the team's pool, and the documentation page does not list eligible plans. You start the fix for a vulnerability found by the scanner yourself: Fix in Cursor opens a cloud agent to work in the repository.

According to the documentation, Rollouts is available only on Teams and Enterprise plans. If you do not yet have a monitoring system such as Datadog, start with that and connect Rollouts afterwards.

For more on Cursor plans, see what a Cursor subscription includes. If you already have task coordination between agents configured in Cursor, see Cursor Projects: how the coordinator delegates tasks.

Summary#

Security Reviewer reviews PRs before merging; Vulnerability Scanner scans the entire repository on a schedule. Usage for both agent types is deducted from the team's pool. Rollouts monitors a change after deployment, is available on Teams and Enterprise, and requires at least one connected telemetry source.

Get to know Ailoot.