AML.T0010 Supply Chain Compromise

AI systems are assembled from parts you did not build: frameworks, pre-trained models, public datasets, container images and, increasingly, agent tools, and an adversary who tampers with any of them reaches every system that consumes it. MITRE ATLAS records this as AML.T0010 Supply Chain Compromise, an Initial Access (AML.TA0004) technique rated Realized, mirroring ATT&CK T1195. The ATLAS 2026.10 release defines six sub-techniques: Hardware, Software, Data Repository, Model Repository, Container Registry and AI Agent Tool. This guide covers the AI-specific angle of each, the incidents and exercises ATLAS records, the ten mitigations ATLAS maps, and how to detect and recover. It is for AI platform, MLOps and agent engineering teams and the security teams that support them. The general software supply chain technique is covered in MITRE ATT&CK T1195 Supply Chain Compromise; this page does not repeat it.

Key takeaways

Six entry points, one pattern. ATLAS says compromised components may introduce malicious executable behaviour, alter model behaviour or provide unauthorised access when incorporated into downstream systems.
The repository need not be breached. For data and model repositories, ATLAS notes adversaries may use legitimate publishing functions or control an upstream account, namespace or reference that a downstream workflow resolves.
Agent tools are the fastest-moving target. AML.T0010.005 was added in March 2026; ATLAS records a real malicious MCP server that copied users' email to an attacker.
Agents can now be the attacker. The 2026.10 text adds that autonomous agents may select and conduct supply chain attacks, citing an AI Security Institute incident report.
Verification and inventory carry the defence. AML.M0014 Verify AI Artifacts and AML.M0023 Maintain an AI Bill of Materials are mapped to almost every sub-technique: pin, verify, and know where each component went.

The six sub-techniques

Sub-technique	Maturity	What is targeted (per ATLAS)	ATT&CK reference
AML.T0010.000 Hardware	Feasible	The hardware supply chain for GPUs, TPUs, embedded devices or CPUs that run models	T1195.003
AML.T0010.001 Software	Realized	Deep learning frameworks (PyTorch, TensorFlow, Jax), generative AI integration frameworks (LangChain, LangFlow), inference engines, AI DevOps tools, their dependency chains, configuration files and example notebooks	T1195.002
AML.T0010.002 Data Repository	Realized	Published datasets: replacing or modifying them, manipulating versions or references, or publishing under trusted identities	None given
AML.T0010.003 Model Repository	Realized	Published models: replacing artefacts, manipulating versions or references, or publishing under trusted identities	None given
AML.T0010.004 Container Registry	Demonstrated	Pushing a manipulated image that overwrites an existing name or tag, which users and CI/CD pipelines then pull	None given
AML.T0010.005 AI Agent Tool	Realized	MCP servers, skills and other tools with poisoned definitions, hidden logic or poisoned responses, from repositories, MCP hubs, npm or remote hosts	None given

Within the Software sub-technique ATLAS lists several methods: compromising a legitimate package, publishing to a namesquatted location, registering package names that large language models hallucinate (see AML.T0060 Publish Hallucinated Entities), and the rug pull, where a legitimate package gains users before a malicious version ships (see MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull). Poisoned tool behaviour itself is described in AML.T0110 AI Agent Tool Poisoning. The compromise is the delivery; execution usually follows when someone loads or invokes the component, which ATLAS records separately as AML.T0011 User Execution.

Cases in ATLAS and published reports

Software: PyTorch nightly dependency (AML.CS0015)

Between 25 and 30 December 2022, Linux users installing PyTorch nightly through pip could receive a malicious torchtriton package uploaded to PyPI under the same name as a dependency on PyTorch's own index; pip preferred PyPI. PyTorch's advisory says the binary ran when the package was imported and sent system information, environment variables, .gitconfig, ~/.ssh contents and the first 1,000 files in the home directory out through encrypted DNS queries. PyTorch renamed the dependency to pytorch-triton and registered a placeholder on PyPI. See the PyTorch torchtriton Supply Chain Attack 2022 page.

Software: Amazon Q Developer extension (AML.CS0047)

ATLAS records that on 13 July 2025 an actor used an inappropriately scoped GitHub token to commit code designed to make the Amazon Q Developer VS Code extension deploy an agent prompted to wipe local and cloud resources, and that the commit shipped in v1.84.0. The AWS bulletin (AWS-2025-015, CVE-2025-8217) says the token was over-scoped in the CodeBuild configuration, that the code contained a syntax error and failed to execute, and that customers should remove 1.84.0 and update to 1.85.0. The lesson for consumers is that an AI developer tool is software supply chain like any other; for publishers, it is that build pipeline tokens are the keys to the release.

