Can an AI Model Do a Real Security Review of My Code?

Yes, an AI model can do a real security review of part of your code, and it now finds bugs that people and scanners miss. It is not yet a complete review. Trust a finding only when it comes with a reproduction you can run, and trust a fix only when a test fails before it and passes after it.

Below: which bug classes AI review handles well and badly, how to measure it on your own code, why refusals get in the way, where your code goes, how to verify findings and fixes, how it fits next to other testing, and how to keep an audit trail. For headline zero day claims, read how to evaluate claims that AI finds zero day vulnerabilities; for the statistics, read precision vs recall for an AI security reviewer.

Key takeaways

• AI review is good at local, readable flaws such as injection, unsafe deserialization and logic slips in one file. It is weak at authorization design, business rules across services and anything that depends on runtime state.
• Measure it on your own code with a seeded test set, and run each review more than once, because results vary between runs.
• Labs treat security as dual use, so models may block exploit validation or malware analysis. Verification programs lower those blocks for vetted defenders, with conditions.
• Where your code goes depends on the plan, not the model. Commercial terms at both major labs say no training by default, with zero data retention for approved customers. Self hosted models keep code in your network but move the work to you.
• A finding is real when it has a proof that runs. A fix is real when the proof fails on the old code, passes on the new code, and fails again if you revert the patch. Trail of Bits calls this a three arm proof.
• AI review adds to static analysis, dependency scanning and penetration testing. It replaces none of them.
• Keep the evidence: configuration, model version, finding, human decision, test and merged change. NIST SSDF asks for this record.

Why this question is everywhere right now

In October 2026 an Ask HN post asked which frontier model can do code security reviews close to a professional audit. The poster said one assistant refused penetration testing style work. Replies argued about refusals, open weight models on an air gapped machine, and trusting a hosted provider with sensitive code (Ask HN thread).

A few days later, a maintainer of a Go networking library posted that one lab's open source scanning effort had reported 36 bugs in the library, including six security vulnerabilities, some more than four years old, and three issues that another lab's internal review of a new API had missed (Tell HN thread). In the comments, people said assistants refused to help verify the reports, one argued each fix needs a test that fails before and passes after, and the maintainer said manual review took a whole day.

On 21 October, Trail of Bits published Your AI agent fixed the bug, but what else did it change?. The authors reviewed more than 130 patches their engineers had landed upstream through Patch the Planet, a joint initiative with OpenAI, and confirmed 21 regressions: 16 functional, 1 performance and 4 build or test. None broke a security protection, but each broke behavior that used to work. Their first automated pass produced 58 candidates for those 21 real regressions, about 36 percent precision, which they described as too noisy.

The same day, an Ask HN post from someone new to security described an AI platform that labeled an issue critical and proposed a fix. A second model disagreed, and the issue turned out not to be a bug at all. In the poster's words, "My trust in the platform immediately degraded" (Ask HN thread).

Nobody in these threads doubts that models find bugs. They want to know which results to believe, what checking costs, and what happens to their code.

What AI review finds well, and what it finds badly

Models read code as text with meaning, not as fixed rules. That is why they catch things pattern based tools miss, and miss things a careful human would catch.

Where AI review is strong

Injection and unsafe data flow inside a readable path. When user input reaches a SQL query, a shell command, a template or a file path within a few function calls, a model can usually follow it and explain the risk in plain words. Anthropic's open source security review action lists injection (SQL, command, LDAP, XPath, NoSQL, XXE), cross site scripting, unsafe deserialization and eval style code execution among the categories it checks (anthropics/claude-code-security-review).

Logic slips inside one function or file. Inverted conditions, a missing early return after a failed check, an off by one in a bounds check. Hard to express as rules, easy for a model to notice.

Weak cryptography and insecure defaults. Weak algorithms, predictable randomness, permissive CORS and debug settings left on.

Explaining why something is a bug. A good finding traces the value from source to sink, which speeds triage even when the finding is wrong.

Protocol and state machine bugs, sometimes. The Go library report included an authentication issue, a deadlock and a TLS key update bug, findings rule based tools rarely produce.

Where AI review is weak

Authorization design. A model can spot an endpoint with no permission check. It usually cannot tell you the permission model itself is wrong, such as tenant isolation that depends on a header a proxy can set. That evidence lives in threat models and people's heads, not the diff.

