How to Audit AI-Generated Code Before Deploying It to Production

Most teams already know the pitch: AI assistants write more code, faster, and the senior engineer still owns the merge button. The quiet part is that the merge button is now the only serious control point left. The code was not typed by a human, it was not reasoned about by a human, and in a growing share of cases it was not even read by one before the PR opened.

The numbers back the unease. A December 2025 CodeRabbit study of 320 AI-co-authored pull requests against 150 human-only ones found AI PRs produced 1.7x more issues overall and 2.74x more security issues. Stack Overflow's 2025 survey of 49,009 developers put AI usage at 84% while trust in AI accuracy fell to 29%. Adoption is up, confidence is down, and the gap between them is where production incidents live.

What follows is a gate-by-gate pre-merge workflow for Copilot, Cursor, and Claude-authored diffs. It is engineering, not governance theater, and every gate below can be enforced in CI.

Tag Provenance Before the Diff Is Reviewable

You cannot audit what you cannot identify. The first gate is a provenance header on every AI-authored commit or hunk: the model, the agent, the prompt digest, and the context digest. CycloneDX 1.6 already supports this through component properties and evidence fields, and the emerging practice is to attach a small "generation BOM" alongside the normal SBOM so each generated artifact traces back to a specific model version and intent hash.

Enforce it as a pre-commit hook plus a CI check that fails if an AI-attributed file lacks a signed provenance record. Treat unlabeled AI code as unreviewed code. This is the same discipline our teams apply on AI engagements: if a function came out of a model, the SBOM says so, and the auditor can tell six months later without playing git archaeology.

Two reasons this matters more than it looks. First, licensing exposure (covered below) depends on knowing which code came from where. Second, when a vulnerability lands, provenance tells you which model-and-prompt pattern produced the vulnerable shape, so you fix a class of bugs instead of a single file.

Run SAST and DAST With AI-Aware Rules

Static analysis is table stakes, but the ruleset needs tuning. AI code tends to fail in characteristic ways: unvalidated input flowing into shell calls, overly permissive CORS, string-concatenated SQL, secrets echoed into logs, and the quiet classic of Improper Output Handling (LLM05), where LLM output is passed to a downstream component without sanitization and ends up as injection or RCE.

Run Semgrep or CodeQL on every PR with a ruleset that explicitly includes the OWASP LLM Top 10 and the usual suspects for the languages in play. Fail the build on high-severity findings in AI-authored hunks even when the same finding in human code would merit a warning. The asymmetry is deliberate: 66% of developers in Stack Overflow's 2025 data say AI gives solutions that are "almost right, but not quite", and "almost right" is exactly the shape SAST catches when thresholds are tight.

DAST goes on the staging deploy. Run ZAP or Burp against the preview environment for any PR that touches HTTP surface, and treat a new high-severity finding as a merge blocker. The point of running DAST on preview rather than main is that an AI diff that opens a new endpoint should prove it is safe before the endpoint reaches a shared environment.

Hunt Hallucinated Dependencies Before the Lockfile Pins Them

This is the gate most teams still do not have. A 2025 USENIX Security study from UT San Antonio, Virginia Tech, and the University of Oklahoma analyzed 576,000 code samples from 16 LLMs and found nearly 20% of recommended packages did not exist in any public registry. The attack class is called slopsquatting, and it works because Socket researchers found 58% of hallucinated packages recurred across multiple runs. Attackers precompute the hallucinations, register the names, and wait.

Three concrete controls, enforced in CI on every dependency change:

• Registry existence and age check. For every new entry in package.json, requirements.txt, go.mod, or Cargo.toml, confirm the package exists, was registered before your project started, and has a maintainer with history. New packages with fewer than N downloads auto-block pending human review.
• Allowlist for AI agents with install permission. Any autonomous agent that can run npm install runs against an allowlist, not the open registry. If the agent wants a package not on the list, it files a PR for a human.
• Lockfile and hash pinning. Pin by version and hash, use npm ci or pip install --require-hashes, and run a scheduled rescan against OSV so a package that was fine on merge day gets caught when it turns malicious three weeks later.

