«AI supply chain attack» is used to mean four different things, and conflating them produces a threat model that defends the wrong layer. Separating them first makes the evidence legible.
The four layers
| Layer | What an attacker gets | Confirmed at scale? |
|---|---|---|
| Software packages | Code execution on developer and CI machines | Yes — repeatedly |
| Model weights | A model that behaves differently on a trigger | Rare in the wild |
| Training and reference data | Influence over outputs | Demonstrated in research |
| Runtime tools and content | Instructions the agent will follow | Yes — routine |
Rows one and four carry the confirmed incidents. Rows two and three carry most of the conversation. That gap is the single most useful thing to know about this subject.
Layer 1: packages, where it actually happens
On 20 August 2026 three crates on the Rust registry — arrayref 0.3.10, append-only-vec 0.1.9 and internment 0.8.7 — were published carrying a dependency called proc-macro1. No such crate belongs in a normal build; it is a typosquat of proc-macro2, one of the most widely used packages in the ecosystem, and it existed to be mistaken for it.
The malicious code sat in build.rs, the script Cargo executes during compilation. Nothing had to be launched for it to fire — compiling was enough. It reconstructed its infrastructure from base64 fragments, selected a payload matching the host, and read the SQLite login databases used by Chrome, Brave and Edge.
| Time (UTC) | Event |
|---|---|
| 01:17 | A fake developer account is created |
| 01:55 | A clean proc-macro1 1.0.106 is published, establishing the name |
| 07:11 | proc-macro1 1.0.107 arrives carrying the payload |
| 07:15 | arrayref 0.3.10 goes up; earlier versions are pulled so builds resolve to it |
| 07:54 | The incident is reported |
| 08:03–08:41 | The malicious packages are removed |
The exposure window was about ninety minutes, against a crate with 245 million lifetime downloads and 53 million in the preceding ninety days. Ninety minutes sounds survivable until you count what runs continuously: CI pipelines, container image builds, dependency refresh jobs. A short window is not a narrow one.
Nothing about this attack is specific to AI. It is included here because AI projects have unusually deep dependency trees, unusually fast-moving ones, and a culture of pulling the latest — which makes them a better target for exactly this, not a different kind of target.
Layer 4: tools and content at runtime
The second layer with routine confirmed compromise is the one that only exists once a model is deployed as an agent. Anything the model reads is a channel for instructions: a fetched page, an uploaded document, a tool response. This is prompt injection, and it belongs in a supply-chain discussion because the content arrives through channels the system trusts.
The distinguishing feature is that no code is compromised. The system runs exactly as written; it is the input that was hostile, and there is no signature to detect.
Layers 2 and 3: where the attention goes
Poisoned weights and poisoned training data are real attack classes with real research behind them. What they lack, so far, is a body of confirmed large-scale incidents. That may change; treating it as already having changed leads organisations to build elaborate model-provenance programmes while their build pipeline resolves dependencies to latest.
The proportionate response is to know the provenance of weights you deploy, pin them, and spend the remaining effort on layers one and four.
How much AI-enabled malware is actually out there
Unit 42 published the count in August 2026. It collected 405 unique malware samples integrating AI capabilities, from WildFire reports, VirusTotal Intelligence and open-source research, then asked how many had ever been on anyone's machine.
- 12 of 405 — three percent — were seen on endpoints.
- Roughly fifteen to twenty unique hashes, about four percent, appeared in production environments via firewalls.
- About 97% existed only in sandboxes and repositories: proof-of-concept code, security validation submissions, and malware branded as AI with no functional AI integration in it.
Five families made it into production, including FunkSec ransomware and a trojanised application that reached more than fifty organisations. The finding that matters for a defender is what Unit 42 concluded about detecting them: existing behavioural detection, cloud sandboxing and endpoint analytics caught these through the same mechanisms that stop conventional malware. No new detection method was required.
What this argues for
| Do | Because |
|---|---|
| Commit lockfiles and honour them in CI | A fresh resolve is how a new transitive dependency arrives silently |
| Hold back new versions rather than resolving to latest | The ninety-minute window closes before a delayed build reaches it |
| Alert on new transitive dependencies, not just direct ones | proc-macro1 was added by nobody's hand |
| Treat build scripts as executed code in review | Because that is what they are |
| Pin model weights and know their provenance | Cheap, and closes the layer you cannot otherwise inspect |
| Keep spending on behavioural detection | It already catches the AI-enabled samples that reach endpoints |
There is a version of this subject that recommends a new product category named after the adversary's toolkit. The evidence does not support it. What the evidence supports is doing ordinary supply-chain hygiene properly, in ecosystems that move faster than the ones those practices were designed for.
Questions
- Is AI-enabled malware a serious threat yet?
- It exists and it reaches endpoints, but rarely: 12 of 405 collected samples, by Unit 42's August 2026 count. More importantly, the ones that arrive are caught by the same behavioural detection that catches conventional malware, so the practical answer is to keep those controls funded rather than to buy something new.
- Should we audit the weights of every model we deploy?
- Know their provenance and pin them — that is cheap and worth doing. A full audit of weights is not currently proportionate: poisoning is a demonstrated research capability rather than a source of confirmed large-scale incidents, while the package layer produces them regularly.
- Why does a build script matter more than a runtime dependency?
- Because it executes before anything is run. In ecosystems that execute code during installation or compilation, an attacker gets execution the moment a developer or a CI job builds the project — no deployment, no launch, no user action required.
- Does prompt injection belong in a supply-chain discussion at all?
- Yes, because the hostile content arrives through channels the system trusts — its own tools, its own fetches. It differs from the other layers in that no code is compromised and there is nothing to detect by signature, which is why it is defended by bounding what the agent can reach rather than by scanning.