AI-generated code: a security review before you ship

Start with the changes that carry authority

Prioritise authentication, authorisation, payments, uploads, data exports and administrative actions. Ask a reviewer to explain what each sensitive change does and why the caller is allowed to do it. If nobody can explain the control, keep that change out of production until the team can review it properly.

Our suggested review record names the commit, affected feature, data touched, reviewer and acceptance test. Identify generated migrations and infrastructure changes as well as application code. A small interface change can conceal a much larger change to database access or deployment privileges.

Test the business boundary, not just the happy path

Create paired tests: an authorised user can perform the operation, while an unauthorised user cannot. Include another tenant, an expired session and a request that bypasses the interface. For retrieval features, test whether the service excludes documents the current user cannot access before they enter the model context.

Microsoft’s Azure AI Search documentation distinguishes service-level roles from document-level access controls. That distinction matters when reviewing a RAG feature: permission to query a service is not automatically permission to read every document. [1] The exact configuration and available features depend on your chosen implementation.

Protect the route from pull request to deployment

GitHub’s secure-use guidance recommends minimal workflow token permissions and warns about untrusted input and code in privileged workflows. It also documents OIDC for cloud authentication where supported. [2] Review both the pipeline configuration and the cloud trust policy; adopting a mechanism does not validate its settings.

For your release checklist, require an accountable owner for dependency updates, secret findings and build failures. Pin dependencies or actions according to the project’s update policy, verify where packages come from and review newly added install scripts. Avoid letting a generated workflow grant broad permissions merely to make a failing build pass.

Three checks that deserve release evidence

Leave a release record the next engineer can use

Our proposed handover contains the reviewed commit, test results, dependency changes, known limitations and rollback procedure. Record why an exception was accepted and when it expires. A scanner finding needs a disposition; silently ignoring it is not the same as assessing it.

After deployment, check the intended behaviour and the failure paths that matter to customers. Confirm who handles alerts and whether the previous version can be restored without losing required data. Use new privileged integrations, changed data flows and major dependency updates as triggers for another review.

A practical pre-release checklist

1. A named engineer can explain sensitive code and infrastructure changes.
2. Authentication and authorisation are checked on the server.
3. Dependencies, install scripts and secret findings have been reviewed.
4. Untrusted pull requests cannot inherit deployment authority.
5. Tests cover denied actions, not only successful demonstrations.
6. The release has an owner, known limitations and a recovery plan.

Questions buyers ask

Keep exploring

• AI security assessment or penetration test: what should you buy?
• MCP security: seven questions before connecting an AI agent