Cursor's security review system identifies over 200 vulnerabilities weekly across 3,000+ internal pull requests. This isn't a security incident; it's a testament to effective automation. It highlights a common pitfall where many security automation initiatives fail.
The system succeeds because Cursor prioritized infrastructure over prompts. Most teams do the opposite and then wonder why their AI security tools yield inconsistent results.
How Cursor's System Operates
Cursor implemented an automated security review system for every internal pull request. The architecture includes:
- A custom Model Context Protocol (MCP) server that standardizes AI agents' access to security context
- Terraform-managed deployment pipelines ensuring consistent execution
- Integration with deterministic tools like Snyk for known vulnerability patterns
- Simple prompts (about 15 lines) guiding AI review agents
The system doesn't replace human security engineers. It triages the 3,000 weekly PRs and highlights the 200+ that need human attention.
Why This Matters for Your Team
Many security teams approach AI automation incorrectly. They create elaborate prompts, use them with AI models like ChatGPT, and get inconsistent results. The issue isn't the AI; it's using prompts in isolation.
Cursor's approach shows three infrastructure elements that make simple prompts effective:
Consistent execution environment. The Terraform-managed pipeline ensures every PR is reviewed under identical conditions. Same tool versions, context structure, and timeout limits. Running prompts manually or through ad-hoc scripts introduces variables that skew results.
Standardized context delivery. The custom MCP server ensures AI agents receive security context predictably. It's not about more data, but the right data delivered consistently. Simple prompts work when your context structure is reliable.
Deterministic and probabilistic layering. Snyk integration catches known CVEs and dependency issues with zero false positives. The AI layer addresses novel patterns and context-specific risks that signature-based tools miss. Both are necessary but serve different functions.
Controls That Support This Architecture
If you're building similar automation, align your infrastructure decisions with these control families:
PCI DSS v4.0.1 Requirement 6.3.2 mandates identifying and addressing security vulnerabilities. While it doesn't specify methods, it requires a defined process. Cursor's infrastructure creates that process, automated review triggers on every PR, results are logged, and exceptions need human sign-off.
ISO/IEC 27001:2022 Control 8.25 (secure development lifecycle) requires integrating security throughout development. Manual reviews don't scale to 3,000 PRs weekly. Automated infrastructure does, but only if it's built for consistency.
NIST 800-53 Rev 5 SA-11 (developer testing and evaluation) requires security testing during development. The control is effective when testing is automated and reliable. Ad-hoc prompt engineering doesn't meet this standard.
The Role of Human Judgment
Cursor's system flags 200+ vulnerabilities weekly for human review. This number is crucial, the AI doesn't auto-fix issues or make final security decisions.
Here's why this is important for your implementation:
AI agents excel at pattern recognition across large codebases. They'll identify issues like concatenating user input into SQL queries or missing authentication on an API endpoint. However, they struggle with business context. Is the API endpoint internal-only? Is the SQL query safe due to input validation elsewhere?
Your security engineers make these decisions. The infrastructure ensures they're focusing on the 200 PRs that matter, not manually reviewing all 3,000.
This aligns with SOC 2 Type II CC6.1 (logical access controls), which requires human authorization for security decisions. You can automate detection, but your audit trail must show human authorization for responses.
Action Items for Your Team
If you're building AI-augmented security review:
Start with deployment infrastructure. Before writing a single prompt, build a pipeline for consistent execution. Use Terraform, GitHub Actions, or similar tools for reproducible environments. Test that your pipeline runs the same way every time, regardless of who triggers it or when.
Define your context structure. Document the exact information your AI agents need and its format. Build tools that deliver this context reliably. For PR reviews, this might include changed files, dependency updates, API endpoints touched, and authentication patterns. Use a structured data format, not free text.
Layer deterministic tools first. Run Snyk, Semgrep, or similar tools before AI review. Let them catch known patterns. Your AI prompts should focus on novel risks and context-specific issues that signatures miss.
Keep prompts simple. If your prompt exceeds 20 lines, you're compensating for infrastructure issues. A well-structured context lets you write prompts like "Review these changes for authentication bypass risks" rather than detailed instructions.
Log everything. Your infrastructure should capture which PRs were reviewed, what the AI flagged, what humans decided, and why. This isn't just for audits; it's how you improve your prompts and context structure over time.
Test failure modes. What happens if your MCP server is down, the AI service times out, or a PR is too large to review? Your infrastructure must handle these cases gracefully, not skip PRs or overwhelm your security team with false alerts.
Building the infrastructure that supports simple prompts isn't glamorous. It won't make a flashy demo. But it's what separates security automation that catches 200 vulnerabilities weekly from automation that your team disables after two weeks of alert fatigue.
Focus on building the foundational parts first. The AI will perform better when you do.
