Cursor's Security Review bot reads your pull requests for exploitable bugs
It posts one comment per PR, skips drafts, and takes your own security rules. What's missing is any accuracy data.
Cursor launched a Security Review bot on September 23, alongside the Rollouts deploy monitor we covered in an earlier post . It reads pull requests and reports vulnerabilities an attacker could actually exploit. Per the Cursor changelog , it’s on Teams and Enterprise plans.
The pitch is context. A pattern-matching scanner flags every string-built SQL query it sees. Cursor says its bot reviews each change within the context of your codebase, so it can ask whether the input is really reachable by an attacker.
How it behaves
You turn it on per repository from the Cursor dashboard. It skips draft pull requests, which is a sensible default: nobody wants a security verdict on code that’s still a sketch.
On a ready PR, it posts a single review comment. That comment lists the exploitable bugs it found, each with a severity level and a proposed fix. One comment, not a thread of line notes, means it’s easy to scan and easy to ignore, depending on how much you trust it.
Cursor lists the kinds of problems it looks for: SQL, command and template injection, authentication bypasses, credential leaks, server-side request forgery, unsafe deserialization, and vulnerable dependency changes.
Team rules
The feature most likely to matter in practice is team rules. You can have the bot enforce policies specific to your codebase. Generic scanners can’t know that your internal runAsAdmin() helper must never be called from a request handler, or that all outbound HTTP has to go through one wrapper. Writing that down once, in a place the reviewer reads, is the sort of institutional knowledge people usually keep in one senior engineer’s head.
What we don’t know
The changelog doesn’t say how often the bot is right. There’s no false positive rate, no comparison against a conventional static analyzer, and no list of what it misses. For a security tool, that’s the number that decides whether it earns its place in a merge queue.
It also doesn’t say what happens to a pull request when the bot finds something. Treat it as advisory until you’ve seen how it behaves.
How to try it
Don’t switch it on across the org. Pick one repository and test it against code where you already know the answer. Put a deliberately vulnerable change on a branch, one real class of bug at a time, and see which ones it catches and how it ranks them. Then run it on a few weeks of merged pull requests where you know the history.
Keep your existing scanners running while you do. A bot that finds things your static analysis misses is useful. A bot that quietly replaces it is a risk until you’ve measured the difference yourself.