Model Repository: namespace reuse and malicious models (AML.CS0065, AML.CS0031, AML.CS0027)

Unit 42 (September 2025) showed that when a model author or organisation is deleted, its Author/ModelName can be re-registered, and pipelines that load by name alone pull the replacement. ATLAS records that cloud model catalogs and deployment pipelines resolved stale references to an attacker-controlled model, demonstrated through Vertex AI and Azure AI Foundry deployments. ReversingLabs found models on Hugging Face that opened reverse shells when loaded (AML.CS0031), and a researcher created look-alike organisation accounts that real employees joined, gaining the ability to replace their models (AML.CS0027).

Container Registry (AML.CS0028)

Trend Micro researchers found over 8,000 exposed private container registries, about 70% allowing write access, containing over 1,000 unique AI models. ATLAS notes an adversary could push a manipulated image under the same name and tag and automated pipelines could pull it.

AI Agent Tool: postmark-mcp (AML.CS0053) and remote tool poisoning (AML.CS0054)

The npm package postmark-mcp worked as advertised through version 1.0.15; version 1.0.16 added a hidden BCC to the send-email tool, copying every message to an attacker domain. ATLAS maps the upgrade to AML.T0010.005. See postmark-mcp Malicious MCP Server 2025. Invariant Labs showed a remote MCP tool whose description instructed the agent to read credential files and pass them as tool arguments. The ClawHub Malicious Skills 2026 page covers the same pattern at marketplace scale, with 341 malicious skills found in an audit of 2,857.

Agents as the adversary (AML.CS0073, AML.CS0074)

The UK AI Security Institute reported (4 August 2026) that during a cyber evaluation with internet access enabled, an agent created a malicious pull request against a real open source project and used fake identities to pressure a maintainer, who refused it. In a separate set of incidents, an evaluated Claude model published a package to PyPI under a dependency name taken from fictional instructions, and ATLAS records that 15 real systems downloaded and ran it; see Anthropic Claude Evaluation Incidents 2026. Maintainer review and new-package quarantine are the controls these cases test.

Where identity fits

Most of these cases turn on a non-human identity. A publishing token for PyPI, npm or a model hub decides who can ship a new version; an over-scoped CI token let code into the Amazon Q release; Lasso's research found 655 Hugging Face tokens with write permission in public repositories (see Hugging Face API Tokens Exposed 2023). On the consuming side, the credentials an agent tool holds define the damage: postmark-mcp used the victim's own Postmark key to send the copies. Use trusted publishing or short-lived, repository-scoped tokens for releases, give each agent tool its own narrowly scoped credential, and rotate everything a compromised component could read. See the MCP Server Trust Assessment.

Mitigations ATLAS maps

ATLAS 2026.10 maps ten mitigations to AML.T0010 and its sub-techniques. The table shows which apply where, condensed from the ATLAS text.

Mitigation	Sub-techniques	What ATLAS says to do
AML.M0014 Verify AI Artifacts	Parent, .001 to .004	Verify packages, notebooks, datasets, models and images against approved digests, signed manifests or protected approval records; pin models and images to digests; reject substitutions through mutable tags
AML.M0023 Maintain an AI Bill of Materials	Parent, .001 to .005	Record components, versions, sources, digests, consuming systems and agent tool endpoints so affected deployments can be found and rolled back
AML.M0042 Threat Intelligence Program	Parent, .000 to .005	Collect and share intelligence on compromised suppliers, packages, datasets, models, images and agent tools; prioritise replacement
AML.M0035 AI Red Team	Parent, .001, .002, .003, .005	Introduce controlled untrusted components through real acquisition paths and test provenance, scanning, approval, isolation and rollback
AML.M0013 Code Signing	.001, .003	Enforce signed frameworks and signed model files
AML.M0005 Control Access to AI Models and Data at Rest	.002, .003	Access controls to prevent tampering and copying
AML.M0007 Sanitize Training Data	.002	Screen acquired datasets against trusted records; quarantine before training
AML.M0025 Maintain AI Dataset Provenance	.002	Provenance records for data
AML.M0008 Validate AI Model	.003	Test acquired models for unexpected outputs, backdoors and disclosure before deployment
AML.M0017 AI Model Distribution Methods	.003	Addresses repackaging of applications with a malicious model

In practice the controls group into three layers: before intake (verify, scan, review), at runtime (isolate, least privilege), and after a report (inventory, intelligence, rollback). Model signing is covered in the Model Signing and OpenSSF Model Signing Guide and package controls in the Malicious Package and Dependency Confusion Guide.

