Using AI for Secure Code Review: A Workflow That Holds Up

TL;DR - AI security review went from a novelty to something you can put in CI this week. Used well, it reads intent the way a senior reviewer does and catches the authorization and logic flaws pattern scanners miss. Used badly, it hands you confident, wrong findings and a false sense of safety.

• Turn on the built-in review. The major assistants (Claude, Copilot, Snyk) now ship a security review you run as a command or a pull-request check. It flags injection, broken authorization, secrets, weak crypto, and dependency risks, then proposes patches.
• Keep a deterministic scanner next to it. SAST asks “does this match a bad pattern?” The AI asks “is this bug real, reachable, and worth fixing?” You want both questions answered.
• Trust the loop, not the model. The workflow that holds up finds, tries to disprove its own finding, patches, re-scans, and escalates to a human when confidence is low. Nothing lands unread.

This is a first pass at expert level and at machine scale. It is not a replacement for the expert.

The thing that actually changed

A companion post made the case that AI writes insecure code at a rate independent testing puts near half, and that the same technology is good at catching those flaws. That was the argument. This is the setup.

What changed in 2026 is that you no longer have to build the review harness yourself. The major assistants now ship AI security review as a feature: it scans a codebase for vulnerabilities and suggests targeted patches, usually as both a command you run locally and a pull-request check you drop into CI. GitHub’s Copilot Autofix does it on top of CodeQL, Snyk Code does it, and Claude has a built-in security review with an official pull-request action from Anthropic (plus audit skills from security firms like Trail of Bits and a loud ecosystem of community skill packs). This post uses Claude’s as the running example because it is the one I reach for, but the workflow below is tool-agnostic. The raw capability is no longer the hard part.

The hard part is using it so that it makes you safer instead of just making you feel safer. That is what the rest of this is about, and it is written from the seat of someone who ships code and audits it, not from a list of tools.

Why AI review and a scanner, not either alone

The instinct is to pick one. Do not. They answer different questions, and a real pipeline wants both answered.

A traditional static analyzer (Semgrep, CodeQL, Snyk Code) traces tainted input from source to sink across files. It is deterministic, repeatable, and it enforces policy: the same code always produces the same finding, and you can fail a build on it. That is your coverage floor. It is also literal. It matches patterns, so it floods you with style nits and misses the flaw that only makes sense if you know what the endpoint is for.

An AI reviewer reads intent. Point it at a diff and it will flag the missing tenant check that a pattern scanner walks straight past, because it understands that an invoice belongs to a customer even though nothing in the syntax says so. It reasons about whether a bug is reachable. It writes an explanation a human can act on. That is the judgment layer.

Keep the scanner as the guardrail that catches the obvious and enforces the rule. Add the AI as the reviewer that argues about what actually matters. Neither one alone is a security program.

The workflow that holds up

The naive version, “ask the model if my code is secure and apply what it says,” is worse than no review, because it launders guesses into confidence. The version that holds up looks like a careful reviewer working a queue:

1. Find. The AI review runs over the diff (or the whole repo for a baseline) and produces findings with severity and a proposed fix.
2. Disprove. Each finding gets re-examined to prove or disprove it, and low-impact classes (denial of service, generic input validation with no shown impact, open redirects) get filtered out. This false-positive pass is the difference between a tool people use and one they mute.
3. Patch and re-scan. For a surviving finding, apply the patch, then re-run the deterministic scanner. If the finding is gone, good. If it persists, try one revised patch.
4. Escalate. If confidence stays low after that, do not guess. Mark it “manual review required” and leave it for a person. False confidence is the failure mode you are engineering against.
5. Human approves. Nothing merges on the model’s say-so. It proposes, a person decides.

That escalation step is the whole game. A reviewer that says “I am not sure, look at this yourself” is worth ten that confidently patch the wrong line.

Wiring it into CI

For a small team, the useful shape is a pull-request check plus the cheap deterministic gates around it. Here is the AI review as a GitHub Action on every pull request:

