Alice opens her document. The page loads, the test passes, and the change looks ready to merge. Then Bob requests the same document with his own account. If he gets Alice’s data, the feature works exactly as implemented. The implementation is wrong.

This is why AI-generated code still needs a security review. Working code does not establish who should be allowed to use it, which data they may access, or what should happen when a request falls outside those rules. A review connects the change to those requirements and looks for evidence that they hold.

The same responsibility applies to human-written code. AI assistance changes how quickly a plausible implementation arrives; it does not remove the need to check its assumptions against the application.

The cover illustrates the synthetic ownership-check example discussed below. It depicts an access decision, not a live incident or a certification.

A passing test can miss the access rule

A test that confirms Alice can read her document answers one useful question. It says nothing about Bob unless the test also tries Bob’s request. If the implementation and its tests share the assumption that every signed-in user may read every document, both can agree and still violate the product’s rules.

Authentication identifies the caller. Authorization decides whether that caller may perform a particular action on a particular resource. Those decisions are related, but checking a session does not establish ownership, tenant membership, or permission to read a record.

OWASP’s Authorization Cheat Sheet recommends validating permissions on every request and testing authorization logic. Hiding a button or making an identifier difficult to guess does not replace that server-side decision.

A small example you can verify

Linmas includes a local authorization review tutorial with a synthetic document owned by Alice. The deliberately vulnerable variant finds a document by ID and returns it to any authenticated user. When ownership enforcement is enabled, the same fixture also checks that the stored owner matches the caller.

The fixture checks five cases:

  • Alice can still read her own document.
  • Bob cannot read Alice’s document after the ownership check is applied.
  • An anonymous caller is rejected.
  • A malformed document identifier is rejected.
  • A missing document returns the expected not-found result.

Inspect and download the complete fixture, then run it from the directory where you saved it using Node.js 24 or later:

node authorization-review.mjs

It uses in-memory data and needs no server, credentials, or model call. The assertions reproduce the cross-user read in the vulnerable variant and verify the restricted behavior in the corrected one. The teaching toggle belongs only in this fixture. Production code must enforce its access rules on every request.

There are limits to the evidence. The fixture receives a synthetic user identity; it does not validate a real session. It also does not exercise a database, tenant roles, shared documents, or concurrent ownership changes. In an application, derive identity from trusted authentication and test the actual permission model, including any legitimate sharing rules.

Follow the change beyond the generated lines

Start a review with one change you can name: a diff, handler, permission rule, or deployment setting. Then follow the data and decisions it depends on. A short handler can rely on middleware, database roles, a cache, and logging defaults that are absent from the prompt used to generate it.

For a document-reading feature, useful questions include:

  • Does every route to the document apply the same access rule, including downloads and cached responses?
  • Can a caller influence an owner or tenant identifier that the server treats as trusted?
  • Can errors, logs, or tracing reveal the document or an access token?
  • Do production credentials or network rules grant more access than the test environment assumes?

Keep distinct problems distinct. A parameterized SQL query helps prevent input from changing query structure, as described in OWASP’s SQL Injection Prevention Cheat Sheet. It does not decide whether Bob may read Alice’s row. Input validation, query safety, and authorization each need the appropriate check.

Use automation to gather evidence

Linters, static analysis, dependency checks, secret scanners, and tests can catch different classes of mistakes. An AI reviewer can help trace a change or suggest a missing test. Their usefulness depends on the input, configuration, and behavior they actually examine.

Ask for a finding that names the affected code, the precondition, the possible impact, and a concrete fix. Then inspect the claim. A warning without a reachable path may be a false positive; a clean report may simply reflect missing context. GitHub’s responsible-use guidance for Copilot agents likewise emphasizes human oversight and review of outputs.

Be careful with the material supplied to a hosted reviewer. Use authorized, sanitized context, and follow your organization’s rules for private code and data. Credentials are not necessary to explain an ownership check.

Make the fix earn its test

For the Alice-and-Bob example, the review should leave behind more than “authorization fixed.” Record the failing cross-user case, the change that enforces the access rule, and the result when the same case is rerun. Keep the owner-access test too; blocking every reader would conceal a broken feature behind a passing denial test.

A useful review record answers four questions:

  1. What did we inspect? Identify the revision, affected path, and relevant assumptions.
  2. What failed? Describe the caller, resource, attempted action, and observed result using synthetic or redacted data.
  3. What changed? Point to the enforced boundary and explain why the change addresses the failure.
  4. What remains unverified? Name missing runtime checks, deployment differences, or permission cases that still need work.

For a real service, add verification through its actual authentication and data-access path. Rerun the relevant checks when those boundaries change. Passing an in-memory example cannot establish that production middleware or credentials are configured correctly.

Where Linmas fits

Linmas provides defensive review skills and a scoped review workflow. A Review Capsule can preserve evaluated input, findings, policy decisions, and execution metadata. These artifacts help a person inspect what was reviewed and what evidence supports the result. They are not a security certification or automatic release approval.

For the broader method, read what security review means for AI-generated code. For a practical first pass, use the local tutorial linked above, then apply the same questions to one authorized change in your own project.

Before merging that change, identify one action an unauthorized caller should not be able to perform. Test it alongside the legitimate workflow. If the team cannot show where the boundary is enforced, the review still has a concrete question to resolve.

Sources and verification notes

Revised September 29, 2026. The Alice-and-Bob scenario is Linmas’s synthetic teaching fixture, not a production incident or a measured claim about the frequency of flaws in AI-generated code. The linked primary sources were checked on the revision date.