Check Licenses and Generate an SBOM on Every Build

AI assistants are trained on code with licenses, and the generated output sometimes carries recognizable fingerprints of GPL or AGPL sources. The commercial risk is not theoretical: a copyleft fragment inside a proprietary codebase is a license violation regardless of whether a human or a model typed it.

Run a license scanner (FOSSA, ScanCode, or Syft plus a policy engine) against every PR. Emit a CycloneDX SBOM at build time and sign it with Sigstore or actions/attest. For AI-authored hunks, add an AST-similarity check against known copyleft repositories; a confidence score above a chosen threshold goes to legal review before merge. This is also the gate where AI-assisted versus traditional development choices show their cost: the SBOM pipeline is overhead you take on in exchange for defensible attribution.

Enforce Coverage and Mutation Thresholds on AI Diffs

The temptation with AI-generated code is to accept the tests the assistant wrote alongside it. That is circular. If the model misunderstood the requirement, it wrote both the wrong implementation and the test that passes against it.

Three thresholds worth setting in CI:

• Line and branch coverage on changed files, with a floor (85% is a defensible starting point for application code) and a delta rule that blocks a PR that lowers overall coverage.
• Mutation score via Stryker, PIT, or mutmut on AI-authored modules. Mutation testing kills the "test passes because it asserts nothing" failure mode that LLM-generated tests fall into.
• Property-based tests on anything parsing input or doing arithmetic that matters. Hypothesis or fast-check catches the edge cases the model did not imagine.

Context for why this is non-negotiable: an Uplevel study of nearly 800 developers found no meaningful improvement in PR cycle time after Copilot adoption and a 41% increase in bugs. The productivity story only works if the extra bugs are caught before merge, which means tests have to be adversarial, not corroborative.

Keep a Human in the Diff

Automation is necessary and not sufficient. A senior engineer still reads every AI-authored diff that touches auth, payments, PII, infra, or data migrations. That is the non-negotiable list. Everything else can go through a lighter review, but the heavy list reads the whole diff, not just the hunks CI flagged.

Three practical rules the reviewers follow:

• Read the diff against the ticket, not against the model's commit message. Models rationalize what they wrote; the ticket says what was asked for.
• Reject diffs that mix refactors with behavior changes. Models love doing both at once because it inflates the apparent progress. Separate them.
• Ask the model to explain any block the reviewer does not understand, then verify the explanation against the code. If the explanation and the code disagree, the code is wrong.

Teams running larger rollouts formalize this with a two-reviewer rule for AI code in the heavy categories. The economics work: the ROI math on AI-assisted delivery only closes if post-merge defects do not eat the gains, and a 15-minute second review is cheaper than a Sev-1 at 2 a.m.

Wire the Gates Into a Single Pipeline

Each gate above runs on every PR. The order matters because cheap gates fail fast: provenance tagging and dependency existence checks run first and take seconds; SAST runs next in parallel with license scanning; DAST and mutation testing go on the preview deploy; human review is the last gate before merge to main. The pipeline fails closed. An AI-authored PR with missing provenance or an unverified dependency does not reach a reviewer.

Buyers evaluating a partner for this work should ask for the actual CI config, not the slide. A real pre-merge pipeline for AI code has a provenance step, an existence check, a signed SBOM, a mutation score gate, and a named reviewer policy. If a vendor cannot point to those artifacts in a repo, they do not have the practice yet. The teams we work with through custom AI rollouts show the YAML.

The Audit Is the Deliverable

AI-generated code is not inherently worse than human code. It is faster, more plausible, and failure-prone in characteristic ways, which means the review process has to catch different things than it did five years ago. The pre-merge gate is where that happens. Treat provenance, dependency hygiene, SAST and DAST, license posture, mutation-tested coverage, and senior human review as six parts of a single audit that every AI-authored diff passes before it reaches main. Skip one and the next incident writes itself.