There is a particular kind of pull request that makes AppSec teams tired before they even open it.
It is not the obvious monster. It is the normal-looking one: 400 lines, three services, a migration, a new helper, a test that proves the happy path, and a description that says “small auth cleanup.” Somewhere inside it, a permission check moved two functions later than it should have.
That is the job AI code review should be hired to do.
Not approval. Triage.
What is AI code review?
AI code review is the use of language models and repository context to inspect code changes, explain risk, and surface issues before merge. In an AppSec workflow, the useful output is not “approved” or “rejected.” It is a short, evidence-backed brief that tells the right human where to look.
For AppSec teams, that distinction is everything. Security review has a judgment problem, not just a coverage problem. A scanner can say, “this pattern resembles a vulnerability.” A developer can say, “the tests pass.” A security reviewer has to answer the harder question: does this change alter the risk of the system we actually run?
AI can help prepare that decision. It should not silently make it.
A good AI review looks like a risk brief
Imagine a pull request that adds a customer export endpoint.
A bad AI review comments: “Ensure authorization is implemented correctly.”
A useful AI review says:
Change observed: This PR adds GET /projects/:id/export and reuses an internal export service.
Why it matters: Similar export endpoints call requireProjectOwner() before reading records. This route loads project data first, then checks membership later.
Evidence: The new handler reads by project ID on line 42. The closest existing endpoint performs ownership validation before the query. The test only covers the owner success case.
Suggested next step: Move the ownership check before the data read and add a wrong-tenant test.
That is the shape AppSec teams should want: changed code, local precedent, security concern, evidence, and next action. It is specific enough for a developer to fix and compact enough for a reviewer to trust or challenge.
AI code review vs. SAST vs. secure code review
These terms get blurred, but they solve different problems.
SAST is broad, repeatable static analysis. It is good for known patterns and consistent rules.
Secure code review is human or human-guided inspection of code for security properties: authorization, data handling, abuse cases, trust boundaries, and business logic.
AI code review sits between them. It can read a pull request, compare it to surrounding code, summarize the risk, and route the change. It is strongest when the task is contextual but bounded.
The best AppSec programs use all three. SAST catches repeatable patterns. AI review compresses context. Humans own policy and judgment.
What to automate
Start with the parts of review that are high-volume and evidence-based.
Automate detection of pull requests that touch security-sensitive areas: auth flows, role checks, billing logic, admin surfaces, dependency files, infrastructure, customer exports, audit paths, AI prompts, and logs.
Automate the first summary: what changed, which controls are nearby, what similar code does, what tests are missing, and who likely owns the risk.
Automate low-friction developer feedback when confidence is high. If the issue is concrete and local, comment in the pull request with the evidence.
Automate routing when the question is ambiguous. If the decision depends on policy, customer commitments, architecture, or risk acceptance, send it to the human who owns that decision.
What should stay human
Keep humans in charge of decisions that depend on business context.
A model should not decide whether a support role is allowed to see a field because a large customer negotiated a special workflow. It should not decide whether a compensating control satisfies a compliance promise. It should not approve a new trust boundary because the generated explanation sounds reasonable.
AI review is a leverage layer. It is not the policy owner.
The fastest way to ruin AI code review is to let it cosplay as governance.
How to evaluate AI code review tools
If you are buying or building an AI code review workflow, ask for evidence instead of adjectives.
Can it read the surrounding code, not just the diff? Can it compare a change to local conventions? Can it distinguish a risky pull request from a noisy one? Can it explain a concern in the language of your repository? Can it route findings without blocking every merge? Can AppSec tune the workflow when developers mark a finding wrong?
Most importantly: can it produce a risk brief that a busy security reviewer would actually use?
That is the bar.
Questions AppSec teams ask
Can AI code review approve pull requests?
It can technically produce an approval-like answer. AppSec teams should avoid that pattern for security-sensitive changes. Use AI to prepare the decision; keep approval accountable to humans and existing ownership.
What should AI code review catch?
The highest-value targets are contextual risks: changed authorization paths, sensitive data movement, dependency changes, unusual framework patterns, missing abuse-case tests, and code that bypasses local guardrails.
Is AI code review a replacement for SAST?
No. SAST and AI code review are complementary. SAST is repeatable and rule-driven. AI review is useful for pull request context, explanation, and routing.
Where should teams start?
Start with one or two repositories and only the sensitive paths that already create review pain. Do not begin by commenting on every pull request. Earn trust with useful briefs first.
Spend human attention where it matters
For teams shipping with AI assistants, the gap between code volume and review capacity will keep widening. The answer is not to pretend every line can get the same human attention. The answer is to make human attention less random.
The companion piece, Secure Code Review Checklist for AI-Generated Pull Requests, turns this into a tactical review flow. If you want to see how Enclave thinks about pre-merge security evidence, request a demo.
Let the model shovel. Keep the judgment human.