Security Review for Agent-Written Code, Step by Step

A coding agent has opened a pull request. The feature works, the tests pass, and the implementation looks reasonable. Your next job is not to ask whether the code looks machine-written. It is to establish what changed, which security boundaries it crosses, and what evidence supports merging it. Use this walkthrough to turn an agent’s output into a reviewable engineering change.

01 · Step 1: Freeze the Patch and Define Its Security Contract

Record the commit under review and compare it with the intended base branch. Read the task description, then write down the security conditions the implementation must preserve: who may perform the action, which records they may access, and which information must never leave the system. Keep these conditions specific enough to test. OWASP recommends reviewing security requirements and application context alongside the code.

For an export feature, your contract might require that users export only their organization’s records, download links expire, and exported fields exclude credentials. Treat this as your acceptance checklist, not as a description of what the agent claims it built.

02 · Step 2: Inspect Every Changed Surface, Not Just Application Code

Review the complete diff, including deleted tests, dependency manifests, lockfiles, deployment settings, and automation workflows. Pay particular attention to changes that widen permissions, expose services, disable logging, or alter agent instructions. OWASP explicitly includes infrastructure, workflow configuration, and agent instruction files in secure review scope.

• › Explain unexpected files: require a task-related reason for each change.
• › Inspect removed safeguards: challenge weakened assertions and bypassed checks.
• › Separate unrelated cleanup: request a smaller patch when incidental changes obscure the security review.

03 · Step 3: Trace Untrusted Input to Privileged Operations

Choose each new entry point and follow its data through the implementation. Inspect where request parameters become database queries, file paths, outbound requests, rendered output, or shell arguments. Check authorization at the operation that reads or changes protected resources, rather than assuming an earlier interface check is sufficient. This follows OWASP’s emphasis on tracing data flows and examining trust boundaries.

For the export example, trace the organization identifier from the request to the database filter. Ask what happens if a valid user supplies another organization’s identifier. Record the exact enforcement point and the test that exercises it.

04 · Step 4: Verify Dependencies and Protect Review Credentials

Confirm that every added package is the intended project, that its version meets your policy, and that its presence is necessary. Run dependency analysis and secret scanning. Also restrict the review agent’s access: do not provide production credentials merely because it needs to inspect code. OWASP highlights dependency verification, secret protection, and excessive agent permissions as separate concerns.

Before sending a patch to any external model service, apply your organization’s data-sharing rules. Remove secrets and unnecessary sensitive content, and verify applicable retention and processing terms rather than assuming a relay changes those obligations.

05 · Step 5: Build Tests That Challenge the Implementation

Run existing tests, then add negative cases derived from your security contract. Try unauthorized identities, cross-organization resource identifiers, malformed inputs, and failure paths. Run static analysis and inspect findings rather than treating a clean summary as approval. NIST recommends combining code review, analysis, and executable testing within secure development practices.

For each suspected defect, seek a reproducible failing test. After remediation, retain that test and rerun the relevant suite against the revised commit.

06 · Step 6: Commission a Bounded Second Review

If you use another model, give it the security contract, sanitized diff, and relevant surrounding code. Request file references, an attack scenario, and a proposed verification method for each finding. Keep its role advisory; NIST’s review guidance includes human evaluation of automated findings and independent expertise.

For teams running repeated reviews, Quanta offers a pay-as-you-go API relay with one balance across models. You can budget review passes using real-token metering while accounting separately for cache writes and reads. Open a Quanta account to consolidate that review workload without treating model agreement as security approval.

07 · Step 7: Attach Evidence to the Merge Decision

Close the review with a short record: reviewed commit, tested security conditions, findings resolved, remaining limitations, and the person approving release. Recheck subsequent changes before merging. Make the decision depend on documented evidence, not the agent’s confidence; NIST recommends retaining review discussions and feedback as part of the development process.