A Security Checklist Before AI-Generated Code Touches Real Data

This is an AI-generated code security checklist for the moment that matters, which arrives well after a model writes an app: the moment that app is about to touch real data. By then, reading the code line by line has stopped being the control, because a fleet of agents can produce more software than any team can review. What you can still do is verify the environment the code runs in. Each item below is one thing to check and why it matters. If the only way you can tick these is by trusting individual artifacts, the gap is still open. The goal is a runtime that guarantees them by default.

1. Isolation: is there a hard per-tenant boundary?#

• Check: every AI-built app runs inside its own isolated tenant with a strong boundary, ideally a microVM rather than a shared container on density-first infrastructure.
• Why: NIST SP 800-190 warns that containers on a shared host offer weaker separation than VMs, so a compromised or buggy app can reach its neighbors' data. Shared runtimes turn one bad app into everyone's incident.

2. Identity: what does the app act as?#

• Check: the app authenticates under a scoped, per-app identity with short-lived credentials, and never a shared API key or a broad service account cloned across apps.
• Why: OWASP's Non-Human Identities Top 10 ranks secret leakage as a top risk and recommends replacing static secrets with short-lived, on-demand credentials, because a leaked shared key lets an attacker impersonate every app that uses it.

3. Least authority: is it deny-by-default?#

• Check: the app holds an explicit allowlist of capabilities and reachable destinations, with egress and data access denied unless named.
• Why: NIST SP 800-207 defines zero trust as "least privilege per-request access decisions" with no implicit trust zones. OWASP lists Excessive Agency (LLM08) precisely because models granted more reach than the task needs will eventually use it.

4. Auditability: can you answer "what ran, and who approved it?"#

• Check: every execution produces an attributable log covering which app, acting as which identity, touched which records, when, and under whose approval, captured automatically rather than left to the app to emit.
• Why: OWASP's Agentic AI threat guidance calls for traceability of agent actions. Without a per-execution trail, an incident review and a SOC 2 auditor ask the same unanswerable question about your data.

5. Provenance: is the running code the approved code?#

• Check: each app is signed before it runs, and the runtime verifies that what is executing matches what was approved, with drift detection that blocks anything that has changed.
• Why: approval is meaningless if the artifact can mutate afterward. Signing plus verification is what lets you say the thing on production is the thing that passed review, rather than a silently altered descendant.

6. Compliance: who is the processor of record?#

• Check: there is a named party accountable for how the generated software handles data, so each new app inherits a SOC 2 / HIPAA / GDPR posture and skips re-proving it from scratch.
• Why: most code generators write the code and leave, and they will decline to sign on as your subprocessor. If nobody owns the runtime's compliance posture, every shadow app becomes a fresh audit finding.

7. Blast radius: what is the worst case if it's wrong?#

• Check: assume the app is buggy or hostile and trace the ceiling, covering which tenant's data, which destinations, and which credentials are reachable. The answer should be small and bounded.
• Why: AI code is often functionally correct and quietly insecure, so design for the app being wrong. Items 1 through 3 exist to keep this last answer contained.

Turning the AI-generated code security checklist into a default#

Read the seven items again and one thing stands out: almost none of them can be satisfied by editing the code. Isolation, scoped identity, deny-by-default egress, per-execution audit, signature verification, and a processor of record are all properties of the place the code runs. A team can bolt each one on per app, and most teams can't do it consistently across a growing fleet of AI-built tools. The teams that tick every box do it because their runtime provides these guarantees by default, so approval happens once and every future app inherits it.