AI supply chain compromise

Every AI system is assembled from parts someone else made. AI supply chain compromise is an attacker arriving through one of those parts rather than through code the victim wrote — MITRE ATLAS’s initial access technique AML.T0010, “compromising the unique portions of the AI supply chain”.

The six ways in

ATLAS splits AML.T0010 into hardware, the AI software stack, data, the model, a container registry, and the AI agent tool — the last added in March 2026, for agentic systems alone.

Two recorded incidents show the spread. In December 2022 someone uploaded torchtriton to PyPI under the name of a PyTorch dependency; “the PyPI index takes precedence”, so pip took the malicious one, which shipped $HOME/.ssh over encrypted DNS. In September 2025 an actor published a working postmark-mcp on npm, waited for a thousand weekly downloads, then shipped a version that BCC’d every email to them — a rug pull, filed separately by ATLAS because adoption evades the scrutiny new packages attract.

Why packages are the easy case

AI-specific artifacts do not behave like dependencies. Acquiring a model can be enough to execute the attacker’s code, because loading one “often requires executing some saved code in the form of a saved model file”. It is also harder to read than source. OWASP calls pre-trained models “binary black boxes” where “static inspection can offer little to no security assurances”, and NIST says organizations and researchers “may not be able to audit and identify vulnerabilities encoded into a model’s weights in the same way” they can open-source software — though NIST names mechanistic interpretability as a proposed route to backdoor features. Three of ATLAS’s four mitigations here address origin, not content: signature checking on artifacts, an AI bill of materials, and red teaming through the real acquisition path. The fourth watches the model’s output instead. ATLAS’s only content-side checks sit one level down: sanitizing training data, and validating an acquired model.

Where definitions disagree

ATLAS and OWASP both say “supply chain” and mean different sets. ATLAS’s is strictly adversarial and about the receiving end; publishing the artifact is a separate technique and tactic, publish poisoned AI artifacts. OWASP’s LLM03:2025 also counts risks no adversary caused — licence terms that “restrict usage, distribution, or commercialization”, models “no longer maintained”, unclear privacy policies. So “supply chain risk” in a vendor document may mean an attack or a licence review.

Questions and answers

How is an AI supply chain attack different from a software supply chain attack?

The mechanism is often the same and the artifacts are not. A poisoned npm or PyPI package is an ordinary dependency-confusion or rug-pull attack that happens to sit in an AI stack. What ATLAS adds under AML.T0010 are three artifact types an SBOM-era supply chain does not contain — the training data and its annotations, the pre-trained model, and the tools an agent can call. Those resist the defences that work on packages. OWASP states that models are "binary black boxes" where "static inspection can offer little to no security assurances", and NIST says organizations and researchers "may not be able to audit and identify vulnerabilities encoded into a model's weights in the same way it is often possible to audit open-source software".

Is a poisoned MCP server an AI supply chain compromise?

It is, when the poisoning arrives with the tool. MITRE ATLAS added an AI Agent Tool sub-technique, AML.T0010.005, on 30 March 2026, and it is the only one of the six restricted to the Agentic AI platform. Three case studies map to it, and AML.CS0053 is the only one ATLAS types as an incident rather than an exercise: an actor registered the unclaimed npm name postmark-mcp, published working releases until the package passed 1,000 weekly downloads, then shipped a version that added their address to the BCC line of every email the tool sent. Poisoning can also arrive after adoption, and that is not an alternative to supply chain compromise but a layer on top of it. ATLAS calls the late arrival a rug pull (AML.T0109), and says of AI Agent Tool Poisoning (AML.T0110) that poisoning "may be present when a tool is first published, introduced through an AI Supply Chain Compromise, or added after adoption through an AI Supply Chain Rug Pull". Postmark was all three at once: ATLAS maps it to AML.T0010.005, AML.T0109 and AML.T0110.001 together.

What stops an AI supply chain compromise?

Mostly provenance rather than inspection, because the artifact is hard to inspect. MITRE ATLAS maps four mitigations to the parent technique. Three establish where the artifact came from, or find out what happens when something untrusted gets in — signature checking on artifacts before they enter the system (AML.M0014), an AI bill of materials so a later disclosure can be traced to the systems that inherited the artifact (AML.M0023), and red teaming that introduces controlled untrusted models, data and agent tools through the real acquisition path (AML.M0035). The fourth does not read the artifact either — guardrails watch what the model emits, on the grounds that they "can detect harmful code in model outputs" (AML.M0020). Content-side checks do exist, but ATLAS files them one level down, on the sub-techniques: sanitizing training data on the Data sub-technique (AML.M0007) and validating an acquired model against backdoor triggers on the Model sub-technique (AML.M0008).