Can AI Code Review Catch Security Vulnerabilities?

The question security teams actually ask

When an engineering team proposes AI code review, the security team asks a version of the same question every time: will this catch vulnerabilities, or will it just reword our lint output? It is the right question, and the honest answer is more interesting than either camp expects. AI review catches a meaningful class of security bugs that traditional tooling misses — and misses a class that no reviewer working from a pull request can see. Knowing which is which is the difference between adding a real security layer and adding a false sense of one.

What AI review is genuinely good at

An LLM reviewer reads code the way a security-literate human does: semantically. It does not match patterns against a rule database; it follows what the code means. That makes it strong on exactly the findings that rule-based scanners fumble:

• Injection in context. A scanner flags string concatenation near a SQL call. An AI reviewer can notice that the concatenated value arrives from a request parameter three functions up in the same diff, that it skips the sanitizer used everywhere else in the file, and that the fix is the parameterized helper the codebase already has — and say all of that in one comment.
• Authorization gaps in the change. The new endpoint mirrors an existing one but drops the ownership check. No rule fires on missing code, because rules match what is present. A semantic reviewer comparing the new handler to its siblings can flag what is absent.
• Dangerous defaults and misused APIs. Disabled certificate verification, weak hash choices for passwords, permissive CORS, secrets committed in config, deserialization of untrusted input — the classic grep-able offenses, but reported with an explanation of why they matter in this specific code path, which is what convinces an author to actually fix them.
• Logic that contradicts its intent. A rate limiter that resets on the wrong key, a token check that runs after the side effect, a redirect validator that validates the wrong URL. These are semantic bugs with security consequences, invisible to pattern matching by construction.

The common thread: everything above is visible in or near the diff. AI review is a reviewer, and its evidence is the pull request in front of it, plus whatever context the system retrieves around it.

What it will miss — and why the boundary matters

Every failure mode of AI security review follows from the same constraint. Some vulnerabilities do not live in any diff:

• Architecture-level flaws. A missing trust boundary between services, an internal API that was never meant to be reachable from the internet, a tenant-isolation model with a hole in it. No pull request contains these; they exist between pull requests.
• Deep business-logic authorization. Whether a refund flow should allow the requesting role depends on product rules no reviewer can infer from code alone — human or machine.
• Supply chain and runtime reality. A vulnerable transitive dependency, a misconfigured bucket, a leaked credential already in the wild. Different tools own these: dependency scanners, infrastructure audits, secret rotation.
• The novel and the adversarial. A reviewer that reasons from known vulnerability classes will not reliably invent a brand-new exploit chain, and a determined insider writing deliberately deceptive code is a threat model for humans and audit, not for PR review.

None of this is an argument against AI review. It is an argument for placing it correctly: as the semantic layer of a defense-in-depth stack, next to — not instead of — dependency scanning, secret detection, SAST for compliance-mandated rule coverage, and human review for design.

Making the security layer actually effective

Teams that get real security value from AI review configure it deliberately. Four practices do most of the work:

• Separate severity from style. A security finding buried under fourteen naming suggestions is a security finding nobody reads. Severity classification — and muting the low tiers on noisy repos — is what keeps the one comment that matters visible. Our rollout playbook covers the tuning sequence.
• Spend where the risk is. Route your strongest models to the paths that deserve them — auth, payments, anything handling user data — and cheaper models to the rest. With per-repository budgets, the spend follows the risk profile instead of the commit volume.
• Ask for security explicitly. Generic review prompts produce generic reviews. Review instructions that name the threat categories you care about — injection, authz, secrets, unsafe deserialization — measurably sharpen what comes back.
• Track acted-on findings. The metric that matters is not findings posted but findings fixed before merge. If security comments are not being acted on, you have a noise problem or a trust problem, and your metrics should surface it.

The question behind the question

There is an irony in sending your code to a third-party cloud service to check it for security vulnerabilities. For teams in regulated environments — and for any security team that has read its own data-handling policy — the reviewer's deployment model is itself a security finding. A cloud reviewer means your unmerged diffs, including the vulnerable ones, transit and rest on infrastructure you do not control.

This is why security-conscious teams gravitate to self-hosted AI code review: the review engine runs inside your perimeter, code never leaves your infrastructure, and with bring-your-own-key inference the model calls run under your provider agreements, your data-processing terms, and your audit trail. PURA was built for exactly this posture — the semantic security layer, deployed like the security-sensitive tool it is.

So: can AI code review catch security vulnerabilities? Yes — a specific, valuable class of them, more readably than any scanner, on every pull request, without fatigue. Just be precise about the boundary. The teams that treat AI review as one strong layer in a stack get safer code. The teams that treat it as the security strategy get surprised.