The CISO checklist for AI-generated software

The security question about AI-generated code is usually asked backwards. "Is AI code less secure than human code?" invites a study-citation contest and misses the operational point: AI changes the volume, velocity and authorship of code, and those three shifts break the assumptions your existing assurance program was built on. Annual pen tests assume the codebase changes slowly. Manual review assumes a human author who understood the change and can answer for it. Sampling assumes the unsampled code resembles the sampled code. Under AI development, none of those hold.

So the CISO-level requirement is not a verdict on model quality — models will keep changing under you anyway. It is a set of properties the development system must have regardless of which model wrote the code: every change attributable to a prompt, a person and an approval; consequential changes gated by policy before merge; security testing that runs continuously and confirms findings against the live application rather than flooding you with static noise; and an immutable record good enough to reconstruct any change for an auditor or an incident review.

Framed that way, AI development is not a new risk category demanding a new theory. It is a familiar category — change management at scale — demanding better machinery. The checklist below is that machinery, written as requirements you can put in front of any vendor or internal platform team.

Posture matters as much as controls. The productive stance is to assume AI-generated software already exists in your organization — because it does — and to make the governed path the attractive one rather than announcing a ban that drives building further into the shadows. Security teams that publish a sanctioned route with clear controls get visibility and adoption; teams that prohibit get neither, plus the same risk. Every requirement below serves that strategy: each one makes the safe way to build also the easy way to answer for what was built.

Start with what is already true: business units are generating applications with AI tools today, mostly outside security's field of view. The realistic near-term incident is not an exotic model attack; it is an unreviewed AI-built app with an over-permissive database policy quietly exposing customer records, discovered by a customer. Shadow AI development is shadow IT with a code generator attached, and it inherits every classic failure — unknown data flows, unpatched dependencies, no owner — at much higher production speed.

Inside engineering, the risk is subtler: erosion of review under volume. When agent-generated pull requests triple and reviewer headcount does not, approval either becomes the bottleneck that kills the productivity gain or becomes a rubber stamp that kills the control. Both outcomes are bad, and organizations that never made the choice explicitly usually get the second one by default. The only stable answer is triage by policy — machines clear the routine, humans review what rules flag as consequential — with the policy itself owned by security, not by whoever wrote the prompt.

And when something does go wrong, the incident-response question becomes the whole game: can you reconstruct what changed, who or what changed it, what testing ran, and who approved it? If the honest answer is a chat log in a departed contractor's account, you do not have an assurance program for AI development. You have exposure with good intentions.

Expect external pressure to rise as well. Auditors, cyber insurers and enterprise customers have started asking direct questions about AI-generated code in security questionnaires and vendor assessments — how it is reviewed, what testing gates it, whether provenance exists. Organizations that can answer from an audit trail will pass those reviews as routine; organizations improvising answers will feel each one as a fire drill. Building the evidence machinery now, before a specific auditor demands it, is materially cheaper than building it during a finding.

Ciao's governance layer was designed against exactly this checklist. Guardrails maps code into business areas, detects risky changes, applies plain-English policies, records human review and leaves an audit trail behind every merge; the trail is append-only and covers prompts, merges, deploys and admin actions. Security runs static scanning, dependency checks and access-control probes, and confirms vulnerabilities against the live app before flagging them — the difference between a findings feed your team trusts and one they mute. QA gates every publish with deterministic browser replays and runs production checks after.

On the vendor-risk side: SOC 2 Type II reports are available under NDA; the platform supports SSO via SAML and OIDC, optional MFA and role-based access control; customer code is not used to train models and inference runs under zero-retention model contracts; and a multi-provider model ladder with fallback reduces dependency on any single model vendor. Deployment targets include your own AWS, Azure or GCP account, private VPC, or on-prem under separate terms for classified workloads. Serious development programs start at USD 10,000 per year. If you are building the internal standard for AI development, request the security pack and score Ciao against every line above.

A rollout suggestion from teams that have done this well: sequence it as inventory, then sanctioned path, then migration. First find what AI-built software already exists and who owns it; second, stand up the governed platform and route new builds through it; third, move existing tools across in blast-radius order. Publishing the checklist itself as your internal standard — whatever platform you choose — turns a diffuse worry into a scored, ownable program, and it gives business units a clear answer to "what would make this okay?" rather than a closed door.