AI-Generated Code: Reviewing What Will Run

The final entry in OWASP's Next Steps section is X03:2025, Inappropriate Trust in AI Generated Code, also labeled “Vibe Coding.” It is additional guidance outside the ten selected categories.

The concern is accepting generated code without understanding and checking what it does. The X03 guidance places responsibility for submitted code with the people building the application.

That leaves a practical question for these notes: what evidence would make this change ready to merge?

A working feature can still miss a security requirement

Consider a hypothetical request to generate an endpoint that downloads an invoice. The result checks that a user is signed in, retrieves the requested invoice, and returns it. The normal test passes because the test user requests their own invoice.

The missing question is whether that user may access that particular invoice. If the endpoint accepts another customer's identifier without enforcing ownership or tenant permissions, the successful demonstration has missed an access-control problem.

Useful tests would cover an authorized request, a request for someone else's invoice, and an unauthenticated request. They should check the response and confirm that protected data was not returned. The OWASP Authorization Cheat Sheet covers permission checks on every request and tests for authorization logic.

This example could occur in human-written code too. AI assistance does not change the requirement that needs to be enforced.

Review the change in its actual context

A reviewer needs to understand the changed code, the surrounding behavior, and the assumptions it relies on. For the invoice endpoint, that includes where identity comes from, how tenant membership is established, and where access is checked.

Review also needs to cover less visible changes: a new dependency, a relaxed permission, a disabled test, or an altered deployment setting. A clear explanation from a coding tool can help navigate the change, but it needs to be checked against the diff and the actual test results.

The OWASP Secure Code Review Cheat Sheet recommends examining trust boundaries, data flow, business logic, and the effect of changes on existing controls. Automated checks complement that work.

Be careful with broad claims about AI code

Research has documented security problems in AI-assisted development. In a study published at CCS 2023, participants using an assistant based on codex-davinci-002 produced less secure solutions overall and were more likely to believe their code was secure. Those findings apply to the model, participants, and tasks studied; they are not a measurement of every current coding tool. Read the study.

The practical reason to review a change does not depend on a universal ranking of human and AI code. The application needs evidence that its requirements are satisfied.

Give tests their own requirements

Generated tests can be useful, but they may repeat the assumptions in generated code. For the invoice example, more tests of successful downloads would still miss the ownership check.

Write down the security properties first. Which identities should succeed? Which must be denied? What should happen if a dependency fails? What data must never appear in the response or logs?

Then check that the tests exercise those properties and actually run. Review any changes that delete assertions, skip tests, or weaken the expected result. Static analysis, dependency scanning, and secret scanning add useful checks without making every design or authorization decision for the team.

Tool access creates another boundary

Some coding tools can install packages, run commands, access the network, and modify repository settings. Their permissions deserve review alongside the code they produce.

Use an isolated environment where appropriate, restrict access to secrets and production systems, and keep consequential actions behind deliberate controls. Verify proposed dependencies before installing them. The OWASP Secure Coding with AI Cheat Sheet discusses these development-workflow risks.

Providing reviewed internal documentation can improve context. Connecting security tools through MCP can make checks available. The workflow still needs to require the checks, preserve their results, and prevent an unreviewed change from bypassing them. Supplying instructions alone does not establish that they were followed.

Questions for my notes

Can the reviewer explain what the changed code does?
Are the security requirements explicit and tested?
Were dependencies, configuration, and test changes reviewed too?
What can the coding tool access or change?
Who is responsible for accepting the result?

AI assistance can fit into a development process with clear requirements, limited permissions, and meaningful review. The useful checkpoint is the same one this series keeps returning to: identify the boundary, examine how it is enforced, and verify the behavior that matters.

Sources and further reading