Security Agents

Security Agents scan your code for security bugs, risky patterns, and vulnerabilities.

Configure Security Agents in Automations. Each agent type has its own page: Security Reviewer and Vulnerability Scanner.

How it works

Security Agents include two Cursor-managed agent types:

• Security Reviewer checks pull requests before they merge. Use it to catch vulnerabilities during code review.
• Vulnerability Scanner scans your codebase at rest. Use it to find pre-existing vulnerabilities, long-standing issues, and problems missed during PR review.

Both agent types run on the Automations platform and require Cloud Agents.

Setup

Open the Security Reviewer or Vulnerability Scanner page in Automations to configure that agent type.

Source control support

Security Reviewer supports pull requests on Origin, GitHub, and GitLab. For pull request reviews on Bitbucket or Azure DevOps repositories, use Bugbot.

Triggers

Security Reviewer agents support Git-based Automations triggers, including pull request and merge request events. Use these triggers to run security checks when code changes.

Vulnerability Scanner agents support cron-based triggers. Use these triggers to scan your codebase on a recurring schedule, independent of pull request activity.

Each Vulnerability Scanner has one schedule. To change when it runs, edit its existing trigger. To scan on another schedule, create a separate Vulnerability Scanner. A scan across more than 1,000 repositories can hit provider rate limits, so split large scopes into separate Vulnerability Scanners with smaller repository scopes.

Security Checks

Both agent types include built-in security checks. Enable or disable individual checks based on what you want each agent to review.

Custom instructions

Use custom instructions to give each agent more context. You can describe the types of issues to prioritize, explain project-specific security expectations, or define how the agent should behave.

Tools and MCPs

Both agent types support tools and MCPs. A Security Reviewer needs at least one tool or MCP before you can save it. A Vulnerability Scanner saves without one and reports its findings to the Remediation agents section on the Vulnerability Scanner page in Automations.

Use tools and MCPs to connect Security Agents to the systems where your team tracks security work.

• Send vulnerabilities to a Slack channel, issue tracker, or another connected system.
• Add custom instructions that explain when and how the agent should use each MCP.
• Give the agent extra context from tools or MCPs before it reports a finding.

Environment Setup

Security Agents run on Cloud Agents, with two exceptions on a team. A team's Security Reviewer runs on Cursor-managed hosting instead of a Cloud Agent when a pull request event triggers it, and a team's Vulnerability Scanner runs its scans there too. Teams that require Self-Hosted Machines keep both on Cloud Agents.

You can use Cursor's cloud with no additional setup.

Run in your agent

Use the /review-security or /review skills to run the Security Agent from your agent before you push the code.

What diff is reviewed: By default, /review-security reviews your branch changes: every change relative to the base branch, including committed and uncommitted changes. Ask it to review only your uncommitted changes when you want narrower feedback.

Against which branch: /review-security compares against your default base branch. When your base branch isn't the default (such as main), tell the agent which branch to compare against or let it infer from the context.

Billing

Security Agents are billed at the team usage level:

• Usage is charged to the team's usage pool.
• Agents run under a shared team service account, so they don't affect any individual user's usage.

Analytics

Security Agents track three key metrics across agent runs. The Security Reviewer page in Automations shows them:

• Vulnerabilities found: the number of security findings reported by agents.
• Issues fixed: the number of findings that were resolved after they were reported.
• Resolution rate: the percentage of reported findings that were fixed.

To determine whether an issue was fixed, Cursor uses LLMs to review incremental diffs and assess whether the flagged issue was resolved.

Viewing Runs

Every agent run is tracked in Automations. Each agent type's page lists Recent Runs for its own agents. Use the run history to see when an agent ran, which tools it used, its final status, and how long it took.

Open a run to inspect the underlying Cloud Agent for more detail about what the agent did. A review or scan that ran on Cursor-managed hosting has no Cloud Agent. Find a hosted review under Recent Runs on the Security Reviewer page, where it opens a read-only view of the review session.

Remediation Agents

Remediation agents check the findings produced by the scanner and help you verify and fix them.

For each finding, Cursor starts an agent that writes exploit tests to verify the issue and automatically patch the confirmed ones.

Find it in the Vulnerability Remediation section and on each scanner's detail page.

How it works

Each finding moves through four steps:

