Cursor Security Review Four Weeks In: What An AI Pull Request Reviewer Can And Cannot Evidence For SOC 2, ISO 27001 And PCI DSS

On 23 September 2026 Cursor launched two bots for Teams and Enterprise customers, Rollouts and Security Review. Security Review reads each pull request in the context of the wider codebase and posts a single review comment listing exploitable bugs, each with a severity, an attack path and a proposed fix. Cursor is explicit that style and quality stay with Bugbot, its existing reviewer, so Security Review is positioned as a dedicated security control rather than a general code quality tool. Four weeks in, enough teams have switched it on that the compliance question has arrived: what does it actually count for in a SOC 2, ISO 27001 or PCI DSS assessment?

Start with what it checks, because the scope is fixed and published. According to the changelog, Security Review looks for SQL, command and template injection, authentication and authorisation bypasses including refactors that quietly stop a check from running, secrets committed to source, server side request forgery, unvalidated redirects, unsafe deserialisation, and dependency changes that introduce known vulnerabilities. That is a sensible list and it overlaps heavily with the OWASP categories most assessors expect a secure development process to address. It is also a list, which means anything outside it, such as business logic flaws, cryptographic misuse, insecure data retention or privacy defects, is not covered and still needs a human reviewer or another tool.

The most important design detail for auditors is that Security Review comments rather than blocks. The launch post describes one review comment per pull request and does not describe a merge gate, and draft pull requests are skipped entirely. Developers can dismiss a finding with a reason, after which it is not raised again on that pull request. None of that is a criticism, since most good security tooling starts as advisory, but it means the control is only as strong as the branch protection and approval rules you wrap around it. If your SOC 2 change management narrative under CC8.1 says that security issues are resolved before merge, you need a required status check or a reviewer obligation that makes that true, not a bot comment that can be scrolled past.

The dismissal reason is the part to design deliberately. In ISO 27001 terms this is evidence for Annex A 8.25 secure development life cycle, 8.28 secure coding and 8.29 security testing in development and acceptance, and an assessor will want to see that exceptions are justified and reviewed. A free text reason typed by the same developer who wrote the code is weak evidence on its own. Decide in advance who may dismiss a high or critical finding, whether a second approver is needed, and how often someone samples dismissals to confirm the reasons hold up. That sampling record is exactly the kind of artefact that turns an AI tool into a defensible control.

For PCI DSS v4.0.1, Requirement 6.2.3 asks that bespoke and custom software is reviewed before release to identify and correct potential coding vulnerabilities, and 6.2.3.1 allows manual review only when the reviewer is someone other than the author and knowledgeable in secure coding. An automated reviewer can support 6.2.3, and 6.2.4 asks for techniques that prevent or mitigate common attacks, which the published bug classes map onto well. What it does not do is replace the documented process, the independence requirement for manual review, or the evidence that findings were corrected before release. Keep a human approver on any change touching the cardholder data environment and treat the bot output as one input to that approval.

Team rules are the most underrated feature. Cursor lets you write codebase specific policies, such as requiring a particular wrapper for every outbound HTTP call, and Security Review enforces them on every pull request. That is a direct way to turn a secure coding standard into a tested rule, and it gives you something better than a policy document to show an auditor. Keep the rules in version control or export them on a schedule, because a policy that lives only in a vendor dashboard is hard to evidence and easy to change without anyone noticing.

There are also vendor management questions to answer before you lean on it. The launch post says nothing about how pull request content is processed or retained, or whether findings and dismissals appear in an exportable audit log. Read Cursor’s current data processing terms and trust documentation, confirm whether privacy mode and your Enterprise data commitments apply to the review bots as well as the editor, and record the result in your vendor register. If findings cannot be exported, plan to capture them from the pull request history in GitHub or Origin, which your compliance platform may already collect.

The compliance platforms will see this tool through the source control integration rather than directly. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof typically test branch protection, required reviews and approval counts on GitHub, so the strongest pattern is to make Security Review a required check and let the existing integration evidence that it ran and passed. Rollouts, the companion bot, deserves a separate note: it writes a monitoring plan for each change and reports healthy, regression or inconclusive per environment, but it does not roll back on its own, so it supports monitoring and incident detection rather than replacing your rollback procedure.

A short plan for the next sprint. Enable Security Review on the repositories in audit scope, not just the ones that are convenient. Make it a required check where your branch protection allows it, and stop skipping drafts from becoming a bypass by requiring the check on the final pull request. Write a dismissal policy with named approvers for high and critical findings and a monthly sample review. Move secure coding rules into team rules and keep a copy under version control. Finally, update your SOC 2 and ISO 27001 control narratives to describe the bot as a supporting automated control, with human review still accountable for the merge decision.