A pull request adds a CSV export. The button works, the file contains the expected rows, and the tests pass. Before merging, someone still needs to answer a less convenient question: can the wrong person get that file?

That is where a security review starts. Security review for AI-generated code means checking a specific change against the application’s access rules, data handling, and operating environment, then verifying any fixes. The result should explain what was examined, what the evidence supports, and what remains uncertain.

The origin of the code does not settle those questions. An AI coding tool can produce a sensible implementation while missing a rule it was never given. A human can make the same mistake. If you want the reasoning behind this checkpoint, read why AI-generated code still needs security review. This article focuses on doing the work.

Start with the change and its rules

“Review this application for security” gives a reviewer very little to work with. A particular diff, the requirement it implements, and the relevant surrounding code provide a better starting point.

For the export feature, the scope might cover who can request an export, which records belong in it, where the file is stored, and who can download it. Those decisions may span a request handler, a background job, and storage configuration. Reviewing the button alone would miss most of the feature.

Write down the intended behavior before judging the implementation. Does access belong to an individual, a team, or a tenant? Can someone share an export? How long should it remain available? These are product decisions with security consequences. A reviewer should identify missing answers rather than invent a policy that happens to fit the code.

Include the dependency versions and configuration needed to understand the change. Keep credentials and private customer data out of review material; use redacted context and synthetic examples where possible.

Trace a feature beyond the diff

Follow a normal request from the caller to the final output. Then repeat that walk for a caller who should be denied.

In an export workflow, checking permission when the user clicks a button is only one step. A queued job needs a trustworthy account context. Its query needs the intended tenant or ownership restriction. The generated file needs an access rule too. If downloads are private, protecting the request handler while placing the result at a public URL leaves the job unfinished.

The example here is hypothetical. It shows how a review can move from a small code change to the behavior that matters without claiming that a particular product has this flaw.

Keep following the less visible paths. What reaches a log when the export fails? Can a retry reuse a file from another request? Does the application make the same decision if the user’s permissions change while the job waits? The correct answer to that last question depends on the product’s policy, but the implementation needs an explicit answer.

This is also where generated code deserves a careful read: check the assumptions it introduced about identity, library behavior, defaults, and error handling. A familiar-looking method name is not evidence that the installed version supports the behavior being relied on.

Choose checks that answer the question

A linter can catch a prohibited pattern. Static analysis can identify suspicious data flows. A dependency scan can flag a known vulnerable package. Tests can exercise an access rule or a failure path. Each contributes useful evidence, with its own limits.

For the export example, the interesting question is whether an unauthorized account can retrieve private data. A clean dependency report does not answer it. A test that exercises the real download path with the wrong account is much closer to the requirement.

OWASP ASVS provides requirements for verifying application security controls. Select the requirements that fit the change and record the version you used. Checking a handful of them does not establish conformance with the entire standard.

NIST SSDF 1.1 places secure development practices within the software lifecycle. That is a useful way to organize the work: review, tests, dependency checks, and operational controls support one another over time. No single tool result covers all of them.

An AI reviewer can help locate a risky assumption or propose a test. Check its finding against the actual code and behavior. Treat a suggested fix as another change to inspect, especially if it alters permissions or failure handling.

Write a finding someone can act on

“Improve access control” sends the author back to the beginning. A useful finding identifies the path, the caller, the missing decision, and the consequence.

For the hypothetical export workflow, a finding might read:

The download handler looks up the export by its identifier and returns the file without checking whether the authenticated caller belongs to the owning account. A user who obtains another account’s export identifier could read that account’s data. Enforce the account-access rule before returning the file, and verify both allowed and denied downloads.

In a real review, attach the relevant file and line, the input revision, and the observation that supports the claim. If you only inspected source, say so. If you reproduced the behavior, record the environment and sanitized result. Do not describe a possible path as a demonstrated incident.

The proposed fix should fit the existing permission model. A strict owner-only check could break legitimate team sharing. A public signed link might be intentional, but its scope, lifetime, and distribution still need to match the requirement. The reviewer needs enough product context to distinguish a flaw from an accepted design.

Verify the fix through the real path

A fix earns confidence when the original failing case is repeated and the legitimate workflow still works. For an export change, that may mean checking:

  • An authorized account can request and retrieve the intended export.
  • An unrelated account cannot retrieve it through the download route.
  • Missing or expired credentials produce the expected response without exposing file contents.
  • Files, logs, and cached responses follow the same data-access and retention rules.

These are suggested checks for the example, not reported test results. Choose additional cases from the actual design, including sharing, permission changes, and job retries where relevant.

Keep the verification close to the boundary being claimed. A helper-function test can establish how that function behaves. It cannot show that every route calls the helper or that production storage is private. Integration and runtime checks are needed for those conclusions.

For a smaller runnable exercise, the Linmas authorization tutorial demonstrates a cross-user read and an ownership fix using synthetic in-memory data. Its limits are explicit: it does not test a real session, database, or deployment.

Close the review with a decision and a record

A review is ready for a decision when the team can identify the inspected change, the findings, the fixes and their verification, and any unresolved work. Someone accountable for the change still needs to decide whether the remaining risk is acceptable.

Avoid stretching a narrow result. “The cross-account download test passed for this revision” is a useful statement. It does not establish that every export path, storage policy, or future revision is secure. When a relevant boundary changes, revisit the evidence.

Linmas organizes this work as Scope, Route, Review, Remediate, and Verify. Its Review Capsule can preserve the evaluated input identity, normalized findings, policy decision, and execution metadata. That record helps another reviewer understand what was done. It does not replace their judgment or certify the application.

For the next pull request, choose one sensitive operation and follow it from the caller to the result. Write down the rule it should obey, then keep the evidence that shows whether it does.

Sources and editorial notes

Revised September 29, 2026. The CSV export scenario and sample finding are editorial examples, not a report of a tested vulnerability. The linked primary sources were checked on the revision date.