Cursor Security Review beta

Cursor Security Review is most useful when you treat it as a router, not a judge: it points risky changes toward the right human, and it never signs for them. Cursor Security Review is an automated pass, part of Cursor, Anysphere's AI code editor, that flags suspicious changes in a diff before merge. It can show you what looks wrong. It cannot decide which customer promise, compliance boundary, or production risk matters most. That ranking stays with your team.

Here is the failure mode it walks into. A middleware PR ships on release day with a green check from the bot. Afterward, the question that mattered surfaces: who approved the new webhook destination? Nobody had. The badge read as approval, so no person made the call.

Read the green check for what it is

A green result means Cursor scanned for the things it knows how to see and found nothing matching. That is genuinely useful. It is not the same as someone deciding this change is safe to ship.

The trap is automation bias, the well-documented habit of trusting a machine's verdict over your own. When every warning lands in the same lane, reviewers learn to scroll, and the riskiest change of the week ships with the same badge as a typo fix.

So give the tool a smaller, honest job. Let it sort risk toward owners. Keep the decision with the people who can name what is at stake.

Route paths before you scan them

Start by naming the paths where Cursor-generated changes meet a higher bar. Keep the list short enough that reviewers actually remember it. This routing block is where your team policy lives, because Cursor can read the diff but the repo decides which areas carry blast radius.

# Cursor security review routing

Red folders:
- `apps/site/src/lib/auth/**`
- `apps/site/src/lib/payments/**`
- `packages/research/pipeline/**/secrets*`
- `.github/workflows/**`

Yellow folders:
- `apps/site/src/app/api/**`
- `apps/site/src/middleware.ts`
- `apps/site/src/lib/seo.ts`

Rule:
- Red folder touched: human security owner must approve.
- Yellow folder touched: attach automated finding summary and verification command.
- Green folder touched: normal product review is enough.

Red folders force a human signoff. Yellow folders ask for evidence. Everything else rides normal product review. That is the whole idea.

Triage findings by type, not by count

Findings turn into noise when they all share one lane, so PRs touching red or yellow folders should carry a triage table. Each finding type gets a required response, which keeps a high-risk change from hiding inside a large agent-generated diff.

The point is not to turn every engineer into an auditor. The point is that a secret and a typo never get the same response.

Make the human sign the evidence

Ask Cursor to help draft the evidence, then make a person make the call. A short block keeps Security Review in the workflow without letting it become the workflow.

## Security review evidence

- Risk route: yellow folder, API handler changed.
- Automated review result: no secrets, no new external destination.
- Human decision needed: confirm request body validation.
- Verification: `pnpm test api-contact`
- Owner: platform reviewer

Five lines, and the last reviewer gets something to check instead of something to trust.

Keep the layers apart

Repeatable security-review behavior belongs in Cursor Skills. Repo-wide boundaries belong in .mdc files per Cursor Rules. Connector ownership belongs in Cursor MCP configuration, with the Model Context Protocol specification defining the boundary language and Cursor Enterprise holding the org-wide defaults.

Mix the layers and you get confident output with unclear authority. When the surfaces move, the Cursor Agent docs and the changelog tell you. The wider delegation patterns sit in the subagents and skills topic hub, and the effort-policy companion to this routing is Bugbot effort levels in Cursor.

A finding without an owner is a fire alarm in a building where nobody is assigned to walk the floors.

Common questions

• Is Cursor Security Review a replacement for human review?

  No. It surfaces suspicious changes, secrets, permission expansion, auth behavior, data movement, and dependency risk, but it cannot rank customer promises or compliance boundaries. Use it as routing: findings flow toward named owners, red folders force human approval, and the green badge never substitutes for a signature from a person who can name the risk.

• What are red folders?

  Red folders are the small set of paths where any change needs a human security owner to approve before merge. Auth, payments, secrets, and CI workflows are the usual list. Yellow folders need an attached finding summary and a verification command. Everything else rides normal product review, which keeps the high-bar list short enough to remember.

• What evidence should a security-reviewed PR include?

  Five lines: the risk route, the automated review result, the human decision still needed, the verification command, and the owner. That block keeps the tool in the workflow without becoming the workflow, and it hands the next reviewer something concrete to check rather than a green badge to trust.

• How do security findings avoid becoming noise?

  Triage by finding type, with a required response per lane. Rotate exposed secrets before merge, require owner approval for permission expansion, and ask for a manual test on auth behavior. When every warning enters one lane, reviewers learn to scroll, and scrolling is how risky changes ship.

• Where should the routing rules actually live?

  In the repo, as an .mdc rule, an AGENTS.md note, or a review checklist that ships before the next automated run. Keeping the rules in version control means the policy is reviewable, auditable, and visible to the agent, instead of living in someone's head or a chat thread that nobody can find later.

What to do next

Pick five red folders and commit the routing block before you widen the beta; the real test is whether a reviewer can say why a path is risky without reading any chat. If you want help drawing that map, book a 15-minute sync.