Why do poisoned model files create a supply chain risk for AI teams?

Because the downloaded model can differ from what the repository page appears to show. If the template inside the file is malicious, every later interaction can be influenced without changing the model weights. That turns model distribution into a supply chain control problem, not just an application security problem.

How a poisoned model file turns distribution into a supply chain problem

A poisoned model file is risky because the object being delivered is not just a set of weights, it is also a packaged artifact that teams trust to behave in a certain way when loaded, referenced, or wrapped in tooling. If the file contains malicious templates, scripts, metadata, or embedded behaviours, the compromise starts before the model is ever used in production. That shifts the trust question from “is the model accurate?” to “is the artifact authentic and safe to consume?”

That distinction matters because AI teams often source models from registries, hubs, mirrors, or internal caches, then reuse them across experiments, environments, and products. Once a poisoned artifact enters that chain, every downstream user inherits the same bad trust decision. A single tampered file can therefore affect many pipelines, not just one notebook or one application.

The right mental model is software supply chain security: provenance, integrity, and controlled distribution are part of the control surface. An AI model should be treated as a build input with measurable trust properties, not as a passive blob that becomes dangerous only after inference begins. SLSA is useful here because the core issue is artifact provenance and integrity, even when the artifact happens to be a model rather than compiled code.

What is actually being manipulated inside the file?

Poisoning does not have to mean changing weights. A repository can present one thing on the page while the downloaded artifact contains a different template, loader, or serialized structure that changes how later interactions are handled. In practice, the malicious payload may influence prompts, logging, routing, tool calls, or data handling without leaving an obvious signature in the model card or README.

That makes the attack subtle. Teams may review benchmarks, sample outputs, and documentation, yet still ingest a file that behaves differently when deserialized or wrapped in downstream code. The dangerous part is not only the model’s predictions, but the trust placed in the artifact and the surrounding workflow that accepts it as legitimate.

This is why artifact verification has to include more than “the file exists in the expected repo.” Hashes, signatures, release provenance, and controlled publishing paths all matter. NIST SSDF (SP 800-218) is a good fit because it frames secure development and release practices around protecting the integrity of what gets shipped.

Why AI teams should treat model poisoning as supply chain trust failure

For AI teams, the supply chain risk is not limited to malicious weights or obviously broken outputs. The larger concern is that a trusted artifact can become a delivery vehicle for behaviour that is hard to see during review and easy to reuse at scale. That is especially true when models are pulled into CI pipelines, experimentation platforms, or shared internal registries.

Once that artifact is consumed by multiple people or services, the blast radius expands. A poisoned file can be redistributed internally, cached in deployment systems, or embedded in a product release. In other words, the initial compromise of one downloaded object can become a repeated trust failure across the lifecycle of the model.

That is why supply chain controls must apply to models as rigorously as they apply to packages or container images. Teams need provenance checks, allowlisted sources, content integrity verification, and review of any embedded templates or serialization logic before the artifact is promoted. The OWASP Non-Human Identity Top 10 is also relevant when model workflows rely on credentials, tokens, or automated publishing paths, because poisoned artifacts often become dangerous when coupled with trusted machine-to-machine access.

Risk and Threat Considerations

Poisoned model files create a classic trust-boundary problem: the artefact can look legitimate while carrying behaviour that alters downstream interactions, exfiltrates data, or hijacks adjacent tooling. The risk increases when teams rely on shared registries, automated pulls, or weak provenance checks, because the same poisoned object can be redistributed widely before anyone notices.

Failure mechanism: Attackers tamper with the distributed artifact, then rely on deserialization, wrapper logic, embedded templates, or later integration steps to activate the malicious behaviour after the file has already passed initial review.

Impact: The result can be silent influence over prompts, outputs, logs, or connected systems, plus wider exposure if the same artifact is reused across experiments, staging, and production.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Model files are distributed artifacts, so provenance and integrity controls directly apply.
Recommendation — Require provenance and integrity verification before promoting downloaded model artifacts.
NIST SP 800-53 Rev 5	SR-11 — Component Authenticity	The question is about trusting a delivered artifact before use, which depends on authenticity checks.
	SI-7 — Software, Firmware, and Information Integrity	Poisoned model files are an integrity failure in a software-like artifact supply chain.
	IA-5 — Authenticator Management	Model workflows often depend on tokens or keys for distribution and publication access.
Recommendation — Verify artifact authenticity before acceptance and downstream reuse. Validate integrity controls on model artifacts before deployment. Manage and rotate publishing credentials used in model distribution.
ISO/IEC 27001:2022	A.5.21 — Managing information security in the ICT supply chain	Model distribution is a supply-chain trust problem that fits ICT supply-chain control governance.
Recommendation — Apply supplier and artifact assurance checks to model distribution paths.

Practitioner Guidance

What to verify: Treat model intake like a release gate. Verify source provenance, hash consistency, signing where available, and whether the downloaded file actually matches the repository metadata, release tag, and expected format.

What good looks like: Good control means the team can explain where the model came from, how it was validated, who approved it, and what artefact-level checks prevented promotion of a tampered file. If you cannot produce that trail, the model should not be treated as trusted input.

Practitioner takeaway: The key decision is not whether the model “works,” but whether the artefact can be trusted to remain what the repository claimed it was across every later use.