Business logic across services. A refund flow safe in service A and safe in service B can be unsafe with a retry queue between them. A reviewer that sees one pull request cannot see the race, and the Anthropic action only analyzes changed files on a pull request.

Anything that depends on runtime state. Feature flags, environment variables, the library version that actually ships in the container. The model sees source, not the deployment.

Bug classes the tool filters out on purpose. This is the one most teams miss. To keep noise down, the Anthropic action filters out denial of service, rate limiting, memory and CPU exhaustion, generic input validation without proven impact, and open redirects by default. The filter is configurable, but a quiet review is not evidence those classes are absent. Read your tool's exclusion list.

Consistency. Run the same review twice and you may get different findings. Trail of Bits built their tooling around strict schemas and a live proof for every claim for this reason.

A quick map

How to measure precision and recall on your own code

Vendor benchmarks measure someone else's code. Measuring yours needs only a seeded test set, an answer key and a scoring script.

The idea is old. The OWASP Benchmark is a runnable Java and Python application whose deliberately included vulnerabilities are meant to be real and exploitable, so that tools can be scored against a known answer key. NIST's Juliet test suite for C and C++ has 64,099 test cases across 118 CWEs, built from paired bad and good variants of the same code.

Precision is the share of reported findings that are real; low precision erodes trust. Recall is the share of real bugs found; low recall gives false comfort. Stability is how much results change between runs, which matters as much for a model.

Step by step: a seeded evaluation in an afternoon

1. Pick two or three real repositories that look like what you ship.

2. Create an evaluation branch and seed bugs. Have one engineer, not the person running the evaluation, add between 15 and 30 small flaws. Mix easy and hard: a query built with string formatting, a removed permission check, a path join without normalization, a race between check and use. Add as many decoys, code that looks risky but is safe. Decoys measure false positives.

git switch -c eval/seeded-2026-10
# engineer adds seeded flaws and decoys, then:
git commit -am "eval: seeded flaws and decoys (do not merge)"
git push -u origin eval/seeded-2026-10

3. Write the answer key. Keep it outside the repository the reviewer can see, so it cannot read the answers.

# answer-key.yaml (stored outside the repo under test)
- id: S01
  file: api/orders.py
  line: 88
  cwe: CWE-89
  real: true
- id: S02
  file: api/admin.py
  line: 41
  cwe: CWE-862
  real: true
- id: D01
  file: api/search.py
  line: 30
  cwe: CWE-89
  real: false   # decoy: parameterized, looks unsafe

4. Run the reviewer the way you will use it, on a pull request or in the terminal, and export findings as JSON. The Anthropic action, for example, uploads a results file as a build artifact.

5. Run it at least three times. Same diff, same configuration, fresh runs. Keep every run.

6. Score it. A short script is enough.

# score.py: compare tool findings with the answer key
import json, sys, yaml

key = yaml.safe_load(open(sys.argv[1]))
runs = [json.load(open(p)) for p in sys.argv[2:]]

def matches(f, k, slack=5):
    return f["file"] == k["file"] and abs(f["line"] - k["line"]) <= slack

real = [k for k in key if k["real"]]
for i, findings in enumerate(runs, 1):
    tp = {k["id"] for k in real for f in findings if matches(f, k)}
    fp = [f for f in findings if not any(matches(f, k) for k in real)]
    precision = len(tp) / max(len(tp) + len(fp), 1)
    recall = len(tp) / max(len(real), 1)
    print(f"run {i}: precision={precision:.2f} recall={recall:.2f} "
          f"found={sorted(tp)} false_positives={len(fp)}")

python3 score.py answer-key.yaml run1.json run2.json run3.json

7. Read the misses, not just the numbers. If every miss is an authorization or cross file issue, that is where you still need people. A decoy flagged on every run is a rule for the tool's false positive instructions.

8. Repeat after any change to model version, prompt or filter file. Treat the reviewer like a dependency: pinned and retested on upgrade.

One limit: seeded bugs are usually easier than organic ones, and a model may have seen public benchmark code in training. Write fresh seeds in your own code.

Why refusals and safety filters affect security work

