AI Coding Assistants: A Security Review Before You Merge

01 / Field notes

Executive Summary

AI-assisted code can look polished while implementing the wrong permission rule or omitting an important failure path. The review problem is not whether the code sounds confident. It is whether the change satisfies a concrete requirement without creating unintended access, data exposure or operational failure.

GitHub's responsible-use documentation discusses limitations and the need to review generated code. NIST's SSDF places verification within a broader secure-development process. [1][2] Apply those ideas to the actual diff: identify what authority the change creates, what data it touches and which tests would fail if the boundary were wrong.

This guide uses a fictional PHP admin feature. It is an acceptance method for assisted development, not a claim that AI-generated code is always insecure or that a particular assistant guarantees safety.

02 / Field notes

Prerequisites / Lab Setup

Begin with a small written requirement: an authorized editor may update articles they are allowed to manage; other users must be refused. Identify the existing authentication, authorization, CSRF, validation and database abstractions. The assistant should use those established boundaries rather than inventing a parallel shortcut.

Use a local branch, synthetic records and a disposable test account for each relevant role. Keep production secrets, customer data and private credentials out of prompts and test fixtures. Review the assistant's tool permissions as well as its output; a coding tool with deployment access can have effects beyond the code it proposes.

03 / Field notes

Technical Analysis

Read the diff as a change in authority

A form that hides an edit button is not authorization. A controller must check whether the current identity may update the particular article. A valid CSRF token does not grant permission; it helps establish that the state-changing request came through the intended user flow. Input validation and parameterized database operations solve different problems again.

These tests are about the requirement, not a mirror of the implementation. A test that merely asserts a helper function was called can pass while the wrong article is changed. Check the observable response and persisted state, including the absence of unauthorized changes.

Inspect dependencies and configuration changes

An assistant may introduce a package to solve a problem the application already handles. Review why the dependency is needed, how it is maintained, what code runs during installation and whether its license fits the project. Verify package names through authoritative sources rather than assuming a plausible name exists.

Configuration deserves equal attention. Disabling certificate checks, broadening CORS, weakening a content security policy or making an upload directory executable may make a test pass while undermining the system. Trace such changes back to the actual requirement and reject unnecessary weakening.

Require evidence for the failure paths

In the fictional admin change, the happy path updates a title correctly. The more revealing tests submit an invalid CSRF token, attempt a cross-owner edit and retry with an outdated revision. If those fail safely and leave the database unchanged, the evidence supports specific boundary claims. It still does not prove the whole application secure.

Read error handling too. A database exception should not expose credentials or a full stack trace to public users. Logs should contain enough context to diagnose failure without recording passwords, session cookies or full sensitive request bodies. Test the configured production behavior rather than relying on development defaults.

Keep review accountable as assistance grows

A second model can identify issues, but agreement between models is not independent proof. Both may miss the same assumption or rely on a fabricated API. Use documentation, executable checks and a maintainer's understanding of the system to resolve uncertainty.

Future assistants may produce larger changes faster. That makes bounded diffs, clear requirements and reproducible checks more valuable. Prefer changes small enough to understand and revert. If the reviewer cannot explain the new authorization path, the change is not ready merely because its tests are green.

04 / Field notes

Mitigation / Defense

For authentication state, see PHP session lifecycle. For deployment evidence, use release verification. Keep the final review grounded in what the application does, without claiming that either human or AI authorship guarantees correctness.

05 / Field notes

References

Sources checked 28 October 2026. The PHP scenario is illustrative and contains no exploit payloads. The guide does not prescribe a vendor-specific review interface, since those capabilities can change. It describes an accountable engineering process rather than a certification of generated code.

1. Responsible use of GitHub Copilot Chat in GitHub ↗GitHub · accessed 2026-10-28
2. Secure Software Development Framework, SP 800-218 ↗NIST · accessed 2026-10-28

Questions readers ask