Reviewing AI-Generated Code for Security: A Practical Checklist

Assistants optimize for code that looks right and runs. That produces distinctive problems:

• The code compiles and passes the happy-path test, so nothing feels wrong.
• It reproduces patterns from older or insecure examples, such as weak hashing or string-built queries.
• It fills gaps confidently. If it doesn't know your authorization model, it may skip the check rather than ask.
• Volume goes up. More code per pull request means less attention per line.

The author's responsibility doesn't change. Whoever accepts the suggestion owns it, and the reviewer shouldn't lower the bar because a tool wrote the diff. Your team's AI assistant policy should say so explicitly.

Work through these in order on any pull request with substantial AI-assisted code:

1. Dependencies: does every new package exist, is it the intended one, and is it maintained? Assistants sometimes suggest names that don't exist, and attackers can register look-alike names.
2. Authentication and authorization: does each new endpoint or action verify who is calling and whether they may do this to this record? Check object-level access, not just login.
3. Input handling: is input validated on the server, with parameterized queries and output encoding where data reaches a database, shell, file path or page?
4. Secrets: any keys, tokens or connection strings in code, tests or comments? Are new environment variables read from config, not defaulted to a real value?
5. Cryptography: is it using a vetted library and current algorithms, and is randomness from a secure source? Hand-rolled crypto is a rejection.
6. Error handling and logging: do errors leak internals, and do logs capture tokens or personal data?
7. Data exposure: does the response return more fields than the caller needs?
8. Tests: do the tests include a failing case and an abuse case, or only the happy path?

Ask the author to explain any block they can't describe. If they can't, it shouldn't merge.

Learn these by sight so they jump out in a diff:

• Missing tenant checks: a query that fetches a record by ID with no filter on the owning account.
• Trusting the client: price, role or user ID taken from the request body.
• Permissive defaults: wildcard CORS, debug modes, disabled certificate checks left in "temporarily".
• Outdated API use: deprecated auth flows or hash functions copied from old tutorials.
• Swallowed exceptions: a broad catch that returns success, hiding a failed security check.

Keep a running list of what you find in your own repo. The same three mistakes usually account for most findings, and they belong in your team's rules for the assistant.

A reviewer can't catch everything, so layer tools that run on every pull request:

• Secret scanning on commits, ideally blocking the push.
• Dependency scanning for known vulnerabilities and for suspicious new packages.
• Static analysis for the language you use, tuned to fail on high-severity findings only, or engineers will stop reading it.
• Tests that fail when a security rule is broken, such as an endpoint reachable without a token.

A scanning product such as Snyk covers dependency and code scanning in one workflow, but the pattern matters more than the vendor. On timing, CISA's federal directive BOD 19-02 sets 15 days for remediating critical vulnerabilities on internet-accessible systems¹, which is a reasonable internal target to borrow.

Some code deserves a second, specialized reviewer regardless of who wrote it: authentication and session handling, payments, anything touching encryption, file uploads, data export and deletion, and code that runs with elevated privileges. Require that extra approval by path using code ownership rules, so the process doesn't depend on someone remembering. For everything else, a normal reviewer with this checklist is enough.