Security knowledge is dual use: the reasoning that finds a flaw also writes the exploit, and every lab's line sometimes cuts through defensive work. Anthropic's Cyber Verification Program page, updated October 2026, says generally available models remain open to all users for tasks such as secure code review, threat modeling, patching known issues and triaging alerts, while safety classifiers may interrupt work such as malware analysis or exploit validation. The program gives qualifying security professionals reduced blocking. It now has three tiers, Defense, Red Team and Specialized, and individuals can apply only for Defense. Anthropic aims to answer within seven business days, and approved users can still hit blocks outside their tier or workspace.

The same page says the program requires data retention so Anthropic can monitor for cyber misuse, with limited exceptions it describes. Defense Access participants have until 15 December 2026 to adopt phishing resistant multi factor authentication and stop using API keys, and until then their API keys expire every seven days.

OpenAI runs a comparable program, Trusted Access for Cyber, which its announcement describes as identity verification to reduce safeguard friction for defenders, with added tiers. Check OpenAI's current terms before planning around it.

What this means in practice:

• Code review itself is rarely blocked. Teams hit walls at the next step: a working proof of concept, reproducing memory corruption, analyzing a malicious package.
• Verification gets the least help. In the Go library thread, assistants refused to help confirm reports. Plan for a human led step, an approved program, or a deterministic tool.
• Programs trade friction for retention and identity. If your policy requires zero data retention for source code, read the conditions before you apply.
• Open weight models move the line, not the work. You avoid hosted classifiers but own the hardware, evaluation, patching and access control.

Where your code goes when an AI reviews it

The answer depends more on your plan and deployment than on the model. Here is what the labs' own documentation says.

Hosted models: what the docs say

Anthropic, for Claude Code. The data usage page separates consumer and commercial accounts. On commercial terms (Team, Enterprise, API, third party platforms and Claude Gov), Anthropic does not train generative models on code or prompts sent to Claude Code unless the customer opts in, for example through the Development Partner Program. Standard commercial retention is 30 days. Zero data retention is available to qualified accounts for Claude Code on Claude for Enterprise, enabled per organization by the account team. Consumer accounts that allow data use for model improvement have five year retention; others have 30 days.

Two details surprise people. The client keeps session transcripts locally in plaintext under ~/.claude/projects/ for 30 days by default, adjustable with cleanupPeriodDays. And a transcript sent with /feedback, /bug or /share is retained for five years. Through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry, metrics, error reports and feedback reports are off by default.

OpenAI, for the API. OpenAI's data controls guide says data sent to the API is not used to train or improve OpenAI models unless you explicitly opt in. Abuse monitoring logs are kept for up to 30 days by default. Approved customers can use Zero Data Retention or Modified Abuse Monitoring, with exceptions the guide lists. Data residency is a per project setting that needs sales approval.

Cloud sessions. When an agent runs in the provider's cloud, your repository is cloned into a managed VM. Anthropic's security page says each cloud session runs in an isolated VM, GitHub credentials never enter it, network access is limited by default, and all operations are logged for audit.

Self hosted and local options

Open weight models on your own hardware. Code never leaves your network. You take on capacity, evaluation, upgrades and the security of the inference server; an unauthenticated model server is a new attack surface.

A local runner. Some platforms, including Safeguard, scan on your machine and send back only results.

No model at all for the parts that do not need one. Dependency inventory, vulnerability matching against databases, license checks and policy gates can run deterministically.

Decision table: where should the review run?

How to verify a finding before filing it

An AI finding is a hypothesis. Turn it into evidence before it becomes a ticket or an upstream report. Trail of Bits states the standard: "Every conclusion depends on a PoC run against a live deployment." In their regression tooling, if a step cannot produce a live proof, its result is inconclusive. A fresh agent replays the proof, and a final step rules out false positives and bugs that predate the change. For each finding:

1. Read the path yourself, from the claimed source to the claimed sink.
2. Check reachability. Is the function called from a route, job or entry point a real user or attacker can reach?
3. Write a failing test, not an exploit. A test showing an endpoint returning another tenant's record is enough. Keep weaponized payloads out of your repository.
4. Get an independent second opinion: a fresh session, another reviewer or a deterministic tool.
5. Record the decision: real, not real, or cannot tell.

