AI-Generated Code and Security Review: A Checklist for Product Owners
If AI writes a large share of your software, the old picture of security review, a senior engineer reading every change, no longer scales. It also was never the product owner's job. Yours is different: to make sure that, before anything ships, the right checks have been run by the right people, and that you can see the evidence. This checklist is organized by where in the build each check belongs, so you can ask for it at the right moment.
It builds on two earlier posts: what code review looks like when half the code is AI-generated, which covers the reviewer's side, and spec-driven development, which explains why the specification matters most.
Before the Build: Put Security in the Specification
1. Security requirements are written as acceptance criteria.
"The system is secure" is not a requirement. "Only a user with the approver role can release a payment" is. If security needs are not in the specification, a model has nothing to build to and nothing to be tested against.
2. Sensitive areas are named.
Sign-in, permissions, payments, personal data and anything touching a regulator should be listed explicitly. These are the areas where every change needs a person's review, whoever or whatever wrote it.
During the Build: Independent Checks
3. The tests are not written by whatever wrote the code.
A model that writes both can make its tests pass by changing the tests. Ask who writes them and whether the code-writing side can alter them. In Xamun's Software Factory, for example, the tests are written by a separate agent on a different model and locked from the code-writing agent.
4. Automated quality and security gates run on every build.
Static analysis, vulnerability scanning and checks for secrets such as passwords or keys left in code should block a release when they fail. Ask which tools are used, what thresholds apply, and what happens when a gate fails. "We review everything" is not a gate.
5. Dependencies are checked.
AI tools sometimes suggest libraries that are outdated, unmaintained or do not exist, and a lookalike package can be a way in for an attacker. Ask whether third-party components are scanned and who approves new ones.
6. A named person reviews the sensitive changes.
Not "the team." A named reviewer with security awareness, who has read the changes in the sensitive areas from point 2 and signed off.
Around the Build: Data, Tools and Environment
7. Prompts and data are controlled.
What can be pasted into an AI tool? Do real customer records or credentials ever enter a prompt? Is the tool environment isolated so your inputs are not used to train anyone else's model?
8. The software runs where you decide.
Ask where it is deployed and who has access. Deployment on your own infrastructure or cloud tenant, with access you control, reduces what you have to trust.
9. Compliance checks run per module.
If you handle regulated data (privacy, health, card payments), compliance scanning should happen as each module is built, not as a single check just before release.
After the Build: Traceability and Change
10. Every feature traces back to a requirement.
When the auditor, or your own team, asks why a piece of code exists, there should be an answer in the specification. This is also how you spot code no one asked for.
11. Rules that must never be wrong are deterministic.
A tax calculation or an approval limit should be enforced by tested, deterministic logic, with AI used where judgment helps. Ask what the system does when the model is switched off or wrong. We cover this in our post on the "Two Minds" architecture.
12. Change triggers re-checking.
When a requirement changes and code is regenerated, the tests and scans run again. Ask how the process proves that a change did not undo an earlier fix.
13. You own the result.
At handover, you should hold the source code, the specification and the test suite, so another team can audit or maintain them.
What Evidence to Ask For
For each item, ask to see something, not to be told something: the section of the specification, the tool configuration and last report, the list of dependencies, the sign-off record for the sensitive changes, the deployment diagram. A team that works this way can produce these in minutes. A team that cannot is telling you where the risk sits.
A Short Version for the Meeting
If you only have time for three questions: who writes the tests, and can the code-writing side change them? What blocks a release when a security check fails? Who is the named person who reviewed the sensitive changes?
If you are commissioning software and want a build process you can audit, tell us what you are building and how it needs to be reviewed.
About BlastAsia: BlastAsia is a Philippines-based software company that builds AI-powered software for enterprises worldwide, whether it's a new application or AI layered on the systems you already run. We build it AI-natively: specifications first, with code generated and reviewed on the Xamun Software Factory, so delivery is faster and more predictable. Engage us as a dedicated team (xDD) or as a fixed-scope Turnkey build, and you own what gets built.
Comments