1. Flagged. Vulnerability Scanner reports the finding.
2. Verified. A verification agent writes tests against the real code path and runs them. It returns one of three verdicts:
   • Confirmed: the tests confirm the issue.
   • Refuted: the tests show the issue can't happen.
   • Inconclusive: the agent couldn't reach a conclusion.
3. Tests PR. For a confirmed finding, the verification agent opens a draft pull request with its tests. These tests fail on purpose until the issue is fixed.
4. Fix PR. A patch agent writes the fix, checks it against the tests, and opens a draft pull request for you to review.

Cursor never merges a fix for you. Merging is always your call.

Remediation settings

Each Vulnerability Scanner has two remediation settings. Turn them on in the scanner's settings in Automations.

Reviewing findings

The Vulnerability Remediation section groups findings into tabs by what they need next:

Open a finding to take manual actions on it as needed.

Vulnerability Remediation API

Enterprise teams can use the Vulnerability Remediation API to list findings, request verifications and fixes, and track their progress. Create an API key from Cursor Dashboard → API Keys and authenticate with Basic Authentication.

Each endpoint allows 20 requests per minute per team. List endpoints use cursor pagination: pass a response's nextCursor as cursor to read the next page. When nextCursor is null, there are no more pages.

If Vulnerability Remediation isn't enabled for your team, every endpoint returns 403 Forbidden.

curl --get https://api.cursor.com/security/findings \  -u YOUR_API_KEY: \  --data-urlencode 'limit=50'

{  "findings": [    {      "findingId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "repository": "github:your-org/your-repo",      "severity": "high",      "title": "Missing authorization check on invoice export",      "location": "src/billing/export.ts",      "status": "active"    }  ],  "nextCursor": "Z2l0aHViOnlvdXItb3JnL3lvdXItcmVwbwozZjJi..."}

curl --request POST \  --url https://api.cursor.com/security/verifications \  -u YOUR_API_KEY: \  --header 'Content-Type: application/json' \  --data '{    "findingIds": ["3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47"],    "verify": true,    "patch": true  }'

{  "verifications": [    {      "findingId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "verificationId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47"    }  ],  "skipped": []}

{  "code": "error",  "message": "No vulnerability scanner is running for this team"}

curl --get https://api.cursor.com/security/verifications \  -u YOUR_API_KEY: \  --data-urlencode 'limit=50'

{  "verifications": [    {      "verificationId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "findingId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "repository": "github:your-org/your-repo",      "commitSha": "9f3c2a1b7d8e4f5061728394a5b6c7d8e9f0a1b2",      "severity": "high",      "status": "completed",      "verdict": "confirmed",      "verifiedAt": "2026-10-20T18:04:11.000Z",      "testsPrUrl": "https://github.com/your-org/your-repo/pull/128",      "verificationAgent": {        "id": "bc-5b1e9d2a-0c47-4f8e-a3d6-7e2b9c4f1a08",        "url": "https://cursor.com/agents/bc-5b1e9d2a-0c47-4f8e-a3d6-7e2b9c4f1a08"      },      "patch": {        "status": "completed",        "agent": {          "id": "bc-8d4a7f3c-2e19-4b6d-9a05-c1f7e8b3d264",          "url": "https://cursor.com/agents/bc-8d4a7f3c-2e19-4b6d-9a05-c1f7e8b3d264"        },        "fixPrUrl": "https://github.com/your-org/your-repo/pull/129",        "fixPrMerged": false      }    }  ],  "nextCursor": null}

curl https://api.cursor.com/security/verifications/3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47 \  -u YOUR_API_KEY:

Verification fields

status values:

patch.status values:

Errors

Errors return a JSON body with a message:

{  "code": "error",  "message": "Vulnerability verification is not enabled for this team"}

Verify and fix findings

1. Call GET /security/findings and pick the findings you want to act on.
2. Call POST /security/verifications with their findingIds. Set verify and patch to true to verify them and open fix PRs for confirmed ones.
3. Save each returned verificationId.
4. Poll GET /security/verifications/{verificationId} until status is completed.
5. Review the pull request at patch.fixPrUrl.

Related pages

• Bugbot reviews pull requests for bugs before they merge.
• Rollouts monitors each pull request as it deploys and reports its health in every environment.