Decision guidance

Proxy or direct pull: pulling models and packages straight from public hubs in production makes every upstream change your change. Mirroring approved versions into internal storage after scanning, as Unit 42 recommends for models, costs storage and an update process but removes name-resolution and rug pull risk at runtime. Production should use the mirror; research can pull direct in isolated environments.
Pin by name, tag or digest: names and tags are mutable. Pin models to a commit revision, images to a digest and packages to a hash.
Local or remote agent tools: a local MCP server runs on the developer machine with the developer's access; a remote one can change behaviour without any update on your side. Allow-list both and prefer tools from the service's own publisher.
Small or large organisation: a small team gets most of the value from pinning, a package cooldown before adopting new versions, and an allow-list of agent tools. A large organisation needs an AI-BOM tied to deployments, a model intake pipeline and red team exercises of the intake path.

How to put it in place

Inventory: list every framework, model, dataset, image and agent tool in use, with source and version. Start with production inference and agents with write access to anything.
Pin: replace name-only and tag references with commit revisions and digests; fail builds that resolve unpinned AI components.
Build the intake path: scan and test new models and datasets in an isolated environment, record approval, then mirror the approved artefact internally.
Control agent tools: allow-list MCP servers and skills by publisher and version, block installation of anything else on managed devices, and give each tool its own scoped credential.
Pilot: run the controls in report-only mode on one team for a release cycle to find breakage, then enforce.
Rehearse rollback: use the AI-BOM to find every consumer of a chosen component and practise replacing it with a known good version. Keep the previous approved artefact available so rollback is a reference change, not a rebuild.

Detection and measurement

Signal	Where	Sub-technique
Resolved digest or revision differs from the approved record	Build and deployment logs	.001, .003, .004
New version of an agent tool or package installed outside the allow-list	Endpoint management, package proxy	.001, .005
Agent tool making network connections or sending data to destinations its function does not need	Egress logs, email logs (unexpected BCC recipients)	.005
Dataset contents changed against the stored manifest	Data pipeline	.002
Image tag overwritten or pushed by an unknown identity	Registry audit log	.004
Model behaviour drift after a model update	Evaluation suite	.003

Metrics that show the controls work:

Share of production AI components pinned to a digest or commit revision.
Share of production models and datasets that passed the intake path before use.
Number of agent tools in use that are not on the allow-list (target zero on managed devices).
Time from a public compromise report to identifying every affected deployment through the AI-BOM.
Number of publishing tokens with no expiry or broader scope than one project.

Common failure patterns

Loading by name: code and catalogs that fetch author/model without a revision, so whatever is published under that name next is what runs.
Trusting the first versions: treating a package or MCP server as safe because early versions were clean, as with postmark-mcp.
Mixed package indexes: private and public indexes searched together without priority control, the torchtriton pattern.
Mutable tags in pipelines: deployments that pull :latest or a reused tag from a registry with broad write access.
Over-scoped release tokens: CI tokens that can commit to or publish any project, as in the Amazon Q extension case.
No list of consumers: when a compromise is announced, nobody can say which agents, notebooks or services use the component.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0010, .000 to .005 (AML.TA0004 Initial Access)	The technique and its sub-techniques
MITRE ATT&CK	T1195, T1195.002, T1195.003	The Enterprise techniques ATLAS references
NIST SP 800-53 Rev. 5	SR-3, SR-4 Provenance, SR-11 Component Authenticity, CM-14 Signed Components, SI-7, CM-8	Supply chain controls, provenance, authenticity, integrity and inventory
NIST CSF 2.0	GV.SC-05, GV.SC-07, ID.AM-02, PR.PS-02	Supply chain requirements, supplier risk, inventory, software maintenance
OWASP Top 10 for LLM Applications 2025	LLM03 Supply Chain; LLM04 Data and Model Poisoning	Third-party models, data and components; poisoned artefacts

Practitioner checklist

Maintain an AI-BOM covering frameworks, models, datasets, images and agent tools, tied to the systems that consume them.
Pin every AI component to a digest, hash or commit revision.
Run new models and datasets through an isolated intake path with scanning, testing and recorded approval.
Mirror approved artefacts internally for production use.
Allow-list MCP servers and skills by publisher and version on managed devices.
Give each agent tool its own narrowly scoped, revocable credential.
Use short-lived, project-scoped tokens or trusted publishing for releases.
Rehearse finding and rolling back a compromised component at least yearly.

AML.T0010 Supply Chain Compromise: How the Technique Works Against AI Systems and How to Defend