AI supply chain attacks: what they are and how to defend against them

Imagine a developer on your team is setting up a new computer vision pipeline to gate physical access to your company's office. They need a base model, so they do what everyone does: search popular online registries like GitHub or HuggingFace, find something with good stars and recent commits, pull it down, and get to work. The model performs well in testing. Six months later, the app quietly starts letting anyone in. What happened?

The model was backdoored before your team ever touched it, hiding a malicious function within its architecture. It was trained to recognize faces accurately in almost every case, except that it had a kill switch that the attacker controlled. Your team's testing never caught it because the model was genuinely good at its job. It just had a second job your team didn't know about.

That's what makes AI supply chain attacks different from most threats security teams are trained to handle. It's worth being specific about what "AI supply chain" actually means here, because it's easy to conflate with something more familiar. This isn't about AI-powered attackers targeting your traditional software stack. It's about the supply chain that exists specifically around AI components. There's no break-in to detect, no phishing email to trace, no CVE to patch. The compromise arrived within something your team chose to trust and deployed intentionally. This is a genuinely new attack surface, and most organizations don't yet have the habits or tooling to monitor it the way they monitor everything else.

This article walks through what AI supply chain attacks are, the common tactics threat actors use, some recent incidents worth paying attention to, and the practical steps teams can take to improve their AI security.

What is an AI supply chain attack?

An AI supply chain attack is any compromise that targets the components feeding into an AI system rather than the system itself. Instead of attacking an AI system head-on, an AI supply chain attack goes after the things that feed into it: the data it was trained on, the packages it uses, or the infrastructure it runs on. That includes the model weights, training datasets, ML frameworks, container images, CI/CD pipelines that ship AI workloads, and the agent plugins or skills developers install to extend their tools. Vulnerabilities can be introduced maliciously by a threat actor or discovered accidentally in trusted open-source components, and either way, the downstream blast radius is significant.

The risk of AI supply chain attacks has grown in direct proportion to adoption. As teams lean harder on free and open-source models from various providers to ship AI features quickly, the registries hosting those models become high-value targets. Attackers understand that a single poisoned artifact in a popular repository can reach thousands of downstream AI-driven applications, which is a much better return on effort than attacking any one of those applications individually. If you want a longer look at how registries became the riskiest part of the modern stack, Chainguard's piece on “why your riskiest supplier isn't a vendor, it's a registry” is worth a read.

What are some common AI supply chain attacks?

The tactics vary, but these attack vectors share a common logic: hackers will compromise an upstream AI component that many teams trust, and let that trust do the distribution work. Here are the patterns showing up most often.

Poisoned AI artifacts. Attackers publish malicious packages and versions of legitimate AI tools or models to public registries such as Hugging Face and PyPI, often using typosquatted names or impersonating popular maintainers through phishing. Developers pull the package thinking they've got the real thing, and the payload runs the moment the model is loaded or the library is imported.

Compromised ML frameworks and toolkits. The open-source frameworks teams use to build, train, and deploy models (PyTorch, TensorFlow, ONNX Runtime) are themselves supply chain targets. If an attacker injects malicious code into a framework update or a widely-used plugin, every model built or served through that toolchain inherits the compromise. A single upstream dependency becomes a vector that affects thousands of downstream AI applications.

Model backdooring, sometimes called Trojaning. Here, the attacker modifies the model's weights so it behaves normally 99% of the time, and then executes a specific behavior when it encounters a trigger, which might be a particular word, a specific pixel pattern, or a crafted input sequence. Behavioral testing against a validation set won't catch it, because the model genuinely performs well on everything except the trigger.

Tampered AI container images. Container images for ML workloads (CUDA runtime, TensorFlow Serving, Jupyter notebook bases) are routinely pulled from public registries to speed up deployment. A single backdoored base image can propagate malicious code across training pipelines, model serving infrastructure, and developer environments. Since these images are layered into everything, the compromise reaches places nobody was specifically thinking about when they pulled the base.

Data poisoning during training. Rather than attacking the model after it exists, attackers manipulate the training data to introduce a bias they can later exploit. A classic example is training a security camera model on data that teaches it to ignore a specific type of clothing, so a person wearing it walks past undetected. OWASP has a solid write-up on training data poisoning in the LLM context if you want to go deeper.

Compromised CI/CD pipelines for AI workloads. The pipelines that build and deploy AI applications are themselves high-value targets. Tag hijacking, dependency confusion, and secret exfiltration via logs all allow attackers to inject malicious code into trusted workflows before the model or application ever reaches production. The compromise occurs between "verified source" and "deployed artifact," a gap most teams overlook.

