AML.T0011 User Execution: How the Technique Works Against AI Systems and How to Defend

In AI systems the moment of compromise is often an ordinary action: loading a model, importing a package, starting an inference server or asking an agent to use a tool. MITRE ATLAS records this as AML.T0011 User Execution, an Execution (AML.TA0005) technique rated Realized, with four sub-techniques in the 2026.10 release: Unsafe AI Artifacts (AML.T0011.000), Malicious Package (AML.T0011.001), Poisoned AI Agent Tool (AML.T0011.002) and Malicious Link (AML.T0011.003). ATLAS describes it as an adversary relying on a user to load, execute, interpret or otherwise use a malicious or unsafe artefact, with effects ranging from host code execution to malicious AI behaviour. This guide covers how each sub-technique works, the cases ATLAS records, the controls that stop execution and how to measure them. It is for ML engineers, data scientists, agent developers and the security teams that manage their workstations and pipelines. The Enterprise equivalent is covered in T1204 User Execution; this page covers the AI-specific angle.

Key takeaways

• Loading is executing. Serialised model formats based on Python pickle run code during deserialisation; Hugging Face's own documentation says not to unpickle data from untrusted sources.
• No vulnerability is required. ATLAS notes an unsafe artefact may use functionality an AI runtime supports on purpose, such as a bundled chat template, to change model outputs, safety behaviour or agent actions.
• The artefact may still work. ATLAS says unsafe artefacts may continue to work as expected from the victim's perspective, so "it ran fine" is not evidence of safety.
• Agents add a new user. With AML.T0011.002 the "user" action can be a prompt that makes the agent invoke a poisoned tool, as in the postmark-mcp incident.
• Verify before load. ATLAS maps AML.M0014 Verify AI Artifacts, AML.M0013 Code Signing, AML.M0011 Restrict Library Loading, AML.M0016 Vulnerability Scanning and AML.M0018 User Training.

How the four sub-techniques work

ATLAS links the technique to Supply Chain Compromise (AML.T0010): users may inadvertently execute unsafe code introduced that way. Supply chain compromise is the delivery; user execution is the trigger. For the Malicious Link example, ATLAS notes that an AI agent configured not to validate website origin headers will accept connections from any website, letting an adversary reach otherwise inaccessible networks.

Why model files execute

Hugging Face's pickle security documentation explains the mechanism: pickle stores a stack of opcodes that run when the file is loaded, and opcodes such as GLOBAL or STACK_GLOBAL import modules while REDUCE calls a function with arguments, which together can run arbitrary code during deserialisation. Its example returns the expected data after running the injected code, so the victim sees nothing wrong. PyTorch checkpoints commonly use pickle. The current torch.load documentation (2.15) shows weights_only=True as the default, which restricts the unpickler to tensors, primitive types, dictionaries and types added through add_safe_globals(), and it warns never to load data from an untrusted source. The safetensors format stores tensors without pickle and is described by Hugging Face as a format for storing tensors safely, as opposed to pickle.

Format choice is only part of the answer. AML.T0011.000 explicitly covers behaviour-shaping components, and the GGUF case below needs no deserialisation flaw at all.

Cases in ATLAS

• Malicious models on Hugging Face (AML.CS0031): ReversingLabs found models that executed reverse shells when loaded. ATLAS records the files were corrupted so the payload ran before deserialisation failed, which the scanner of the time did not flag.
• Organization Confusion on Hugging Face (AML.CS0027): a researcher replaced models in look-alike organisation accounts; per ATLAS, when any future user loads the model it automatically executes the payload.
• Model Namespace Reuse (AML.CS0065): loading or deploying a model pulled through a re-registered name executed the embedded payload in the model endpoint environment.
• Poisoned GGUF Templates (AML.CS0064): Pillar Security and Fujitsu Research of Europe showed a modified chat template that the inference engine interprets automatically, changing model and agent behaviour without touching weights.
• Google Colab notebooks (AML.CS0018): a victim may unwittingly run malicious code in a shared notebook, with the code hidden in files the notebook downloads.
• Package hallucination (AML.CS0022): a user installs a package whose name an LLM invented and an adversary registered, giving arbitrary code execution. See the Slopsquatting and Package Hallucination Guide.
• Amazon Q Developer extension (AML.CS0047): ATLAS maps execution to users who upgraded to v1.84.0; the AWS bulletin says the injected code failed to execute because of a syntax error.
• postmark-mcp (AML.CS0053) and ClawdBot skill (AML.CS0049): the malicious code ran when users asked their agent to use the poisoned tool or skill. See postmark-mcp Malicious MCP Server 2025 and, for the marketplace pattern where skills told users to run "prerequisite" commands, ClawHub Malicious Skills 2026.
• LAMEHUG (AML.CS0044): an email attachment held a PyInstaller-built .pif executable that CERT-UA classified as LAMEHUG, malware that uses an LLM to generate commands.

