The AI Supply Chain Provenance and Security Act

By Achuthan Panikath

Mon Aug 03 2026

A model is an ecosystem Public debate treats an artificial intelligence model as a single artifact, as if a deployed system were one object with one author. In practice, a modern AI system is a supply chain: training datasets assembled from dozens of origins, pretrained base models built by other organizations, open-source libraries maintained by volunteers, third-party application programming interfaces (APIs), cloud infrastructure, evaluation harnesses, human-feedback pipelines staffed by contractors, fine-tuned model versions layered on model versions, and downstream applications that inherit all of it. Any link in that chain can carry a vulnerability, a poisoned dataset, a license violation, or a silent dependency on a component nobody remembers adopting.

Software engineering confronted this exact structure a generation ago and, after painful incidents, developed an answer: the Software Bill of Materials, or SBOM, a standardized inventory of a software product's components. When a critical vulnerability was disclosed in the Log4j logging library in 2021, organizations with component inventories could locate their exposure in hours; organizations without them spent months searching their own systems. Federal policy responded, and Executive Order 14028 on improving the nation's cybersecurity made SBOMs part of federal procurement practice.

Artificial intelligence has no equivalent. An organization deploying a high-impact AI system today typically cannot produce, and has never been asked to produce, a complete account of what the system is made of. This Act would create the AI equivalent of the SBOM and attach it to the systems where opacity is least tolerable.

The AI Bill of Materials Covered high-impact AI systems would maintain an AI Bill of Materials, or AIBOM: a standardized, machine-readable provenance record describing the system's material components and dependencies. The AIBOM would document the model's origin and version history; the major pretrained models incorporated or built upon; the datasets used in training and fine-tuning, at the level of identified dataset families; material external dependencies and security-critical libraries; third-party APIs on which the system relies in operation; known vulnerabilities in any component, tracked against public vulnerability databases; significant fine-tuning events and the data involved; evaluation results relevant to safety and security; and the deployment environment.

For the highest-risk systems, those whose failure or compromise could affect critical infrastructure, safety of life, or essential government functions, the Act would additionally require a cryptographically verifiable provenance chain, so that each component's inclusion is signed and tamper-evident. This mirrors the trajectory of software supply-chain security, where signed attestations are replacing self-reported inventories, and it matters most exactly where an adversary would have the most to gain from quietly substituting a component.

Scope: risk, not size The Act's obligations attach to systems, not to companies, and the covered class is defined by consequence. Sector regulators, the banking agencies for financial systems, the Food and Drug Administration for clinical systems, the Department of Transportation for vehicle autonomy, and their counterparts elsewhere, would determine which AI applications within their jurisdictions are sufficiently consequential to require compliance, against criteria the Act establishes: systemic impact, deployment scale, and the severity of plausible harm.

This design is the direct answer to the objection that provenance requirements crush small companies. A startup's chatbot for restaurant reservations would never be covered, whatever the startup's size or success. A small firm selling AI-based screening into hospital systems would be, and should be, because the patients bearing the risk do not care about the vendor's headcount. Thresholds keyed to company size would invite exactly the wrong evasion, large risks housed in small entities; thresholds keyed to risk cannot be gamed that way.

Governance The Act assigns roles to institutions already doing adjacent work rather than inventing a new regulatory universe. The National Institute of Standards and Technology (NIST) would develop the technical standards: the AIBOM format, the minimum required fields, and the cryptographic attestation specifications, extending its existing AI Risk Management Framework and its role in SBOM standardization. The Cybersecurity and Infrastructure Security Agency (CISA) would coordinate security-related reporting, including disclosure of newly discovered vulnerabilities in widely used AI components, extending the coordination function it already performs for software. Sector regulators would handle designation and day-to-day supervision within their industries, where the relevant risk expertise actually lives.

Enforcement, proportionate to risk Enforcement escalates with the stakes and begins with correction rather than punishment. An organization with a deficient AIBOM would first receive a notice of deficiency and a remediation order with a defined cure period. Continued noncompliance would draw civil penalties scaled to the system's designated risk tier. For systems sold to the government, noncompliance would carry procurement consequences: disqualification from federal contracts and, for the highest tier, suspension from high-risk federal work until compliance is demonstrated. Procurement leverage deserves emphasis, because it is how SBOM adoption actually spread through the software industry: the federal government is a large enough customer that its purchasing standards become de facto market standards without any penalty ever being assessed.

What this buys Provenance is not a compliance ornament; it is the precondition for nearly everything else AI governance hopes to do. Incident response requires knowing what a failed system contained. Vulnerability management requires knowing where a compromised component was deployed. Liability allocation requires knowing who supplied what. Dataset accountability requires knowing which data trained which model. Every one of those functions currently fails at the same first step: nobody can say what the system is made of. The AIBOM makes that sentence obsolete for the systems that matter most, at a cost, standardized documentation of facts a responsible engineering organization should already track, that is difficult to characterize as unreasonable.

Summary of the proposal Require designated high-impact AI systems to maintain a standardized, machine-readable AI Bill of Materials covering models, datasets, dependencies, APIs, vulnerabilities, fine-tuning events, evaluations, and deployment environment, with cryptographically verifiable provenance for the highest-risk tier. Assign technical standards to NIST, security coordination to CISA, and designation and supervision to sector regulators applying risk-based criteria. Enforce through remediation orders, tiered civil penalties, and federal procurement disqualification.

Key references Executive Order 14028, Improving the Nation's Cybersecurity (2021). NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0). NTIA and CISA materials on Software Bill of Materials minimum elements. Public post-incident analyses of the Log4j vulnerability. Sector regulatory frameworks governing safety-critical software in finance, medicine, and transportation.