Operationalizing MITRE ATLAS

Concept. MITRE ATLAS is the ATT&CK of AI — a curated, adversary-informed knowledge base of the tactics and techniques used against ML and, increasingly, agentic systems. Weeks 8–16 taught individual attacks; this week you stop treating them as a bag of tricks and start using ATLAS as a shared vocabulary and coverage map. The goal is operational: threat-model a RAG pipeline and an agentic system, map every Phase 2 attack to a technique ID, and turn that map into detection and response you can staff.

🎯 Objectives

By the end of this week you can:

• Explain ATLAS's structure — tactics, techniques, sub-techniques — and how it extends ATT&CK with two AI-specific tactics.
• Run an ATLAS-based threat model over a RAG pipeline and an agentic system, producing a heat map of relevant techniques.
• Map your Phase 2 attacks (prompt hacking, RAG poisoning, MCP hijacking, supply-chain) to concrete AML.Txxxx IDs.
• Name the current agent techniques — Context Poisoning, Memory Manipulation, Thread Injection, Publish Poisoned Tool — and say where each is detected.
• Turn the knowledge base into operations: behavioral SIEM signals, IR playbooks, and the coverage gaps ATLAS still has.

What ATLAS actually is

ATLAS (Adversarial Threat Landscape for AI Systems) mirrors ATT&CK's tactic → technique → sub-technique grammar, so a team already fluent in ATT&CK adopts it without a new mental model. As of the v2026.09 release (15 September 2026) it catalogues 16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations, and 73 case studies — up from 101 techniques / 77 sub / 37 mitigations / 68 studies two releases earlier (v2026.07), and 84 techniques / 56 sub at the start of the year: a measure of how fast the agentic attack surface is being catalogued (atlas-data releases). It adds two tactics ATT&CK has no equivalent for: AI Model Access and AI Attack Staging (Vectra). Every technique is grounded in real incidents via the case-study collection — poisoned Postmark MCP email exfiltration, Bing Chat indirect prompt injection, LAMEHUG malware (APT28) — so a technique ID is never abstract (ATLAS case studies).

In May 2026 ATLAS also migrated to a new v6 data format and a date-based release scheme (v2026.05, .06, .07), and — the operationally significant change — every technique now carries platform designations (Predictive AI · Generative AI · Agentic AI · Enterprise). That lets you filter the matrix down to just the techniques that apply to your system class before you ever build a heat map (atlas-data releases).

🔑 Why a framework and not a checklist: a technique ID gives you a stable name that survives across teams, tools, and time. "We're exposed to AML.T0080" is auditable; "the agent might get confused" is not. ATLAS turns ad-hoc red-team findings into a coverage matrix you can measure against.

The agentic turn

The reason this week sits in Phase 4 and not Phase 2 is that ATLAS itself pivoted. An October 2025 Zenity Labs collaboration seeded 14 agent-focused techniques, and every release since has extended them — the v2026.07 batch alone added Publish Poisoned AI Artifacts and split AI Agent Tool Poisoning into three lifecycle sub-techniques (atlas-data releases). The defining property of this whole class: they all assume the attacker is already past the input sanitizer. Front-door prompt-injection testing misses them entirely.

The pedagogical sting is where each is caught. v2026.07 makes this explicit by decomposing tool poisoning into three lifecycle sub-techniques — Definition & Instructions (the poisoned tool spec), Implementation (encoded payload + unexpected external calls, built to survive code review), and Runtime Response (the payload firing once the tool is wired into a live agent workflow) (AML.T0104). The lesson: a poisoned tool is not one event to catch but a chain, and the reliable detection point is the last one — the syscall pattern the tool emits during execution, exactly the behavioral signature traditional AppSec tooling ignores (AML.T0110; AML.T0100).

From knowledge base to security operations

A framework nobody operationalizes is a poster. The operational move has three stages (Operationalizing ATLAS):

