Neural
When an organization adopts a foundation model — whether as a hosted API, a downloaded open-weights model, or a fine-tuned variant — it is inheriting a supply chain it did not build and cannot fully inspect. The training data, the alignment process, the evaluation methodology, and in many cases the fine-tuning datasets that shaped the model's behavior are under the control of a third party or, in the case of publicly assembled models, no party at all.
This is a materially different risk profile from traditional third-party software procurement. A software library with a known vulnerability can be identified through CVE databases, patched, and replaced. A foundation model with a behavioral backdoor, a systematic bias, or a privacy-leaking tendency is harder to identify, harder to remediate, and harder to explain to regulators when it causes harm.
What the Foundation Model Supply Chain Actually Contains
Understanding the risk requires mapping what is actually in the supply chain. For a typical foundation model deployed through a hosted API, the supply chain includes: the pre-training dataset and its curation process, the alignment and RLHF process, the evaluation harnesses used to assess safety properties, any fine-tuning datasets used for domain specialization, and the serving infrastructure that processes requests. For an open-weights model that organizations fine-tune themselves, the supply chain also includes the model repository from which the weights were downloaded and the fine-tuning datasets sourced from public corpora.
Each of these components can be compromised. Pre-training data can be poisoned to create behavioral backdoors. Alignment processes can be gamed to produce models that appear safe during evaluation but behave differently in deployment. Fine-tuning datasets assembled from public sources can contain adversarially crafted examples designed to influence model behavior in specific ways.
Training Data Poisoning at Scale
Data poisoning attacks on foundation models are qualitatively different from attacks on smaller, specialized models. Foundation models are trained on internet-scale datasets assembled through automated crawling. The cost of influencing the composition of those datasets — by publishing content that will be crawled and included — is low relative to the potential impact.
Research has demonstrated that influencing a foundation model's behavior on specific topics requires poisoning only a small fraction of the training corpus. For a dataset of one trillion tokens, introducing a few hundred thousand targeted examples — a large but not infeasible amount of deliberately published content — can measurably shift model behavior on specific input patterns.
The implications for organizations using foundation models in trust-sensitive applications are significant. The model may have been subtly influenced by adversarial content in ways that are invisible in standard evaluation but emerge under specific operational conditions.
Model Weight Integrity
For organizations downloading open-weights models from public repositories, the integrity of the weights is a distinct security concern. Model weight files are binary artifacts that are difficult to inspect without running inference. A compromised model weight file — one that has been modified to introduce a behavioral backdoor — is not detectable through file hash verification alone if the attacker also controls the published hash.
Downloading a model from a public repository and deploying it to production without behavioral validation is the AI equivalent of running an unverified binary from the internet. Most organizations would not accept this practice in their software supply chain. Many are accepting it in their AI supply chain.
Model provenance verification — using cryptographic signatures published by model authors, combined with behavioral validation against known-good test cases — is the minimum bar for open-weights model deployment. Organizations in regulated industries should treat foundation model adoption with the same rigor as third-party software procurement: documented provenance, security assessment, and contractual representations where applicable.
Third-Party Fine-Tuning Datasets
Fine-tuning on domain-specific data is the standard way organizations adapt foundation models to their use cases. The security of this process depends entirely on the integrity of the fine-tuning dataset. Datasets assembled from public sources — GitHub repositories, Wikipedia dumps, legal document collections, medical literature — can contain content that was placed there specifically to influence models trained on them.
This is not a theoretical concern. Researchers have demonstrated proof-of-concept attacks where instructions embedded in publicly available documents cause models fine-tuned on those documents to exhibit specific behaviors. The attack requires only that the targeted content be included in the fine-tuning corpus — a condition that is easy to engineer for documents published in commonly scraped domains.
Fine-tuning dataset auditing — systematic review of dataset sources, content filtering for anomalous examples, and behavioral validation of fine-tuned models against held-out test cases — is the control that catches this class of attack before deployment.
Hosted API Dependencies
Organizations using foundation models through hosted APIs face a distinct supply chain risk: the model they are depending on can change without their knowledge or consent. API providers update model versions on schedules that do not always align with customer notification practices. When a new model version behaves differently from the version your application was built and tested against, the change reaches production before your team is aware of it.
This creates a risk that is invisible to traditional application monitoring: the code has not changed, the infrastructure has not changed, but the model's behavior has changed. Applications that depend on specific model behaviors for correctness — structured output generation, classification, policy compliance — are silently broken by model version updates.
Monitoring production model behavior continuously — not just at deployment — catches this class of change. When the behavioral baseline established for a model version shifts, the monitoring system surfaces the deviation regardless of whether a version update was announced.
Building Supply Chain Hygiene Into AI Procurement
The organizational response to foundation model supply chain risks requires integrating AI-specific questions into procurement and vendor management processes. For hosted API providers: what is the model update and notification policy? What security assessments are performed before major version releases? What contractual representations exist about model behavior?
For open-weights models: what is the provenance of the weights? What datasets were used for training and fine-tuning? What evaluation methodology was used to assess safety properties? What is the process for reporting and remediating behavioral vulnerabilities?
These questions do not have perfect answers — the foundation model ecosystem does not yet have the transparency standards that comparable questions in software procurement do. But asking them creates accountability, surfaces the risks that are present, and establishes a documented basis for the deployment decisions that organizations are making every day as they integrate foundation models into their operations.
