AI code supply chain risk: a compliance playbook

The risks unique to AI-generated code that traditional SBOM / SCA tooling misses:

1. Hallucinated packages. The model invents a plausible-looking npm / PyPI / Maven package name that doesn't exist (or is registered by an attacker, a "package squat"). The agent imports it. The build pulls it. The attacker has code execution in your CI.
2. Training-data leakage. The model returns code that includes snippets from its training data. For open-weight models trained on open code, this is fine. For proprietary models trained on licensed code, this is a license violation. For models trained on customer data (which most aren't), this is a privacy event.
3. License violations. The agent suggests a copyleft (GPL, AGPL) dependency in a proprietary product. The product is now a derived work; the license requires source disclosure. Most legal teams don't know this happened.
4. Outdated or vulnerable dependencies. The model suggests a dependency that has a known CVE. The agent doesn't know; the SCA scanner does.
5. Hidden behavior in suggested code. The model returns a snippet that looks correct but does something subtle — a backdoor, a credential exfiltration, a network call to a non-obvious domain. Hard to catch with static analysis; needs a human reviewer or a behavioral test.

Each risk has a control. None of them are solved by "use a better model".

The regulatory map (mid-2026) for AI code supply chain:

• HIPAA (US healthcare): Training-data leakage is a Business Associate Agreement issue if the model was trained on PHI. Self-hosted inference for PHI-touching workloads is the cleanest answer. The Department of Health and Human Services has not yet issued AI-specific guidance, but the standard HIPAA Security Rule applies.
• GLBA + NYDFS (US finance): The same self-hosted argument. NYDFS Part 500 explicitly covers AI systems; an AI-generated code change touching customer data is in scope.
• FINRA (US broker-dealer): AI-generated trading code is in scope for the same reasons human-generated code is. Documentation of the development process is the audit trail.
• SOC 2 + ISO 27001 (general): The auditor wants to see documented controls. The scanning infrastructure + the policy + the runbook for "an AI-opened PR was rejected — what do we do?" is the audit artifact.
• EU AI Act (EU): High-risk AI systems (which includes some AI coding tools in regulated contexts) require documented risk management, data quality, transparency, and human oversight. The controls in this playbook map directly to those requirements.
• FedRAMP (US federal): AI coding tools used in federal contexts are in scope. The controls here are a starting point; the full FedRAMP authorization is a 6–12 month process.

The good news: the controls are the same across frameworks. Map once, document once, ship once.

Three controls, one for each risk surface:

1. Scanner. AI-aware SCA + secret scanning + license check in CI. Catches hallucinated packages, secrets in agent output, and license violations on every PR the agent opens. Tools: Snyk with AI packs, Semgrep with AI rules, open-source agentvfs for the workspace boundary, plus a custom rule for "package exists on the public registry" (catches the obvious hallucination cases).
2. Policy. A one-page policy on AI-generated code: what the agent can do, what it cannot do, the approval gates, the data classification rules, the audit log expectations. Reviewed by legal + security. Signed by the CISO. Reviewed annually.
3. Runbook. A runbook for the four incident types: hallucinated package discovered in production, training-data leakage suspected, license violation flagged by a customer, secret in agent output that made it to production. Each runbook has an owner, a triage checklist, and an escalation path.

End state: every AI-opened PR is scanned, every supply-chain risk is documented, every incident has a runbook, every auditor gets a one-page artifact.

A 4-week rollout for a healthcare or finance team:

1. Week 1: policy. Write the one-page policy. Get legal + security sign-off. This is the artifact the auditor will ask for first; everything else hangs off it.
2. Week 2: scanner in CI. Add the scanners to the existing CI. Start with secret scanning + license check (the lowest-risk controls), then AI-aware SAST (the highest-value). Wire the PR label so reviewers know which PRs are agent-opened.
3. Week 3: self-hosted inference for the regulated workload. Stand up vLLM / TensorRT-LLM / SGLang on the team's own cloud. An 8–16 week engagement for the full deployment; week 3 of this playbook is the discovery + sizing, with the build in the following weeks.
4. Week 4: runbooks + audit artifacts. Document the four incident-type runbooks. Build the audit-artifact template (what the auditor gets when they ask). Walk the auditor through the artifacts.

End of week 4: documented policy, scanner in CI, self-hosted inference sized and scoped, runbooks written, audit artifacts ready. The regulatory exposure for AI-generated code is the same as for human-generated code — which is the answer the auditor wants.

The auditor's question is always some form of "what is your residual risk and what are you doing about it?". The honest answer is "we have a scanner, a policy, and a runbook; here are the monthly numbers; the residual is X and we have a roadmap to Y".

The template:

1. Risk register. One row per AI-era supply-chain risk (the 5 above). Columns: risk, control, control owner, scan/audit frequency, last audit date, residual risk, remediation roadmap.
2. Monthly metrics. PRs opened by agent, scanned, blocked, accepted. Hallucinated packages caught (by week). License violations caught. Secrets caught. Time from PR open to PR merge, agent vs. human.
3. Annual review. CISO + legal + engineering owner sit down once a year. The risk register is the agenda. The output is the updated policy + the next year's roadmap.

The auditor sees a real program, not a slide deck. The insurance underwriter sees a real program. The customer sees a real program. The board sees a real program.

When to do this yourself, when to hire: