Before You Merge: A Security Review Checklist for AI-Generated Code
Use this practical review checklist to inspect AI-assisted code for access, data-flow, dependency and deployment risks before it reaches production.
AI can draft code quickly, but the person or team merging it remains responsible for understanding what the change does. A generated patch may compile and still mishandle permissions, expose data, introduce an unsafe dependency or fail under an edge case the prompt did not mention.
This checklist is for developers and small teams reviewing ordinary application changes. It is a starting point for human review, not a vulnerability scanner, penetration test, compliance certification or guarantee that software is secure.
Before reviewing the diff
**Keep sensitive information out of unapproved prompts.** Do not paste production credentials, private keys, customer records or confidential source code into an AI service unless the organization has approved that tool and its data handling for the specific information.
**Understand the change request.** Write down the intended behaviour, affected users, data touched, trust boundaries and failure conditions. Ask the author to identify generated or substantially AI-assisted sections where that context is useful. Do not rely on an AI-generated summary as the only explanation of the change.
Review the code in context
### 1. Trace input to sensitive operations
Follow untrusted input from the request, file, queue or external service to database queries, shell commands, templates, file paths and network calls. Check that validation happens at the correct boundary and that output is encoded for its destination. Look for injection risks, unsafe deserialization, path traversal, server-side request forgery and error messages that expose internal details.
### 2. Verify authorization—not just authentication
Check that every sensitive action is authorized for the specific record and operation. Ask whether a user can change an identifier, role, tenant or object reference to access another person’s data. Confirm server-side checks do not depend only on a hidden button or client-side state.
### 3. Inspect secrets, cryptography and configuration
Search the complete diff for credentials, tokens, private endpoints, debug settings and permissive defaults. Confirm cryptographic operations use established libraries and appropriate defaults rather than custom algorithms. Ensure logs do not expose secrets or unnecessary personal information.
### 4. Review dependencies and build changes
Inspect new and updated packages, versions, sources, licenses and lockfile changes. Verify that build scripts and CI workflows do not introduce unexpected network access or executable code. Use the organization’s dependency and supply-chain checks where available; a clean scan does not replace review of how the package is used.
### 5. Test both expected and rejected behaviour
Run the relevant unit and integration tests. Add cases for missing, malformed and unauthorized inputs; boundary values; duplicate requests; dependency failures; and error handling. Confirm a test fails when the protected behaviour is removed, where feasible. Passing tests show that tested cases passed—they do not prove the absence of vulnerabilities.
### 6. Review the final change and release path
Read the full diff, including generated files and configuration. Confirm the change is small enough to review, has an accountable human owner, and can be rolled back. For high-risk changes, require an independent reviewer who understands the affected system. Monitor relevant logs and user-facing behaviour after release without recording sensitive data unnecessarily.
Use recognized references without overstating them
OWASP’s Top 10:2025 is an awareness document describing major web application risk categories; OWASP cautions that it is only a starting point for secure code review. For testable application security requirements, consider the OWASP Application Security Verification Standard (ASVS) 5.0. NIST’s Secure Software Development Framework (SP 800-218) provides practices that can be integrated into a software development life cycle. Select controls based on the application, data and threat model.
For account hygiene around developer and service accounts, iPragma’s Password Generator can create a unique password locally in the browser. Never use a generated password as a substitute for secrets management, access review or secure key handling.
Teams that need a broader review of application risks can explore iPragma’s security and reliability services. This checklist is general information; regulated, high-impact or externally exposed systems may need a qualified security assessment.
A lightweight merge record
For meaningful changes, record the reviewer, the intended behaviour, tests run, dependencies changed, unresolved risks and rollback plan. This short record makes later maintenance easier and helps teams learn whether AI assistance reduced total work or simply shifted effort into review and rework.