The PyTorch nightly case shows how small the trigger can be: PyTorch's advisory says the malicious torchtriton binary ran only when the package was imported. See the PyTorch torchtriton Supply Chain Attack 2022 page.

Where identity fits

User execution runs with whatever the user, notebook kernel or agent can reach. The torchtriton payload collected environment variables, .gitconfig and SSH keys; ClawHub skills went after exchange API keys, SSH keys and an agent's .env file. The less a workstation or agent holds in long-lived secrets, the less a single load or tool call exposes. Keep cloud and model hub credentials short-lived and out of environment files, run model experimentation under identities without production access, and give each agent tool its own scoped credential so a poisoned tool cannot borrow the agent's full access. See the Local MCP Server Security Guide.

Controls that stop execution

ATLAS maps no mitigation directly to AML.T0011.002 or AML.T0011.003. For poisoned tools, the controls on the delivery side in AML.T0010.005 apply (AI-BOM, red teaming, threat intelligence), plus runtime measures: an allow-list of tools, human approval for sensitive actions, and egress limits on tool processes. For malicious links, the general phishing defences in M1017 User Training apply, together with origin validation on any local agent service that listens for connections.

Decision guidance: the strongest single change is to make the safe path the default: safetensors or other non-executable formats in the intake pipeline, restricted loading in code, and an internal mirror of approved models, so data scientists do not have to judge each file. Where a team must load pickle-based or custom-code models from outside, do it in a disposable sandbox with no credentials and no network beyond what the test needs. Small teams should start with format and loading defaults plus an agent tool allow-list; larger organisations add signing enforcement and endpoint controls on ML workstations.

How to put it in place

1. Find the load points: search code, notebooks and serving configuration for model loading calls, custom code flags, unpinned model names and agent tool configuration.
2. Set safe defaults: convert approved models to safetensors where possible, keep weights_only=True, and turn off custom model code unless reviewed.
3. Create a sandbox lane: a disposable environment without credentials for evaluating untrusted models, notebooks and tools.
4. Allow-list agent tools: approved MCP servers and skills by publisher and version, with approval prompts kept on for tools that send data or change systems.
5. Pilot in audit mode: log load events and tool installs that would be blocked for one release cycle, then enforce.
6. Plan rollback: keep previous approved artefacts and tool versions available; if an enforced rule blocks legitimate work, add a reviewed exception rather than switching enforcement off.

Detection and measurement

• Share of production model loads using non-executable formats or restricted loading.
• Share of production models verified by signature or digest at load.
• Number of agent tools in use outside the allow-list (target zero on managed devices).
• Untrusted artefacts evaluated in the sandbox lane rather than on workstations.
• Mean time to contain after an EDR alert on an ML workstation.

Common failure patterns

• "It is just weights": treating a model download as data rather than code, then loading it on a workstation that holds cloud credentials.
• Scanner as approval: relying on a hub scan result alone, although the hub itself says its scan is not foolproof and ATLAS records models that evaded it.
• Turning safety flags off to make a model load: disabling restricted loading or enabling custom code to fix an error, without reviewing why it was needed.
• Running the prerequisite: following setup commands embedded in a skill or README without reading them.
• Agents with everything: one agent holding many tools and broad credentials, so one poisoned tool can drive the others.

Framework mapping

Practitioner checklist

• Treat every model, notebook, package and agent tool as code, not data.
• Default to safetensors and restricted loading; keep custom model code off unless reviewed and pinned.
• Load only from the internal mirror of approved, verified artefacts in production.
• Evaluate untrusted artefacts in a disposable sandbox without credentials.
• Allow-list MCP servers and skills and keep approval prompts on for sensitive tool calls.
• Keep long-lived secrets off ML workstations and out of agent environment files.
• Monitor inference and notebook processes for shells and unexpected egress.
• Train ML and agent users on manipulation patterns specific to AI artefacts.

Standards and references

• MITRE ATLAS: User Execution
• MITRE ATLAS: Poisoned GGUF Templates
• MITRE ATLAS: Malicious Models on Hugging Face
• MITRE ATT&CK: User Execution
• Hugging Face: Pickle Scanning
• PyTorch: torch.load
• Hugging Face: Safetensors
• PyTorch: Compromised PyTorch-nightly dependency chain

Related NHI Mgmt Group resources: MITRE ATLAS Guide · AML.T0010 Supply Chain Compromise · AML.T0110 AI Agent Tool Poisoning · AML.T0060 Publish Hallucinated Entities · Model Supply Chain Guide · Hugging Face Security Guide · MCP Server Trust Assessment