Maintainers receiving AI generated reports can ask for the failing test. It is the fastest filter.

How to verify a fix before merging it

Fixes carry a risk findings do not: they change behavior. A patch can close the bug and quietly break something else.

The three arm proof

Trail of Bits requires that the reproduction fails on the original code, passes on the patched code, and fails again when the patch is fully reverted. The third arm proves the patch, not an unrelated change, fixed the bug. With git and pytest (swap in npm test, go test or mvn test):

# The fix branch holds the new regression test and, in its own commit, the patch.
TEST=tests/test_orders_injection.py
BR=fix/orders-sql-injection
PATCH=$(git log -1 --format=%H --grep='^fix:' "$BR")   # the commit with the patch

# Arm 1: original code plus the new test. The test must FAIL.
git worktree add --detach /tmp/arm1 origin/main
git -C /tmp/arm1 checkout "$BR" -- "$TEST"
(cd /tmp/arm1 && pytest "$TEST") && echo "ARM 1 FAILED: the test does not reproduce the bug"

# Arm 2: the patched branch. The test must PASS.
git worktree add --detach /tmp/arm2 "$BR"
(cd /tmp/arm2 && pytest "$TEST") || echo "ARM 2 FAILED: the fix does not work"

# Arm 3: the patched branch with only the patch reverted. The test must FAIL again.
git worktree add --detach /tmp/arm3 "$BR"
git -C /tmp/arm3 revert --no-edit "$PATCH"
(cd /tmp/arm3 && pytest "$TEST") && echo "ARM 3 FAILED: something other than the patch fixed it"

for d in /tmp/arm1 /tmp/arm2 /tmp/arm3; do git worktree remove --force "$d"; done

Then look for what else changed

A passing regression test says nothing about the rest of the behavior. Before merging:

• Run the full test suite, not just the new test.
• Read the whole diff, including files the finding did not mention.
• Ask what supported behavior could change. Trail of Bits found mostly broken features, not new vulnerabilities.
• Keep the fix small. Trail of Bits recommends a PATCHING_GUIDELINES.md or AGENTS.md for fix size and test expectations, and a THREAT_MODEL.md defining assets, trust boundaries and what counts as a vulnerability.

Make it automatic in CI

This GitHub Actions job expects new security tests to fail on the base branch and pass on the pull request head. It adds to your normal test job.

name: fix-proof
on:
  pull_request:
    paths: ["tests/security/**"]
permissions:
  contents: read
jobs:
  fail-before-pass-after:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt pytest
      - name: Collect new security tests
        run: |
          git diff --name-only origin/${{ github.base_ref }}...HEAD -- tests/security/ > new_tests.txt
          cat new_tests.txt
      - name: Tests must fail on base
        run: |
          git checkout origin/${{ github.base_ref }} -- . ':!tests/security'
          if pytest $(cat new_tests.txt); then
            echo "New security tests pass on base; they do not reproduce the bug" && exit 1
          fi
          git checkout HEAD -- .
      - name: Tests must pass on head
        run: pytest $(cat new_tests.txt)

Does AI review replace SAST, SCA or a pentest?

No. It adds a reviewer with different blind spots. Each method answers a different question.

Two notes. Dependency risk is where AI review is the wrong tool: a model reading a diff cannot know every advisory published this week, while matching your full tree against vulnerability databases is a deterministic job. And determinism matters for audits. "The model saw it differently" is a poor answer to an assessor, so keep deterministic tools as your system of record.

A pattern that works:

1. Deterministic dependency scanning and policy gates on every build.
2. Static analysis on every pull request, tuned to your code.
3. AI review on pull requests that touch sensitive areas in your threat model.
4. Reachability to rank dependency findings by whether your code calls the vulnerable path.
5. Dynamic testing on staging and a human penetration test on a schedule or before major launches.

How to keep an audit trail for SOC 2 and SSDF

AI review helps compliance only if it leaves evidence. Aim at NIST's Secure Software Development Framework, SP 800-218 version 1.1. Three tasks matter:

