Why AI-generated code still needs security testing

Start with the business rule

There is no single useful percentage of “insecure AI code” that describes every model, task and application. For your release, the actionable question is which trust boundaries changed and whether the application still enforces them.

Imagine an assistant adds an invoice download endpoint. The feature test checks that the owner can download a PDF. Add a second test: a different tenant must not download that same invoice, even when they know its identifier. Passing the first test says nothing about the second.

Review the server decisions

Map each new route to the identity, role and object ownership it requires. Enforce those decisions on the server for every request; hiding a button does not protect an endpoint. OWASP describes these principles in its authorization guidance.

Inspect query construction separately. Use parameterized queries for data values and restrict dynamic identifiers to approved choices. An ORM does not make a raw interpolated query safe. See the OWASP SQL injection prevention guide and Sintropyc’s SQL injection testing guide.

Inspect what the build actually ships

Review generated files as well as the proposed source diff. Check browser bundles and configuration for credentials that belong only on the server. A public client identifier and a privileged service credential need different treatment; document which kind you found before declaring a leak. Our Supabase guide covers that distinction.

For a new dependency, verify the package name, source, intended purpose and resolved version before accepting it. Include the lockfile in review. A generated import is a suggestion to verify, not evidence that a package is the correct dependency.

A practical release check

• List the routes, roles, data stores and integrations affected by the change.
• Run the intended behavior with a dedicated test account.
• Test a denied role, another owner and an unauthenticated session where relevant.
• Review query handling, secrets and dependencies alongside runtime checks.
• Record failures, apply the correction and repeat both allowed and denied cases.

Use deterministic regression tests for the boundaries you understand and exploratory testing for interactions that the test suite does not cover. Sintropyc’s API authorization guide separates object, function and property permissions so each can be checked deliberately.

For an authorized assessment of the running web application or API, see the Sintropyc Proof scan. Runtime testing complements source review; neither should be treated as a guarantee that all vulnerabilities have been found.