AI code audit checklist for 2026: six sections, printable, with a free template
A six-section AI code audit checklist: inventory, SAST, auth and input validation, dependencies, business-logic tests and senior review. Free template.
On this page
An AI code audit checklist has six sections: an inventory of what the AI wrote and where it runs, a static analysis (SAST) pass, a hand check of authentication and input validation, a dependency audit that catches hallucinated packages, business-logic tests against the original requirements, and a senior review of the paths that handle money, identity and personal data. Below is the full checklist, the 2026 reasons it matters, and a free template you can copy.
Why AI-generated code needs its own audit
Code from Cursor, Claude Code, Copilot or Codex looks finished. It compiles, the tests the model wrote pass, and the pull request reads well. MetaCTO's July 2026 guidance on review standards for AI-generated code calls this the "review trap": plausible code that misses a requirement, invents an API, or skips an authorization check, and sails through a review that was looking for style.
The numbers are not vendor hand-waving. Veracode's 2025 GenAI Code Security Report ran 80 curated coding tasks through more than 100 language models and found that they introduced a security vulnerability in 45 percent of cases. Java failed above 70 percent; Python, C# and JavaScript sat between 38 and 45 percent. Cross-site scripting was left open in 86 percent of cases and log injection in 88 percent.
Dependencies are a newer class of problem. A USENIX Security 2025 study by Spracklen and colleagues tested 16 models across roughly 576,000 generated code samples and found that 19.7 percent of the packages they recommended did not exist. Attackers now register those invented names, a practice called slopsquatting. A conventional review never checked whether a package was real, because until recently it always was.
So an AI code audit is not a normal review done more carefully. It adds checks with no human-code equivalent, and it moves the human effort to where a confident-looking mistake costs the most.
The three drivers in 2026
Vibe-coded MVPs are reaching customers. Founders are shipping products built largely by agents, often by one person over a few weeks. The audit is the first time anyone has read the code as a whole. Firms that publish what they find in these codebases report the same pattern: admin screens protected in the UI but not at the API, missing rate limits, row-level security absent or misconfigured, secrets in the repository.
SOC 2 due diligence. Under the change-management criteria (CC8 in the AICPA Trust Services Criteria) the auditor's question is whether every significant change was reviewed, approved and tested before production. Neither SOC 2 nor ISO 27001 names "code review" as a control, but both expect change management to be enforced and verifiable. A pull request written by an agent and approved by the person who prompted it is a weak answer; a documented audit with named reviewers is a strong one.
The EU AI Act. General-purpose AI model obligations have applied since 2 August 2025, and the Act became broadly applicable on 2 August 2026. The AI Omnibus (Regulation (EU) 2026/1744, in force from 27 July 2026) moved the stand-alone high-risk obligations in Annex III to 2 December 2027 and embedded-product obligations to 2 August 2028. If you sell into employment, education, credit or critical-infrastructure use cases, "an agent wrote it and we did not check" is not a defensible technical documentation entry.
The checklist, section by section
Print it, or copy the hosted code audit checklist template into your workspace. Tick each item, note the evidence (a link to a scan result, a test, a commit), and name the person who checked it.
1. Inventory and architecture map
- List every repository, service, scheduled job and infrastructure definition in scope.
- Mark which files or modules were AI-generated, AI-assisted, or hand-written. Git blame plus the commit messages usually tells you; if the team does not know, say so in the report.
- Draw the request path: entry points, auth layer, data stores, third-party calls, background workers.
- Note the runtime versions and the deployment target.
- List every place personal data, payment data or credentials are stored or transit.
Without this section the rest of the audit samples at random.
2. Static analysis (SAST) and secret scanning
- Run a SAST tool over the whole codebase (Semgrep, CodeQL, SonarQube, or the language-specific equivalent) and keep the raw output.
- Run a secret scanner (gitleaks, trufflehog, or your host's built-in scanning) over the full git history, not just HEAD.
- Triage findings into true positive, false positive and accepted risk, with a one-line reason each.
- Check the model's favourite weaknesses by hand: output encoding on every template and API response (XSS), and user input reaching log statements (log injection).
- Confirm the agent did not loosen type checks or lint rules in CI to make a build pass.
3. Authentication, authorization and input validation
- Every protected route checks identity on the server, not only in the UI.
- Every object-level access (by id) checks that the caller owns or may see that object.
- Admin functions are gated by role, and role is read from the session, not the request body.
- Sessions and tokens expire, rotate on privilege change, and are stored with HttpOnly and Secure flags.
- Password handling uses a current hash (Argon2id, scrypt or bcrypt) with no custom crypto.
- All input is validated at the boundary with a schema (Zod, Pydantic, JSON Schema) and database access is parameterised.
- Rate limits exist on sign-in, sign-up, password reset and any endpoint that sends email or SMS.
- CSRF protection is present on state-changing browser requests.
This is where vibe-coded apps fail most often, and where the model's output is most convincing. Read these files line by line.
4. Dependency audit
- Every package in the lockfile exists on the public registry under that exact name and has a plausible history (age, maintainers, downloads).
- Any package first added by an AI tool was checked on the registry page by a human.
- Run a software composition analysis tool (npm audit, pip-audit, OSV-Scanner, Snyk, Dependabot) and record open advisories.
- Licences are compatible with how you ship (watch for GPL in a closed-source SaaS).
- Pinned versions and a committed lockfile.
5. Business-logic and requirements tests
- Write down the requirements the code was supposed to meet. If they only exist in prompts, recover them from the prompt history and freeze them as a baseline.
- For each requirement, name the test or manual check that proves it. Gaps are findings.
- Test the edge cases the model tends to skip: empty lists, duplicate submissions, concurrent updates, timezones, currency rounding, partial failures in multi-step operations.
- Check that the tests the agent wrote test behaviour, not just that a function returns without throwing.
- Run the application end to end on a clean environment and follow the money: pay, receive, refund, invoice.
6. Senior review and sign-off
- A senior engineer who did not write the code reads every file on the Red list: authentication, payments, personal data, migrations, public API surface, infrastructure.
- Each finding has a severity, evidence, an owner and a target date.
- The reviewer records what they personally checked and what they sampled.
- A named person signs the report, with the date and the commit hash audited.
Severity scale to use
| Severity | Definition | Fix before |
|---|---|---|
| Critical | Exploitable now: auth bypass, exposed secrets, SQL injection on a public route, payment logic error | Any further deployment |
| High | Exploitable with a precondition, or a requirement silently unmet in a core flow | Next release |
| Medium | Defence-in-depth gap, unpinned or stale dependency with a known advisory, missing rate limit on a low-value route | Within 30 days |
| Low | Style, dead code, non-blocking lint findings, documentation | Backlog |
Keep the scale short. Four levels everyone uses beat ten that nobody agrees on.
How published frameworks compare
As of October 2026, the two most-cited published structures are:
| Framework | Shape | What it adds | Where it is thin |
|---|---|---|---|
| SolGuruz, "How to Audit AI-Generated Code in 2026" | Five stages: inventory and architecture mapping, SAST scanning, business-logic testing, dependency audit, senior expert review; the authors call it a framework, not a checklist | Puts inventory first and senior review last, which matches how a paid audit runs | Says little about recovering the requirements the code was built against |
| MetaCTO, "Establishing Code Review Standards for AI-Generated Code" (July 2026) | Ten pre-merge checks with a named owner each, plus Green, Yellow and Red risk lanes; AI reviewers advise but cannot approve Red-lane changes | Best treatment of ownership and of disclosing AI involvement in the PR | Written for ongoing review, not a one-off audit of an existing codebase |
| This checklist | Six sections, printable, severity scale, sign-off | Adds the requirements baseline step and the EU AI Act and SOC 2 evidence angle | Not a substitute for a penetration test |
Our six sections follow the SolGuruz order and borrow MetaCTO's rule that the person who prompted the code cannot be the only person who approves it.
Running the audit in five steps
- Scope and freeze. Agree the repositories, the commit hash and the requirements baseline. Nothing merges to the audited branch until the report is signed.
- Automate first. Run SAST, secret scanning and dependency scanning on day one, so the humans spend their time on triage rather than discovery.
- Read the Red list. Authentication, payments, personal data, migrations, public API, infrastructure. Line by line, by someone who did not write it.
- Test the requirements. Map each frozen requirement to a test or a manual check. Record what is missing.
- Write, sign, track. One report, one severity table, one owner per finding, and a tracker where the fixes are visible until closed.
For a three-person team with a 20,000-line codebase, budget a working week: a day for steps 1 and 2, two to three days for step 3, a day each for steps 4 and 5.
Where Atrix fits, and where it does not
Atrix AI does not scan source code, run static analysis or find vulnerabilities. What its agent does is a requirements audit: you freeze a requirements baseline (from a PRD page or a Develop run), and the audit reports which requirements are covered by planned or shipped work, which have drifted, and which have no owner. That maps to section 5 of this checklist and nothing else; the code audit feature page spells out that boundary.
The human code audit is a different service. Atrix Digital, the agency behind the product, performs code audits with people reading the code; that covers sections 1 to 4 and 6. Inside Atrix the findings land as issues in a cycle, the report lives as a page with a share link for the client, and the checklist template is a page database you tick through. That is the setup we use on our own audits.
FAQ
What is an AI code audit?
A structured review of code written largely by AI tools, covering inventory, static analysis, authentication and input validation, dependencies, business-logic tests and a senior review, with findings rated by severity and signed off by a named reviewer. It adds checks for hallucinated packages and for requirements the model silently dropped.
How is auditing AI-generated code different from a normal code review?
Three things change. You verify that dependencies exist and are what they claim to be; you recover the requirements from prompts and test against them, because the model may have solved a slightly different problem; and you move human attention to authentication, payments and data paths, where Veracode's 2025 testing shows models fail most often.
How long does an AI code audit take?
For a codebase under 20,000 lines with one or two services, about a working week for one senior engineer. Larger codebases scale with the size of the Red list, not the total line count.
Do I need an audit for SOC 2?
SOC 2 does not require an audit by that name, but its change-management criteria expect evidence that changes were reviewed, approved and tested by someone other than the author before production. A signed audit report plus enforced pull-request review is strong evidence; a solo founder approving their own agent's output is not.
Does the EU AI Act require me to audit AI-generated code?
Not directly. The Act regulates AI systems by their use, not by how their code was written. But if your product is a high-risk system under Annex III, the technical documentation and risk-management obligations, applying from 2 December 2027, are far easier to meet if you can show how the code was reviewed and tested.
Can Atrix AI audit my code?
No. Atrix AI audits requirements against a frozen baseline; it does not read or scan source code. For a human code audit, use the Atrix Digital agency service, and track the findings in Atrix as issues.
Next step
Copy the code audit checklist template into a page, freeze your requirements baseline, and run the six sections in order. If you are auditing a codebase you did not write, the companion post on how to audit AI-generated code before you ship it walks through the baseline step in more detail.
Sources
Facts checked in October 2026: Veracode 2025 GenAI Code Security Report press release, MetaCTO, Establishing Code Review Standards for AI-Generated Code, SolGuruz, How to Audit AI-Generated Code in 2026, European Commission, AI Act regulatory framework and timeline, Spracklen et al., package hallucination study, as summarised by Xygeni, AICPA Trust Services Criteria.