Cursor: Security for Agents

Cursor manages two Security Agent types, and each one covers a different moment in the life of your code. One reviews changes as they arrive. The other looks for problems that are already in the codebase.

Both types run on the Automations platform and require Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition.. Security Agents need a team or enterprise plan. Cursor's docs put the setup in Automations, where each agent type has its own page.

Plan to run both eventually, because each one leaves a gap. The Reviewer doesn't scan the code you already have, and the Scanner sees a change only after it merges. Cursor also says the Scanner catches problems missed during PR review, which means the Reviewer misses some.

If you set up both, start with the Reviewer, because of who sees each finding. A Reviewer's finding lands on the pull request, in front of its author, while the change is fresh and cheap to fix. The Scanner's first pass over an older repository returns a list of findings with no author attached. Turn the Scanner on second, once someone has agreed to own that list.

A Security Reviewer reacts to code changes. A Vulnerability Scanner runs on a schedule, whether or not anyone opened a pull request.

Cursor doesn't suggest a cadence for the Scanner, and the right interval depends on how much code lands in a week. Don't pick a schedule because it looks diligent. A nightly scan of a codebase that changes twice a month mostly re-reads code it read the night before. Set the interval from how fast the repo moves, and widen it if the findings stop changing.

Merge request events sit beside pull request events because they are GitLab's name for the same moment. The rest of the trigger catalog belongs to the Automations platform, not to Security Agents, and Automations covers it.

Beyond its trigger, each agent has three things to configure: the built-in checks it runs, custom instructions that give it context, and the tools or MCPs it uses to work and to report findings. They stack, so one agent can run a narrow set of checks and report into the system where your team already tracks security work.

Tools and MCPs connect a Security Agent to the systems where your team tracks security work. Cursor's docs give three uses for them:

• 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 MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition..
• Give the agent extra context from tools or MCPs before it reports a finding.

A Vulnerability Scanner with no tool still reports. Its findings appear in the Flagged Vulnerabilities list in Automations. A tool or MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. sends them on to Slack or your issue tracker as well, so attach one if your team triages security work there.

The obvious first move with a new agent is to go down the built-in checks and switch off whatever you don't want. That is a guess, because which checks are noisy depends on the codebase, and you haven't seen a finding yet. Write the custom instructions first, leave every check on for the first few runs, then disable checks based on what they report.

Where findings land decides whether anyone fixes them. A Slack channel gets read the week it is created and skimmed after that, while an issue tracker holds a finding until somebody closes it. On a team of five, a channel works, because everyone who reads it can also fix the problem. On a larger team, each finding needs an owner, so send findings to the tracker and let Slack carry the notification.

Cursor runs Security Agents on Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., and you can use Cursor's cloud with no additional setup. The exception is a team's Security Reviewer. When a pull request event triggers it, the review runs on Cursor-managed hosting instead of a Cloud Agent.

Earlier versions of this page said reviews could also run on self-hosted Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. in your own environment. Cursor's current Security Agents docs don't mention self-hosting, so ask Cursor before you plan around it. Self-hosting wouldn't cover the exception above in any case, because those pull request reviews don't run on a Cloud Agent.

The choice between Cursor's cloud and self-hosting belongs to Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. in general. The Security Agents docs describe no runtime setting of their own, and the runtime comparison walks through the options.

You don't have to wait for a pull request. Run the /review-security or /review skill from your agent before you push, and you see findings while the change is still local.

The default is the broader diff, and we think it is the right one, even on a long-lived branch where it feels noisy. The Reviewer sees the whole branch once you open the pull request, so a local pass over the whole branch shows you what is coming. Narrow it to uncommitted changes while you iterate on one file, then widen it again before you push.

Stacked branches are where the base-branch default goes wrong. If you cut branch B from branch A, a comparison against your default base branch also covers A's changes, so B's review reports findings that belong to A. Name the base branch in the prompt.

Cursor bills Security Agents at the team usage level. Usage is charged to the team's usage pool, and the agents run under a shared team service account, so they don't affect any individual user's usage.

The shared account changes how people behave, mostly for the better. A scan never touches anyone's personal usage, so nobody has to weigh this week's scan against their own budget. The downside is a bill with no obvious owner. On a large team, the person who set the cron schedule is often not the person watching the usage pool.

Cursor tracks three metrics across agent runs. To decide whether an issue was fixed, Cursor uses LLMs to review incremental diffs and assess whether the flagged issue was resolved.

Resolution rate is the number that ends up on a slide, so check what moves it. Disabling a noisy check means fewer findings get reported, so the rate can climb without anything being fixed. The numerator comes from a model that reads incremental diffs and judges whether the flagged issue is gone, so it carries that judgment's error. Read it as a trend across quarters, and open the underlying runs before anyone quotes it to an auditor.

Automations tracks every agent run, and each agent type's page lists the recent runs of its own agents. The history shows 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. A review that ran on Cursor-managed hosting has no Cloud Agent, so it opens as a read-only view of the review session.

When something looks wrong, open the run history before you re-read the configuration. It tells you quickly whether the agent ran and reported nothing or never fired at all.