• PW.7.1 asks you to decide whether to use code review (a person looks at the code), code analysis (tools, fully automated or with a person) or both, as defined by your organization. AI review is code analysis under this definition. Write down where you use it.
• PW.7.2 asks you to perform the review or analysis based on your secure coding standards and to record and triage all discovered issues and recommended remediations in the development team's workflow or issue tracker. One example is a static analysis tool with a human reviewing what it reports. Use the same model for AI review: the tool reports, a person decides, the decision is recorded.
• PO.3.3 asks you to configure tools to generate artifacts that support your secure development practices, with examples that include creating an audit trail with existing tooling and setting retention policies for artifact data. SP 800-218 defines an artifact as "a piece of evidence".

For SOC 2, the change management criterion in the Trust Services Criteria expects changes to be authorized, tested and approved before release. An AI generated fix is a change like any other. A model writing it does not lower the bar.

What to keep for every AI reviewed change

Require reviews on protected branches, keep the reviewer's instruction and filter files in the repository so changes are reviewed like code, and export tool usage to your monitoring. Anthropic's security page points to OpenTelemetry metrics and managed settings for this.

Two safety notes before you wire AI review into CI

Prompt injection through the code under review. A pull request is untrusted input. Comments, strings and documentation in the diff can contain instructions aimed at the reviewer. Anthropic's action says plainly that it is "not hardened against prompt injection attacks" and should only be used to review trusted pull requests, and it recommends requiring approval for workflows from external contributors. Apply the same thinking to any AI reviewer: do not give it write tokens on pull requests from forks, and do not let its verdict alone gate a merge.

Agents that can run commands. A reviewer that can also run tests and edit files is far more useful and far more dangerous. Use the most restrictive permission mode that still gets the job done, run it in a sandbox or container for untrusted code, and keep network access off unless the task needs it. Anthropic's security page describes read only starting permissions in manual mode, sandboxed bash with filesystem and network isolation, and a recommendation to use virtual machines when working with untrusted content.

Common mistakes

• Treating a clean AI review as a pass. Absence of findings is weak evidence, especially for bug classes the tool filters out by default.
• Filing findings without a reproduction. This is how trust in a tool collapses after one bad report.
• Merging AI fixes on a green test run alone. The new test proves the bug is gone. Only the full suite and a read of the full diff tell you what else changed.
• Letting the reviewer see the answer key. Your recall numbers become meaningless.
• Measuring once. A single run hides instability. Three runs is the minimum.
• Mixing consumer and commercial accounts. Retention and training terms differ.
• Forgetting local copies. Assistant transcripts on laptops contain your code. Set retention, encrypt disks and include them in your offboarding checklist.
• Using AI review for dependency risk. Matching versions against advisories is a deterministic job. Use a scanner.
• Running the reviewer with write access on untrusted pull requests. Prompt injection is not theoretical for tools that read attacker controlled text.
• No record of who decided. If the decision to dismiss a finding lives only in a chat window, it does not exist for your auditor.

Fix it without waiting for upstream

An AI reviewer that finds a flaw in your own code hands the fix back to you. A finding in a dependency is different: the fix often has to come from a maintainer, and that is where most teams wait.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits in an AI review program

Safeguard does not ask you to trust a model's opinion on its own. Its remediation flow pairs Griffin models with deterministic dependency and SBOM scanning, vulnerability matching against vulnerability databases, and reachability analysis. Each fix pull request goes through analysis, a proposed change, an impact assessment and validation before a person reviews it. That is the verified fix discipline the Trail of Bits post argues for, applied to the dependencies and code paths your application actually uses.

On the data question, Safeguard can run with Safeguard's own models, with a model you bring, with models running inside your own environment, or in Zero AI mode where the platform runs deterministically with no language model at all. The local runner scans on your machine and sends back only encrypted results. Policies and gates are evaluated in the platform, so a finding can block a merge, warn or require approval, and the result is recorded.

The Safeguard CLI includes an assistant that can edit code and run commands with your approval. Its /permissions modes are Ask, Accept edits, Plan, Auto (the default) and Strict, so you choose how much it does without asking. For pipelines, safeguard exec runs it non interactively, and safeguard scan --dir ., --image <name> or --sbom <file> writes results as JSON under ./output for your audit trail. Griffin review of pull request diffs is in early access.