name: Security Review
on: [pull_request]

permissions:
  contents: read
  pull-requests: write

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2
      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Then keep the deterministic gates from the companion post alongside it, cheapest first: a secret scan before the commit lands, your SAST failing the build on high-severity findings, and a dependency and package scan so a hallucinated or vulnerable library never reaches your build file. In a Gradle project that dependency gate is one plugin:

// build.gradle - fail the build on known-vulnerable dependencies
plugins {
    id 'org.owasp.dependencycheck' version '10.0.4'
}
// then: ./gradlew dependencyCheckAnalyze

The AI review is the judgment layer on top of those gates, not a substitute for them.

About those “Claude security skills”

Search for this and you drown in listicles and near-identical repositories: dozens of packs all named some variant of “claude security skills,” a few with big star counts, most thin. A skill is just a folder of instructions and scripts that teaches the agent a repeatable procedure (a dependency audit, a threat-modeling pass, a hardening checklist), so a strong one encodes real expertise you would otherwise re-type every session. The gap between a strong one and filler is wide.

First, calibrate what “official” means. Anthropic’s public skills are general-purpose (document handling, building integrations), not a security pack. The official security capability is the built-in review itself, not a skill you install from a third party. So do not read “there is an Anthropic skills repository” as “Anthropic vouches for this security skill.” It almost certainly does not.

Then the part the listicles skip, and it is the same warning the companion post made about AI-suggested packages. A skill runs instructions and code with whatever access your agent has. A hostile or sloppy skill can exfiltrate data or run commands that have nothing to do with its stated job. So:

• Use skills from sources you trust: ones you wrote, the built-in review Anthropic ships, or a known security firm. Trail of Bits, for example, publishes audit skills (things like constant-time analysis and reviewing agent actions) from a firm that audits code for a living. That is a different risk tier than an anonymous pack with a big star count.
• Read the instruction file before you install it. It is plain text. Five minutes of reading catches most surprises.
• Remember the reviewer itself is not hardened against prompt injection. The official action says as much: run it on trusted pull requests, not on code an anonymous outsider just pushed, because a malicious diff can carry instructions aimed at the reviewer.

The tooling that finds your vulnerabilities is software too, and it has an attack surface. Treat it that way.

Where it still needs you

Four places the AI review will let you down if you let it, and where a human still earns their seat:

• Reach across the codebase. A flaw that only exists because module A trusts what module B validated is easy to miss when the reviewer is looking at one diff. Deterministic dataflow analysis and a human who knows the system cover this.
• Business logic that only you understand. “This refund path should never run for a suspended account” is not something a general reviewer can know. It knows code, not your rules.
• Confident nonsense. It will occasionally cite a fake CVE, warn about a non-issue, or propose a patch that quietly changes behavior. The disprove-and- re-scan loop exists precisely because you cannot take findings at face value.
• The final call. It proposes, you decide. On anything that touches auth, money, or customer data, a person signs off.

Used this way, AI review is a senior reviewer who never gets tired and reads every line of every pull request, and who is occasionally, confidently wrong. That is an enormous amount of leverage, as long as you keep the loop and keep a human at the end.

Summary

The capability is here and cheap to adopt: a built-in security review that scans your code and proposes patches, runnable as a command or a pull-request check. Make it useful by pairing it with a deterministic scanner (pattern coverage plus intent), by running the find-disprove-patch-rescan-escalate loop instead of blindly applying fixes, by treating security skills as trusted-source-only code with an attack surface, and by keeping a human on every merge that matters. It is an expert-level first pass at machine scale. Aimed at your own code, before an attacker aims their version at it.

That is the code. The cloud and identity setup it runs in is a separate audit with the same shape: auditing your cloud and identity setup with AI.

---

Want this workflow set up in your pipeline, or a real audit of what your AI-written code is exposing? That is the hands-on half of Security & Compliance. Book a free 30-minute call and we will wire the review in and read the first report together.