AI Supply Chain Security: The Hidden Risks Behind Models, Datasets and AI Tools
A malicious model doesn't look wrong when you read it. Real cases of poisoned datasets, backdoored models, and compromised MCP servers, and how to actually verify what you're running.
In April 2026, a Hugging Face Space with a name deliberately close to a legitimate tool, vsccode-modetx, started serving a Go-based backdoor that used blockchain infrastructure for command and control. Tracked as CVE-2026-39987, it gave an unauthenticated attacker a full interactive shell on the machine of anyone who loaded it. Nobody had to click a phishing link. They just downloaded a model that looked like the one they were searching for.
Most supply chain security conversations still mean npm, PyPI, and container images. That conversation is real and important, but it covers maybe two stages of a pipeline that now has eight. A dataset, a pre-trained model, a fine-tuning run, an adapter, a model registry entry, and the framework loading all of it are each their own opportunity for something to go wrong, and almost none of them have the tooling maturity that software supply chain security has spent two decades building.
The one sentence to remember
A poisoned dependency in traditional software usually still looks like code when you read it. A poisoned dataset or a backdoored model doesn't look wrong at all, it just produces a model that behaves wrong later, in ways a code review was never going to catch.
This is a full walkthrough of the AI-specific supply chain: where real attacks have already happened at every stage from raw data to deployment, and the provenance tooling now emerging specifically because software supply chain security wasn't built for any of this.
The Pipeline Nobody's Securing End to End
Traditional SBOM tooling covers maybe two of these eight stages
Software Bill of Materials tooling and dependency scanning were built for the framework and plugin stages, tracking known libraries and known CVEs. They have nothing to say about whether a dataset was poisoned, whether a model's weights encode a backdoor, or whether an adapter quietly undoes safety behavior the base model shipped with. That gap is the entire subject of this article.
Poisoned Datasets
Data poisoning moved from an academic concern to a practical, documented attack surface in 2026: poisoned repositories, poisoned web content scraped into training sets, and poisoned datasets published directly to model hubs. The defining difficulty is asymmetric in the attacker's favor: a poisoned dataset doesn't announce itself, and once a model has trained on it, the resulting behavior is baked into the weights, not something a later scan can simply strip out.
Prevention beats remediation, because remediation barely exists
Cleaning a dataset after a model has already trained on it doesn't undo the training. In practice, a confirmed dataset poisoning incident usually means retraining from a trusted source, not patching the existing model. That asymmetry, cheap to poison, expensive to fix, is exactly why this stage deserves scrutiny before training starts, not after something looks wrong.
Malicious Models
A downloaded model file is not inert data the way a dataset or a config file is. Depending on its format, loading it can mean executing code, and attackers have built real, working techniques around exactly that fact.
The nullifAI technique
Security researchers documented over 100 malicious models exploiting Python's pickle serialization format, the standard way many models get packaged. The technique embeds malicious code at the start of the pickle byte stream and compresses the file with 7z instead of the default format, specifically to break Hugging Face's own PickleScan detection tool.
What these models actually do once loaded
Documented behavior includes reverse shells connecting back to hardcoded attacker infrastructure, credential theft, environment variable exfiltration, and secondary malware downloads, all triggered simply by loading the model the normal way, not by running anything unusual.
Typosquatting works on model names too
The CVE-2026-39987 case that opened this article is a model hub equivalent of typosquatting a package name: a name close enough to something legitimate that a rushed or unfamiliar download grabs the wrong one.
Treat a model file like an executable, because it often is one
"I'll just download the model and try it" is the exact habit that makes this attack surface work. A model from an unfamiliar or unverified source deserves the same scrutiny as running an unfamiliar binary, not the casual trust most people extend to a dataset or a config file.
Vulnerable Dependencies
The AI framework loading all of this, PyTorch, TensorFlow, and the libraries underneath them, is regular software with regular CVEs, and it's often the stage that gets the least scrutiny precisely because attention is focused on "the model" as the risk. A framework vulnerability doesn't care how trustworthy the model you loaded was; it's a separate, ordinary dependency risk sitting one layer underneath. Standard dependency scanning applies here exactly as it would to any other software stack, and skipping it because "it's just the ML library" is how this stage gets missed.
Unsafe Plugins and Compromised MCP Servers
Agent tooling extends the supply chain past the model entirely, into whatever plugins and MCP servers an agent connects to at runtime, covered in the malicious-tools section of AI Agent Security. That wasn't a one-off: between January and February 2026, a campaign that came to be called ClawHavoc infiltrated over 1,200 malicious skills into a popular agent marketplace, demonstrating that this specific attack surface, agent extensions published to a public registry, scales the same way malicious npm packages always have, just with far less mature screening in place today.
Model Provenance
The direct answer to almost everything above is being able to prove where a model, dataset, or adapter actually came from, and that it hasn't been modified since. Real tooling for this now exists, built specifically for this gap.
| Mechanism | What it provides |
|---|---|
| ML-BOM / AI-BOM | A bill of materials for a model: training data sources, architecture decisions, and safety benchmarks documented in one place, mapped to frameworks like NIST AI 600-1 and the EU AI Act's supply-chain provisions |
| Sigstore-backed model signing | Cryptographic signing so anyone using a model can verify it's the exact artifact its builder actually produced, not a tampered copy |
| OpenSSF Model Signing (OMS) | An emerging industry standard specifically for signing AI models, built on the same trust infrastructure as Sigstore |
| SLSA for ML pipelines | Supply-chain integrity levels, originally built for software, now being adapted to track provenance through training and fine-tuning stages the same way a software build pipeline is tracked |
Provenance is the practical alternative to trusting every download individually
None of this requires inspecting a model's weights by hand, which isn't realistically possible anyway. It requires verifying a signature and a documented chain of custody, the same shift software supply chain security made years ago when manually auditing every dependency stopped being feasible at scale.
Fine-Tuning and Adapters: The Quietest Risk in the Pipeline
A fine-tuned adapter gets shared even more casually than a full model, often as a small file layered on top of a base model everyone already trusts. That casualness is exactly the risk: an adapter trained on a poisoned dataset, or deliberately built to reintroduce behavior the base model's safety training removed, inherits none of the scrutiny that went into the base model itself. Trusting the base model is not the same as trusting everything layered on top of it, and treating an adapter as low-risk because it's small is precisely backward.
Deployment
Everything upstream, however carefully verified, still needs the deployment stage to contain what happens if something was missed. This is where sandboxing, covered in depth in AI Agent Security, earns its place again: an isolated execution environment limits the damage from a supply-chain compromise that made it all the way through, the same way it limits damage from a prompt injection or a malicious tool.
Risk Summary Across the Pipeline
| Stage | Real risk | Primary mitigation |
|---|---|---|
| Dataset | Poisoning, often undetectable after training | Verify data provenance before training, not after |
| Pre-trained model | Malicious code execution via formats like pickle | Model signing and provenance verification, treat unfamiliar models like executables |
| Fine-tuning | Reintroducing removed safety behavior | Evaluate fine-tuned outputs against the same bar as the base model |
| Adapters | Shared with less scrutiny than full models | Apply the same verification standard regardless of file size |
| Model registry | Typosquatting, unvetted uploads | Verify publisher identity, not just the model name |
| AI framework | Ordinary dependency CVEs | Standard dependency scanning, applied without exception |
| Plugins / MCP servers | Malicious or compromised tools at scale | Vet sources the way any other dependency gets vetted |
| Deployment | Whatever made it through every stage above | Sandboxing and least privilege, as a last line of defense |
The Bottom Line
The United States Department of Defense published formal guidance on AI and machine learning supply chain risk in March 2026, treating this explicitly as a national security concern, not a niche developer topic. That's the right level of seriousness for a pipeline where a single malicious model file, a single poisoned dataset, or a single compromised MCP server can undo every other security control built around it, simply because nothing downstream was ever built to question where the model actually came from.
The question worth asking before your next download
For the last model, dataset, or adapter your team pulled into a project, could you actually answer where it came from, who published it, and whether its provenance was verified, or did it just look right and come from a source that seemed familiar? For most teams today, that's still the honest gap.
Software supply chain security took two decades to mature. The AI supply chain doesn't have that long, because the attacks are already real, and they started before most teams even knew this was a pipeline worth securing.
Written by
Chetan Yamger
Cloud Engineer · AI Automation Architect · Modern Workplace Consultant
Cloud Engineer, AI Automation Architect, and Modern Workplace Consultant based in Amsterdam, Netherlands. Specializing in scalable, secure enterprise solutions with Microsoft Azure, Intune, PowerShell, and AI-driven automation using ChatGPT, Gemini, and modern LLM technologies.
Stay in the loop.
New articles, straight to you.
Deep-dive technical articles on Intune, PowerShell, and AI — no noise, no spam.
Discussion
Share your thoughts — your email stays private
Leave a comment