How to Review AI-Generated Code Before Merge

How do I run a security review on AI-generated changes before merging them

Run the review as a merge gate, not as a casual code glance. The goal is to prove the change is safe enough to ship, with a human owner, automated checks, and a record of what was reviewed. OWASP says AI-generated code needs human accountability, and NIST’s SSDF says testing belongs before release, not after incident response.

Start with scope. Ask what the AI changed, what it touched indirectly, and what user-facing or infrastructure-facing paths it can influence. The part people miss is the hidden path: a prompt-generated edit to app code can still change auth rules, deployment settings, dependency versions, logging, or secret handling. OWASP specifically calls out AI changes to deployment configuration as a review risk.

Read the diff line by line, then trace the data flow. Check where input enters, where it is validated, where it is stored, and where it is rendered or executed. Security review is not only about obviously dangerous functions, it is about whether the change creates a new trust boundary or weakens an existing one. That includes command execution, SQL queries, template rendering, file paths, and network calls.

Run automated checks before anyone approves the merge. Use SAST, dependency review, secret scanning, and whatever CI checks your team already trusts. GitHub documents code scanning and dependency review as pre-merge controls that catch vulnerabilities before they reach production. NIST also recommends vulnerability testing, fuzzing for input handling, and re-running tests for previously reported issues.

Treat secrets as a separate review item. AI-generated patches often add debug logs, example config, copied environment variables, or test fixtures that accidentally expose credentials. Search the diff for API keys, tokens, private URLs, certificate material, and anything that looks like a credential pattern. If the change touches environment files, deployment manifests, or CI variables, verify that nothing sensitive moved from protected storage into source control.

Check dependencies with suspicion, not optimism. AI tools often add packages to solve one small problem, but each dependency expands your attack surface and your maintenance burden. Review new direct dependencies, version bumps, transitive risk, install scripts, and lockfile changes. GitHub’s dependency review flow exists for exactly this moment, when a pull request quietly adds a vulnerable library that code review alone would not catch.

Verify tests that prove the security property, not just the feature. A passing unit test that checks the happy path is not enough if the change affects authentication, authorization, input validation, rate limiting, or serialization. NIST recommends functional security tests, dynamic vulnerability testing, and regression tests for prior vulnerabilities. In practice, that means adding one test that fails before the fix and passes after it.

Use a threat-model mindset for the review. Ask how the change could be abused if an attacker controls input, traffic, filenames, headers, model output, or a downstream dependency. The inconvenient part is that AI-generated code often looks complete, so reviewers stop at style and compile success. Security review has to keep going until you can explain how the worst plausible misuse still fails safely.

Require a second human for high-risk changes. Anything touching authentication, authorization, payment, data export, webhook handling, secrets, or deployment should get a deeper review than ordinary product code. OWASP says a human must approve AI-generated changes, and GitHub supports merge protection when checks fail. If the team can only afford one review, make that review slower and stricter, not shorter.

Block merge on unresolved findings. Do not merge because the AI says the issue is fixed, because the diff looks small, or because the feature is urgent. The review has to produce a clear outcome: approved, approved with a tracked follow-up, or rejected. Every issue should be written into the same workflow your team uses for normal security bugs, with a concrete owner and a concrete remediation. NIST recommends recording discovered issues and recommended remediations in the team workflow.

Use a short reviewer checklist so the same mistakes do not repeat. A practical one is: does the diff change trust boundaries, add dependencies, touch secrets, weaken auth, alter logging, alter deployment, or skip tests for a security-relevant path. If the answer is yes to any item, the reviewer expands the review before merge. That checklist is valuable because AI-generated changes often hide their risk in a file that looks operational rather than security-sensitive.

Make the CI gate stricter than the human gate. Humans miss things when they are tired; automation does not get bored. GitHub’s merge protection and code scanning let you block pull requests that fail security checks, which gives the reviewer a hard stop instead of a polite warning. That matters most for AI-generated changes, because the failure mode is usually speed, not malice.

A concrete example: an AI adds file upload support to a web app. The security review should confirm the file type check is server-side, the storage path is not attacker-controlled, filenames are normalized, uploads cannot execute, preview rendering cannot trigger script execution, and the dependency added for image parsing has no known issues. If any of those points are unclear, the change is not ready.

Another example: an AI refactors a payment webhook handler. The review should verify signature validation still happens before parsing, replay protection still works, malformed payloads fail closed, and logs do not contain secrets or raw card data. People get this wrong by checking only whether the endpoint still returns 200 in the happy path. A security review checks the unhappy path first.

If you want a simple operating rule, use this one: no AI-generated change merges until a human can explain the security impact in one sentence, name the automated checks that ran, and point to the test or control that proves the risky path is safe. That standard is inconvenient, and it is the right level of inconvenient.

If you need a shared place to organize that process, DevConnect is built around practical testing and review work, and you can keep the flow inside your own owned project without relying on unsafe shortcuts: https://devconnectplatform.com.

What is the minimum security review before merge

The minimum is a human read-through of the diff, automated security scans in CI, dependency review for new packages or version bumps, and an explicit approval from the person responsible for the change. OWASP and NIST both place human review and pre-release testing at the center of the process.

What should I check first when the AI touched authentication or authorization

Check whether the change weakens access control, broadens a permission check, changes session handling, or adds a bypass path. The safest habit is to read the code as if an attacker already knows where the new branch is and is trying to reach it.

What if the AI-generated change is only a small refactor

Small refactors still deserve security review if they touch parsing, logging, configuration, dependencies, or any security-sensitive path. Many real incidents come from “harmless” cleanup that moved a check, reordered logic, or exposed a secret in a log.

What evidence should I keep after the review

Keep the diff, the reviewer name, the automated scan results, the test results, and any follow-up issues created from the review. NIST recommends documenting discovered issues and remediations in the team workflow, which is what makes the review auditable instead of informal.