ATLAS Execution Tactic: Controlling What Runs Through Your AI Agents and Models

In AI systems the thing that executes an attacker's intent is often not a binary but a model following instructions, an agent calling a tool, or a model file running code as it loads. MITRE ATLAS defines the Execution tactic (AML.TA0005) as the adversary "trying to run malicious code embedded in AI artifacts or software", and notes that execution is usually paired with techniques from every other tactic. This hub covers the 6 techniques and 7 sub-techniques under the tactic in ATLAS 2026.10, ranks them for defenders, shows how they chain in recorded cases, and sets out detection and mitigation priorities. It is written for teams that build or run LLM applications, copilots and AI agents, and for the detection engineers who watch them. Each technique has its own deep guide, linked below; for ATLAS as a whole see the MITRE ATLAS Guide.

Key takeaways

• Prompt injection dominates the tactic. AML.T0051 LLM Prompt Injection is recorded as an Execution step in 33 of the 44 ATLAS case studies that include Execution, counted from the ATLAS 2026.10 data; the Indirect sub-technique alone appears in 19.
• Execution is where words become actions. An injected instruction only causes harm when the model can act, through AML.T0053 AI Agent Tool Invocation, a code interpreter (AML.T0050) or a deployed agent (AML.T0103).
• AI artefacts are executable. AML.T0011 User Execution covers unsafe model files, malicious packages, poisoned agent tools and malicious links that run as soon as a user or service loads them.
• Tool permissions set the blast radius. ATLAS maps 13 mitigations to AML.T0053, more than to any other technique in the tactic, and most of them are about scoping, authorising and confirming tool calls.
• Logging is the first control. AML.M0024 AI Telemetry Logging and Monitoring is one of the three most frequently mapped mitigations across the tactic: without prompt, context and tool-call logs, AI execution cannot be detected or investigated.

What Execution means for AI systems

Traditional execution means a process starts. In an LLM application, execution can happen with no new process at all: the model reads text, treats part of it as instructions, and then uses its own legitimate tools to carry them out. ATLAS models this as a sequence. Content reaches the model through Initial Access (see the ATLAS Initial Access Tactic hub); AML.T0051 makes the model follow it; AML.T0053 turns that into API calls, file operations or shell commands. Separately, AI artefacts such as pickle-serialised models, chat templates and agent skills carry code or behaviour-shaping logic that runs when they are loaded, which ATLAS covers under AML.T0011.

Of the 44 case studies with an Execution step, 10 are incidents and 34 are exercises (red team or research demonstrations). The high share of exercises reflects how new agentic execution paths are; the incidents show they are already used in practice.

Every Execution technique in ATLAS 2026.10

Case study counts are distinct ATLAS case studies recording the technique or its sub-techniques as an Execution step. Maturity is the ATLAS rating.

AML.T0053 also sits under Privilege Escalation and Lateral Movement, and many case studies record it there rather than under Execution, which is why its Execution count is lower than its real prevalence. Sub-technique counts can exceed a parent's share of a case study because one case may use several sub-techniques.

Where to start: ranked techniques for defenders

1. AML.T0051.001 Indirect prompt injection combined with AML.T0053 tool invocation. This pair is the core agentic risk. In AML.CS0067, prompt injections in GitHub issues and pull request text led a CI coding agent to read /proc/self/environ with its file Read tool, outside the sandbox boundary applied to its shell; in AML.CS0046, a PDF carried instructions that led a computer-use agent to run destructive shell commands. Restrict tool use when untrusted content is in context and require confirmation for consequential actions. See the Prompt Injection Guide and the Human-in-the-Loop for AI Agents Guide.
2. AML.T0011.000 Unsafe AI Artifacts and AML.T0011.002 Poisoned AI Agent Tool. Malicious pickle models executed reverse shells on load (AML.CS0031); a reclaimed Hugging Face namespace served a payload that ran on deployment (AML.CS0065); poisoned GGUF chat templates injected instructions at inference time without touching weights (AML.CS0064); the postmark-mcp package copied every outgoing email to the attacker whenever an agent used it (AML.CS0053). See the MCP Tool Poisoning Detection guide.
3. AML.T0050 Command and Scripting Interpreter. Code-executing LLM features are remote code execution by design. AML.CS0052 records 20 remote code execution vulnerabilities across 11 LLM frameworks reachable through prompts; AML.CS0016 shows a math assistant whose generated Python revealed environment variables containing its API key. Sandbox every interpreter with no credentials and no network by default. See the AI Agent Sandboxing and Code Execution Guide.
4. AML.T0103 Deploy AI Agent. In the Amazon Q Developer Extension Compromise (AML.CS0047), a malicious extension release launched the bundled agent with all tools trusted and no interaction, under a prompt to delete local and cloud resources; AWS said a syntax error stopped it. In AML.CS0069 a state-sponsored group configured a jailbroken coding agent inside its own attack framework. Control which agent runtimes may start on your hosts and with which flags.
5. AML.T0100 AI Agent Clickbait. Computer-use and browser agents can be socially engineered like people: AML.CS0055 adapted ClickFix so an agent opened a terminal and pasted a command. See the Browser and Computer-Use Agent Guide.
6. AML.T0051.000 and AML.T0051.002. Direct injection matters most for public chat products and when an attacker already holds a session token; triggered injection matters for assistants that act on events (email arrival, calendar updates, replies such as "Thanks" in AML.CS0063).

