How to Review Code from AI Agents

Diff Strategy for Multi-File Changes

Agent-generated diffs are fundamentally different from human-authored diffs. A human developer typically changes a few files per commit with clear intent. An AI agent may touch 20 or more files in a single session, mixing boilerplate scaffolding with security-critical logic changes. Standard top-to-bottom diff review breaks down at this scale.

Start by categorizing changed files into security tiers. Files that handle authentication, authorization, database queries, file I/O, and network requests are tier one and require line-by-line review. Configuration files, dependency manifests, and CI pipelines are tier two. UI components and styling changes are tier three. Review in tier order, spending the most time on security-critical paths.

• Use git diff --stat first to understand the scope before diving into individual files
• Check for new files the agent created that were not part of the original request
• Look for deleted files or removed code blocks that may have contained security controls
• Compare the agent's changes against the task description to identify scope creep

Checklist Approach for Agent Output

A structured checklist compensates for the cognitive load of reviewing large agent-generated changesets. Unlike human code where you can infer intent from commit messages and coding style, agent output requires explicit verification of security properties.

Apply this checklist to every agent-generated PR:

• Input validation: Are all user inputs validated and sanitized before use?
• Authentication: Do new endpoints require authentication? Are existing auth checks preserved?
• Authorization: Are access controls applied consistently across new and modified endpoints?
• Secrets: Are there any hardcoded credentials, API keys, or tokens in the diff?
• Dependencies: Were new packages added? Are they from reputable sources with no known vulnerabilities?
• Error handling: Does error output avoid leaking stack traces, internal paths, or database details?
• SQL/queries: Are database queries parameterized? Are ORMs used correctly?
• File operations: Are file paths validated against traversal attacks?

Automate as many checklist items as possible through CI. Static analysis tools can verify input validation patterns, secret scanners catch embedded credentials, and dependency scanners flag vulnerable packages. The human reviewer then focuses on the items that require judgment: architectural decisions, trust boundary placement, and business logic security.

Trust Boundaries

Every application has trust boundaries -- the points where data crosses from an untrusted context to a trusted one. Agent-generated code frequently mishandles these boundaries because the agent does not have an inherent understanding of which data sources are trusted in your specific application.

When reviewing agent output, trace data flow across trust boundaries. User input arriving via HTTP requests, data read from external APIs, content loaded from files, and values retrieved from caches all cross trust boundaries. At each crossing point, verify that the agent's code validates, sanitizes, or escapes the data appropriately for its destination context.

Pay special attention to cases where the agent introduced new trust boundaries. A new API endpoint, a new file upload handler, or a new webhook receiver each creates a new entry point for untrusted data. These additions require the most careful review because the agent had to make all security decisions from scratch rather than following existing patterns.

Integration Testing After Agent Edits

Unit tests passing does not mean the agent's code is secure. Agents are adept at writing code that satisfies test assertions, but the tests themselves may not cover security properties. An agent might even modify existing tests to accommodate insecure behavior rather than fixing the underlying code.

After merging agent-generated code, run integration tests that specifically target security boundaries. Test authentication flows end-to-end, verify that authorization rules work across different user roles, and confirm that rate limiting and input validation behave correctly under load. These integration-level tests catch the cross-file inconsistencies that unit tests miss.

• Run DAST (Dynamic Application Security Testing) against the running application after agent changes
• Verify that the agent did not modify or weaken existing test assertions
• Test edge cases that the agent may not have considered: empty inputs, oversized payloads, concurrent requests
• Check that logging and monitoring still capture security-relevant events after the agent's modifications

Related Resources