Cursor Security Review beta

The situation

Cursor has added Security Review in beta for Teams and Enterprise. The changelog describes two always-on security agents: Security Reviewer and Vulnerability Scanner. Security checks can now sit inside the workspace instead of living as a one-off prompt or a manual pass before merge.

For teams already using Cursor rules, subagents, and MCP, this fits the same workflow. Security work can live closer to the codebase and the repo’s operating model. Admins can enable a managed review layer in the Cursor dashboard and run it on a schedule or on trigger.

The first questions are practical: what gets scanned, what gets sent to Slack, what instructions the agent should follow, and which external scanners stay the source of truth.

If your team already organizes conventions in AGENTS.md, scoped rules, or custom agent workflows, the security agents fit that pattern. See Cursor subagents and skills.

What changed

The changelog says admins can enable Security Review in the Cursor dashboard, and the agents draw from the team’s existing usage pool. It also says Vulnerability Scanner can send updates to Slack, and that teams can adjust triggers, add instructions, give the agents custom tooling, and choose how outputs are shared.

That changes the workflow in a simple way: security review becomes a shared team setting, not just an individual habit. The useful habit to build is ownership. Decide who turns it on, who reviews the output, and who decides when a finding needs human follow-up.

A good first rollout is one repo, one admin owner, and one output path. Start with one Slack channel and one severity threshold. If the channel fills with low-signal warnings, people will mute it.

What to try

Customize the agent instead of assuming the default behavior will match your repo. A short AGENTS.md boundary can define what counts as security-sensitive, what should never be auto-fixed, and when a human review is required.

# AGENTS.md

## Security review boundary
- Treat dependency bumps, auth flows, and secret-handling code as high-risk.
- Do not auto-apply fixes to auth, payment, or deployment logic.
- Escalate findings that touch secrets, permissions, or production config.
- Summarize all changes with file paths and a short risk note.

If your team already uses external scanners, Cursor’s MCP support is the cleanest way to connect them. The changelog calls out plugging in MCP servers for existing SAST, SCA, and secrets scanners so Cursor can use them during review. Keep the specialized tools where they already live, and let Cursor orchestrate the review surface.

A small .mdc rule stub can keep the agent scoped:

---
description: Security review for dependency and config changes
globs:
  - "**/package.json"
  - "**/pnpm-lock.yaml"
  - "**/*.yml"
  - "**/*.yaml"
apply: auto
---
Flag known-vulnerability, outdated-dependency, and config-risk issues.
Prefer concise findings with file paths, evidence, and suggested next checks.

Review checklist

Use a short checklist before widening rollout:

• Confirm the agent is enabled only for the intended team or repo.
• Verify Slack routing is limited to the right channel and severity.
• Check that custom instructions do not suppress important findings.
• Confirm MCP connectors have least-privilege access.
• Review one sample report before expanding use.
• Keep human sign-off for auth, secrets, and deployment changes.

Tradeoffs and limits

The main benefit is consistency. Always-on agents can catch known vulnerabilities, outdated dependencies, and configuration issues without waiting for someone to remember a checklist. They also reduce the gap between code changes and security feedback.

The limits are familiar. Scheduled scans can create noise if the repo has many stale dependencies or if severity thresholds are not tuned. Slack delivery can amplify that noise. MCP connectors also widen the trust boundary, so every external scanner should be reviewed for permissions and data exposure.

Cursor notes that the runtime, harness, and models are still being improved. Treat early results as a baseline, not a final control. Validate the agent against your own repo patterns before relying on it for release gating.

Security agents do not replace repo conventions. If your AGENTS.md, rules, and review habits are vague, the agent will inherit that ambiguity. The better setup is clear instructions, narrow triggers, and a human review path for high-risk changes.

Further reading

• https://cursor.com/changelog
• https://cursor.com/docs
• https://cursor.com/docs/rules
• https://modelcontextprotocol.io/docs/getting-started/intro
• https://github.com/anthropics/skills/blob/main/README.md
• https://github.com/openai/skills/blob/main/README.md

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.