Where it does not help: Safeguard does not replace a human design review of your authorization model, a penetration test of your business logic, or your judgment about which findings matter. It gives you the deterministic layer, reachability context and tested fix pull requests that make AI output worth acting on.

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli. For more on the assistant itself, see the Safeguard CLI as a security aware coding assistant.

FAQ

Can ChatGPT or Claude do a security review of my code?

They can review code and point out likely vulnerabilities. Anthropic's verification program page lists secure code review among tasks open to all users of its generally available models. Treat the output as a list of hypotheses: keep only findings you can reproduce with a test, and verify every fix with a fail before, pass after test.

Is AI code review accurate?

It depends on the bug class and the codebase, and it varies between runs. Trail of Bits reported about 36 percent precision on their first automated regression pass before tightening the evidence rules. Measure it yourself with a seeded test set and at least three runs.

Is it safe to paste my code into an AI model?

On commercial API terms, both Anthropic and OpenAI say they do not train on your data by default, and both keep content for a limited period for abuse monitoring, with zero data retention available to approved customers. Consumer accounts have different terms. Also remember local copies: Claude Code keeps transcripts on your machine for 30 days by default.

Why does the AI refuse to help with my security work?

Labs treat security as dual use. Code review is usually allowed, but writing proofs of concept, validating exploits or analyzing malware can trigger safety classifiers. Anthropic's Cyber Verification Program and OpenAI's Trusted Access for Cyber both reduce these blocks for verified defenders, with identity, authentication and, in Anthropic's case, data retention conditions.

Can AI find business logic vulnerabilities?

Sometimes, within one function or file. It is much weaker at business logic that spans services, queues or user roles, because it cannot see the other services or the deployment. Use threat modeling, integration tests, dynamic testing and human penetration testing for those.

Should I use an open source or local model for security review?

If source code may not leave your network, yes, it is a valid option. You gain control over data and avoid hosted refusals. You also take on evaluation, hosting, patching and access control for the model server. Measure it on your seeded test set before relying on it.

Can AI replace a penetration test?

No. A penetration tester chains issues across a running system and applies judgment about impact. AI review reads code. A clean AI review is not evidence a penetration test would find nothing.

How do I know an AI generated fix is correct?

Require a regression test that fails on the original code, passes on the patched code, and fails again if you revert only the patch. Then run the full suite and read the entire diff for unrelated changes. Trail of Bits found 21 regressions in more than 130 merged patches, mostly broken features rather than new vulnerabilities.

Does AI code review count for SOC 2 or NIST SSDF?

It can, if it leaves evidence. SSDF PW.7.2 asks you to record and triage discovered issues in your workflow or tracker, and PO.3.3 asks for tool artifacts and an audit trail. Keep the tool configuration, raw output, human decisions, test runs and merge approvals.

Can AI review find vulnerable dependencies?

Not reliably. A model reading your code does not know every advisory published this week. Use software composition analysis against vulnerability databases for your full dependency tree, and reachability analysis to rank what your code actually calls.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same ask before acting, test before claiming pattern is what this post recommends for any AI generated fix. It ends with /permissions, /model and /scan ..

Click through it at your own pace, or open it full screen.

If your concern is where your code goes, the second demo shows the local runner. You set it up on your own machine, approve it with its device code, then scan from the terminal. It is the option for teams whose policy says source code stays on their hardware.

Click through it at your own pace, or open it full screen.

If you already review code with Claude, the third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. That pairs the model's reading of your code with Safeguard's deterministic scan results, under permissions you set.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Trail of Bits: Your AI agent fixed the bug, but what else did it change?
• Hacker News: Ask HN, which frontier model can do code security reviews
• Hacker News: Tell HN, AI scanner report on a Go DTLS library
• Hacker News: Ask HN, handling AI security for automated vulnerability management
• Anthropic: claude-code-security-review GitHub Action
• Anthropic: Claude Code data usage
• Anthropic: Claude Code security
• Anthropic: Cyber Verification Program
• OpenAI: Data controls in the OpenAI platform
• OWASP Benchmark project
• NIST SARD: Juliet C/C++ 1.3 test suite
• NIST SP 800-218: Secure Software Development Framework 1.1
• NIST SP 800-218 full text (PDF)

Last reviewed: 22 October 2026. Vendor programs and data policies change often; check the linked documentation for current terms.