Malicious AI agent plugins and skills. As AI coding assistants and autonomous agents become everyday development tools, attackers have started publishing poisoned plugins, skills, and extensions to public registries. A single malicious skill can grant shell access to a developer endpoint, exfiltrate API keys, or quietly alter the AI-generated code an agent produces across every project that installs it. This category barely existed eighteen months ago, and it's now one of the fastest-growing vectors.

What are some recent AI supply chain attacks?

These attacks have moved from theoretical to routine. The incidents below represent different flavors of the problem, and together they give a reasonable picture of what defenders are up against.

If you're tracking this space more broadly, GovInfoSecurity's coverage of how AI is driving software supply chain attacks is a useful companion read.

How can you protect against AI supply chain attacks?

The guidance here isn't radically different from traditional supply chain risk management; it just needs to account for the fact that AI artifacts behave differently from ordinary software dependencies. Chainguard's Securing AI course walks through this in more depth if you want structured training.

1. Focus on model provenance

You can't defend what you can't trace. Knowing where every model and dataset came from, who published it, and whether anything has changed since you pulled it down is the baseline. In practice, that means verifying cryptographic hashes against the publisher's manifest before loading any model, and tracking those hashes in an AIBOM(an AI Bill of Materials) so you'd know immediately if a weight file changed between pulls. Provenance tracking lets you catch the moment an upstream artifact shifts underneath you, before a backdoored model has been quietly running in your pipeline for months.

2. Conduct regular security testing

Functional testing alone won't catch a backdoor, because backdoored models are designed to pass functional tests. Behavioral analysis that probes for hidden triggers and unexpected responses to edge-case data is what actually surfaces this class of issue. Concretely, that looks like running adversarial input suites against your models in staging, specifically designed to probe for outputs that shouldn't be possible given the model's stated training. Testing needs to be ongoing, not a one-time gate at deployment.

3. Closely manage dependencies

Scan dependencies regularly, lock versions, and make sure nothing new can slip into a build without explicit approval. In practice, tools like pip-audit or Dependabot catch known vulnerabilities in libraries, but you also need to pin container image digests rather than tags, since a tag like latest can be silently overwritten. This extends beyond libraries to CI/CD actions, which are a frequently overlooked attack surface. Pipeline actions pulled from public marketplaces can be hijacked or spoofed, turning a trusted build step into an entry point. Chainguard's post on guarding the Python ecosystem against severe malware attacks covers how this plays out in practice.

4. Lock down all machine permissions

AI agents and the service accounts they run under should operate with the minimum permissions they need. In practice, that means scoping agent tokens to read-only where possible, keeping write access off by default, and requiring explicit approval workflows before an agent can push code or deploy artifacts. Hardened rulesets that structurally limit what an agent can access are far more reliable than expecting developers to manually restrict permissions.

How Chainguard can help protect you from AI supply chain attacks

A lot of AI supply chain defense comes down to the quality of the artifacts entering your stack and the level of security automation in place. That's where Chainguard fits.

Chainguard Containers and Chainguard Libraries give you zero-CVE images and verified open-source packages built from source with full provenance. The goal is to structurally prevent malicious code and compromised dependencies from reaching your developers, rather than catching them after the fact with a scanner. The Chainguard and Cursor partnership is a good real-world illustration of this in action: Cursor users get Chainguard artifacts wired directly into their workflow. The Chainguard x Cursor video tutorial walks through how it looks in practice. For a broader view on AI workload protection, Chainguard's write-up on protecting AI workloads from supply chain attacks is the best starting point.

Chainguard Actions brings the same philosophy to the CI/CD layer. Secure-by-default workflows built from verified sources are designed to prevent tag hijacking, dependency confusion, and secret exfiltration in the pipelines that deliver AI applications. Adoption is straightforward: in most cases, it's a drop-in replacement for the actions you're already using, requiring a single config change.

Chainguard Agent Skills (currently in beta) takes the protection a step further, right down to the AI agent layer. These are purpose-built rulesets that harden AI coding assistants and agents against exactly the sort of skill-based attacks that made ClawHavoc possible. Installing a hardened skill is as simple as adding a single SKILL.md file to your project, and the catalog is self-healing, meaning skills get re-hardened as new threats emerge. You can also read what cybersecurity professionals are saying about AI risks for more context on how the industry is thinking about this shift.