1. Threat-model first. Enumerate your AI assets — RAG index, agent memory store, config files, MCP tool registry — before an incident, using ATLAS TTPs as the checklist. This slots onto STRIDE/PASTA/attack-tree methods you already run (CTID Threat Modeling with ATT&CK).
2. Recalibrate telemetry. The hard part: "AI attacks rarely leave traditional file or network-based signatures... their signatures are functional or behavioral anomalies." The SIEM must capture behavior, not just IOCs.
3. Write technique-scoped playbooks. Tie each IR playbook to a specific TTP so response is "targeted, prioritized, and systematic," not generalized panic.

ATLAS pairs techniques with mitigations (37 as of v2026.07), and the two newest are pure operations: AI Red Team — systematically exercise your own coverage map rather than assume it — and Limit AI Workload Resource Consumption — bound the blast radius of unbounded tool/compute abuse (atlas-data releases).

For agentic systems, ARMO maps the ~140 TTPs onto four detection surfaces — a more useful lens than a flat list when deciding what to instrument first (ARMO):

💡 The instrumentation rule: signature-based tooling detects none of the new agent techniques. Detection demands cross-layer correlation — tie an Input-surface event (untrusted instruction in context) to a downstream Identity-surface action (unexpected egress to an allowlisted host). Instrument the surface with the largest uncovered technique cluster first, then backfill.

Where ATLAS still has holes

Operationalizing a framework means knowing its blind spots. ATLAS added a general Lateral Movement tactic (v5.1.0, late 2025), but it was scoped for a single AI system facing an external adversary — agent-to-agent lateral movement and multi-agent command-and-control remain under-covered, and secondary references still describe both as out of scope. For multi-agent deployments that leaves real gaps. The Cloud Security Alliance's gap analysis proposes six techniques ATLAS does not yet cover well (CSA):

• Agent-to-Agent Lateral Movement — a compromised agent exploits trust to instruct or impersonate peers within the comms layer.
• Orchestrator Hijacking — compromise the meta-agent → control all sub-agent routing (the AI-layer domain-controller compromise); can suppress audit entries while looking normal.
• Credential Relay Through Delegation Chains — under-scoped tokens across multi-hop delegations combine lateral movement with privilege escalation.
• Memory Persistence Across Sessions — hardest to detect, because "the poisoned state is structurally indistinguishable from legitimate learned context."

🔑 The one rule to carry out: ATLAS is your coverage map, not your perimeter. Map every attack to a technique, instrument the four surfaces, scope your red team past the front door — into memory, RAG index, config, and the MCP registry — and treat the framework's missing lateral-movement tactic as a gap you must close, not one ATLAS closed for you.

The lab

Threat-model a RAG pipeline plus an agentic system: select relevant TTPs in the ATLAS Navigator, map each Phase 2 attack to a technique ID, and output a heat map of the techniques that apply. That heat map — not this chapter — is the deliverable: it is what a SIEM engineer builds detections from.

📇 ATLAS technique reference

The lesson above is what to learn. This is the catalog to map against. Folded by default; expand when threat-modeling.

Read the agent techniques through their persistence horizon

The v5.4.0 agent techniques resolve into a small taxonomy by how long the compromise survives — which dictates the fix:

Technique & tactic index

• AML.T0100 — AI Agent Clickbait — lure agents into processing attacker-controlled content.
• AML.T0110 — AI Agent Tool Poisoning — poison tool definitions to hijack agent behavior; caught at execution syscalls, not source review.
• AML.T0104 — Publish Poisoned AI Agent Tool (Resource Development) — publish a poisoned tool to a public registry (PyPI/GitHub/HF Hub); v2026.07 splits its lifecycle into Definition & Instructions → Implementation → Runtime Response sub-techniques.
• AML.T0096 — AI Service API for C2 — use AI-service APIs as command-and-control channels.
• Context Poisoning (AML.T0080) + Memory sub-technique (AML.T0080.000) and Exfiltration via Tool Invocation (AML.T0086) — full tree in the Navigator.

CSA-proposed gap techniques (not yet in ATLAS)

Agent-to-Agent Lateral Movement · Orchestrator Hijacking · Credential Relay · Memory Persistence · MCP Server Compromise — rationale in the CSA gap analysis.