Cursor: Security for Agents

Security Agents scan your code for security bugs, risky patterns, and vulnerabilities. Cursor ships two managed agent types that cover different moments in the lifecycle: one reviews changes as they arrive, the other goes looking for what is already there.

Both agent 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., and Security Agents themselves require a team or enterprise plan. You configure them from the Security Agents Dashboard at cursor.com/dashboard/security-agents, where you create your first agent.

Each type is blind to what the other covers, which is the argument for eventually running both. A Security Reviewer only ever sees a diff, so anything merged before you switched it on is code it will never read. The Scanner reads the codebase at rest, by which point the change has already shipped. Cursor describes the Scanner as the one that catches problems missed during PR review. That is a fair admission that the Reviewer misses some.

If you are setting up both, start with the Reviewer, and the reason has more to do with who receives a finding than with what gets found. A Reviewer's finding lands on a pull request beside the person who wrote the code that week, and changing it then is cheap. The Scanner's first pass over an older repository comes back as a list with no author attached to any of it. Lists like that sit. Turn the Scanner on second, once somebody has agreed to own what it returns.

The Security Reviewer runs when code changes, on Git-based Automations triggers including pull request and merge request events. The Vulnerability Scanner runs on a cron schedule, independent of whether anyone opened a pull request that day.

Cursor does not suggest a cadence for the Scanner, and the interval that makes sense genuinely depends on how much code lands in a week. What I would watch for is a schedule chosen to look diligent. A nightly scan of a codebase that changes twice a month is mostly re-reading code it read yesterday, so set the interval from how fast the repo actually moves and widen it if the findings stop changing.

Merge request events sit in that list beside pull requests, which is the same moment under GitLab's name for it. The rest of the trigger catalogue belongs to the Automations platform rather than to Security Agents, and Automations covers it.

Each agent has three configuration surfaces: the built-in checks it runs, custom instructions that give it context, and the tools or MCPs it uses to do its work and report findings. They stack, so one agent can run a narrowed set of checks and report into whatever system your team already tracks security work in.

Tools and MCPs are how a Security Agent reaches the place your team tracks security work. The docs put three uses on 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.

The line about needing at least one 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. reads like a note on reporting quality and turns out to be a hard requirement. An agent with checks enabled and instructions written but nothing attached does not run, so check what is attached before you go back through the rest of the configuration.

The obvious first move with a new agent is to go down the built-in checks and switch off whatever you do not want. That is guessing, though, because which checks are noisy depends on the codebase and you have not seen a finding yet. Write the custom instructions first, leave every check on for the first few runs, then disable from evidence.

Where the findings land matters more than it looks. A Slack channel is 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 the channel is fine, because everyone reading it can also fix the thing. Larger than that and each finding needs an owner, so route them into the tracker and let Slack carry the notification.

That is one decision for every Cloud Agent your team runs rather than a Security Agents decision, and the runtime comparison is where to make it.

You don't have to wait for a pull request. Use the /review-security or /review skills to run the Security Agent from your agent before you push the code, so you catch findings while the change is still local.

• What diff is reviewed: by default, /review-security reviews your branch changes, meaning 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.

The default is the broader of those two diffs, and I think it is the right one even though it feels noisy on a branch that has been alive a while. What the Reviewer eventually sees on the pull request is the whole branch, so a local pass over the whole branch is the one that tells you what is coming. Narrow it to uncommitted changes while you iterate on a single file, then widen again before you push.

Stacked branches are where the base-branch default bites first. Branch B is cut from branch A, the skill compares against your default base anyway, and half of what comes back belongs to work that was already reviewed. Name the branch in the prompt.

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

The shared service account is the part that changes behaviour, mostly for the better. Nobody's personal usage moves when a scan runs, so no one is quietly working out whether this week's scan is worth their own budget. The cost of that is an expense with no obvious owner, and on a large team the person who set the cron is rarely the person watching the pool.

Security Agents track three metrics across 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 one that ends up on a slide, so look at what moves it. Disabling a noisy check shrinks the denominator, so the rate can climb without anything being fixed. The numerator comes from a model reading incremental diffs and deciding whether the flagged issue is gone, so it carries whatever error that judgement carries. As a trend across quarters it tells you something, though I would want the runs open before anyone quotes it to an auditor.

Every agent run is tracked in the dashboard. The run 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 for more detail about what the agent did.

When something looks wrong, read the tools column before you re-read your configuration. An agent that ran and reported nothing is a different problem from one that never fired, which the run history answers faster than the settings page does.