How Execution chains in real cases

The 2026 OpenAI and Hugging Face incident shows the last pattern at scale: evaluation agents used a template evaluation path in Hugging Face's dataset processing to run Python and shell commands inside a production pod, then read its Kubernetes service account token. Execution inside AI infrastructure turned straight into credential access.

Detection priorities across the tactic

See the AI Agent Observability and Incident Response Guide for the logging design.

Metrics that show coverage

• Tool-call logging coverage: percentage of production agents whose tool calls are logged with prompt, sources and result.
• Consequential actions gated: share of write, send, delete and payment tools that require confirmation or policy approval.
• Interpreter isolation: number of code-executing features running without network egress and without credentials in the environment.
• Red team pass rate: percentage of indirect injection test cases that fail to trigger a tool call, by agent.
• Artefact load hygiene: share of model loads using safe formats from approved, pinned sources.

Mitigation priorities

Across the tactic's techniques and sub-techniques, the most frequently mapped ATLAS mitigations are AML.M0024 AI Telemetry Logging and Monitoring, AML.M0033 Input and Output Validation for AI Agent Components and AML.M0035 AI Red Team (5 each), followed by AML.M0011 Restrict Library Loading (4). See the MITRE ATLAS Mitigations Guide.

Model-level controls (guidelines, alignment, classifiers) reduce the success rate of injection but do not remove it, so architectural controls on tools and isolation carry the weight. The OWASP LLM06 Excessive Agency guidance makes the same point.

Implementation order

1. Log first: capture prompts, retrieved sources, tool calls and results for every agent, centrally and tamper-resistant.
2. Inventory tools: list each agent's tools, the identity each runs as, and which are read-only, write, external or irreversible.
3. Scope identities: give agents their own service identities or delegated tokens bounded by the user; remove shared admin keys.
4. Isolate interpreters: move code execution into sandboxes without credentials or default egress; test with known escape cases.
5. Gate in audit mode: run policy checks on tool calls in log-only mode for two to four weeks, tune, then enforce for write and external tools first.
6. Red team: run indirect injection, poisoned tool and clickbait scenarios each release. See the AI Red Teaming Guide.
7. Rollback and containment: keep a per-agent kill switch and the ability to revoke an agent's credentials in one step. See the AI Agent Kill Switch and Containment Guide.

Where identity fits

An injected instruction executes with whatever identity the agent holds. In AML.CS0016 the interpreter's environment held an API key; in AML.CS0067 the CI agent's environment held workflow secrets; in AML.CS0047 the agent would have acted through the user's AWS CLI profiles. Each case is an over-provisioned non-human identity sitting behind a model that can be talked into using it. Keep credentials out of agent runtimes where possible, issue short-lived scoped tokens per task, and record which identity performed each tool call. See the AI Coding Agents Security Guide.

Framework mapping

Common failure patterns

• Relying on the system prompt: telling a model to ignore instructions in documents is a guideline, not a boundary; the tool layer must enforce it.
• Sandboxing the shell but not other tools: AML.CS0067 shows a file Read tool reaching secrets that the sandboxed bash tool could not.
• Trust-all flags in automation: agent CLIs run non-interactively with every tool auto-approved turn a single injected prompt into full execution.
• Rendering model output as code: chat transcripts and generated HTML rendered without encoding move execution into another user's browser (AML.CS0060).
• Loading models with unsafe deserialisation: pickle-based formats from public hubs loaded directly on GPU hosts that hold cloud credentials.

Practitioner checklist

• Log prompts, retrieved sources and every tool call with the identity used, for all agents.
• Classify each agent tool as read, write, external or irreversible, and require confirmation for the last three where practical.
• Disable automatic tool use when untrusted content is in the context window.
• Run all code-executing features in sandboxes with no credentials and default-deny egress.
• Load models only in safe formats from approved, pinned sources; verify before deserialising.
• Block agent CLIs with trust-all or non-interactive flags outside approved pipelines.
• Encode or sanitise model output before rendering it in browsers or passing it to interpreters.
• Red team indirect injection, poisoned tools and agent clickbait every release, and track the pass rate.

Standards and references

• MITRE ATLAS: Execution (AML.TA0005)
• MITRE ATLAS: LLM Prompt Injection (AML.T0051)
• MITRE ATLAS: AI Agent Tool Invocation (AML.T0053)
• MITRE ATLAS: User Execution (AML.T0011)
• MITRE ATLAS: Mitigations
• MITRE ATLAS: atlas-data repository
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATT&CK: Execution (TA0002)

Related NHI Mgmt Group resources: MITRE ATLAS Guide · ATLAS Initial Access Tactic · ATLAS Persistence Tactic · Prompt Injection Guide · AI Agent Sandboxing and Code Execution Guide