MITRE ATLAS Technique Mapping for LLM Agent Attacks

MITRE ATLAS gives security teams a shared way to talk about how adversaries attack AI systems. For LLM agents, that language now covers the concrete techniques that matter most: prompt injection, memory poisoning, RAG compromise, and tool supply chain attacks. The framework's real value, though, depends on translating its tactic-and-technique structure into a working threat model for the surfaces agentic systems actually expose.

Why ATLAS exists and what it actually is

ATLAS is a threat taxonomy, not a detection framework, and conflating the two is the root mistake practitioners make when they try to operationalize it. Maintained by The MITRE Corporation and modeled on ATT&CK, ATLAS organizes adversarial activity against AI systems into a hierarchy: tactics name adversary goals, techniques name specific methods each carrying a stable AML.TXXXX identifier, and mitigations and case studies connect both to observed incidents. The October 2025 Zenity Labs collaboration added 14 agent-focused techniques to that set, the most significant expansion since the framework's early releases.

The distinction between a taxonomy and a detection plan matters because the two structures share no unit of analysis. Two structures, two purposes. Treating a technique ID as a detection requirement is a category error that produces coverage reports full of items no runtime program can ever evidence.

How agentic systems break the assumptions ATLAS was originally built around

Traditional security assumes deterministic control flow, bounded trust boundaries, stateless execution, and identifiable adversarial inputs. When an LLM agent uses delegated tool authority, shares persistent memory, and coordinates with peer agents, the attack surface becomes behavioral and emergent, not structural and bounded. ATLAS's original framing was built for bounded systems, and agentic deployments break every boundary that framing relied on.

The dual-mode nature of the threat compounds the mapping difficulty. Attackers can target the agent itself, compromising its behavior so it takes actions its operator never intended. Crew Scaler's study organizes agentic threats into nine risk categories: Agent-Tool Coupling, Data Leakage, Injection, Identity and Provenance, Memory Poisoning, Non-Determinism, Trust Exploitation, Timing and Monitoring, and Workflow Architecture. That surface is richer than anything a pre-agentic ATLAS version addressed.

The framework layer offers no relief. LangGraph, Google ADK, and CrewAI vary sharply in security posture. CrewAI's open-source core ships with no built-in authentication, audit logs, or access controls. Google ADK includes framework-level safety features by default, including non-configurable content filters, callback hooks, and sandboxed execution, but still relies heavily on the deploying engineer for comprehensive security. The mapping work cannot be delegated to a framework default.

The three buckets every ATLAS technique falls into before any mapping begins

Before you map individual techniques to detection surfaces, sort the full ATLAS technique set into three buckets based on where the evidence lives. Each bucket needs a different detection apparatus, and if you skip the sort, your coverage claims are structurally dishonest. Bucket 1 holds runtime-evidenced techniques. The attack produces observable behavior during agent execution, crosses one or more of four detection surfaces, and leaves evidence that is sequence-shaped or context-shaped rather than configuration-shaped. The majority of agent-relevant ATLAS techniques live in this bucket.

Bucket 2 holds configuration-state techniques: overprivileged service accounts, exposed model artifacts, missing network segmentation. These are detectable in CSPM and CIEM tools that read configuration data, not in a runtime detection program. The evidence is a static property of how the system is deployed, not something that happens during execution.

Bucket 3 holds pre-runtime model-lifecycle techniques. ML Attack Staging at training time, ML Supply Chain Compromise on model artifacts, Model Theft via the training pipeline. A runtime program cannot see these events because they happened before the runtime existed. Without it, a practitioner checks technique IDs against a matrix and misses that some techniques sit outside the runtime program's reach entirely by design.

Prompt injection techniques: how ATLAS maps to the Input and Reasoning surface

Prompt injection has the deepest ATLAS coverage and the most confirmed real-world exploitation against agents. The detection signal at this surface is instruction-shaped tokens entering the agent's context window from a source not previously trusted with that role. Provenance matters as much as content.

The EchoLeak case grounds this abstraction in observed damage. CVE-2025-32711 scored CVSS 9.3 and affected Microsoft 365 Copilot through a zero-click indirect prompt injection delivered via crafted emails. Reference-style Markdown image links bypassed Copilot's link-redaction filters, and the attack exfiltrated OneDrive, SharePoint, and Teams data. No user interaction was required.

The standard objection to this technique class is that inputs are already filtered for malicious content. ARMO's guide adds a reporting subtlety: the CISO's report must use ATLAS vocabulary while the runtime program must use surface vocabulary. The architect needs both layers simultaneously, and the translation between them is the mapping work itself.

Memory and context poisoning: how ATLAS maps persistence across sessions

ATLAS enumerates memory manipulation techniques that are qualitatively distinct from prompt injection. The technique cluster includes AI Agent Context Poisoning, Memory Manipulation, and Thread Injection, all added through the October 2025 Zenity Labs collaboration. Thread Injection introduces malicious instructions into a specific chat thread.

The temporal dimension separates memory poisoning from single-turn injection. When a poisoned belief is encoded into the memory store rather than present in the current context window, the agent will defend that belief as correct even under questioning. The MemoryTrap demonstration from Cisco researchers in April 2026 made this concrete. When humans questioned the agent about these beliefs, it defended them as correct.

Detection requires watching two crossing points, not one. The first is at write time, when poisoned content enters the memory store. The second is at retrieval time, when the poisoned memory influences a future reasoning step. Crew Scaler's framework evaluation places Memory Poisoning among the strongest in aggregate coverage across all sixteen reviewed frameworks, but the broader picture is mixed. ATLAS coverage here is an improvement over prior versions, but gaps remain.

RAG poisoning and credential harvesting: the retrieval pipeline as an attack surface

The RAG pipeline is an attack surface in its own right, and ATLAS now names distinct techniques for it. RAG Poisoning, also called False RAG Entry Injection, was added in the Spring 2025 release and targets the retrieval index rather than the live context window. Credentials from AI Agent Configuration targets API keys or passwords stored directly in the agent's own settings.

These are separate from prompt injection because the target differs. The credential harvesting techniques exploit tool use directly: the agent is directed, via a poisoned retrieved result or injected instruction, to search its own retrieval store for secrets that were never meant to be there. They are frequently present anyway, because RAG databases ingest documents without sanitizing secrets.

The detection surface for this cluster is Tool Invocation. A program must see what the agent is querying for, not merely that a retrieval tool was called. That argument-level requirement recurs across every technique cluster covered so far, and it points toward the provenance discussion developed later.

Tool supply chain techniques: AML.T0104 and AML.T0110 in the agentic context

The early-2026 ATLAS additions for agent tool supply chains describe an attack arc that is simple and realistic: poison a tool, publish it to a registry an agent trusts, and let the agent install and invoke it. AML.T0115.002, Publish Poisoned AI Artifacts: AI Agent Tools, formerly AML.T0104, sits in the Resource Development tactic. A tool that looked legitimate becomes a foothold the next time the agent reaches for it.

The OpenClaw marketplace poisoning demonstrates the scale. The campaign reached over 800 malicious skills out of roughly 10,700 total on the marketplace. The autonomous AI pentester Hackian went from a black-box target URL to a one-click RCE in approximately 1 hour and 40 minutes with no human in the loop. SkillAtlas documents a parallel evidence gap: the same skill may be benign for one task and unsafe for another, and static signature scanning or single-pass sandbox testing misses this context-dependence entirely.

Bucketing these techniques splits them across categories. AML.T0104 straddles Bucket 2, where configuration state determines what tools the agent is authorized to install, and Bucket 1, where runtime monitoring checks whether a tool's behavior matches its declared schema when invoked. AML.T0110 is primarily a Bucket 1 runtime technique once the tool is already in the agent's environment.

Multi-agent trust exploitation and cross-agent coordination attacks

Multi-agent coordination introduces a trust surface with no analog in single-agent or traditional systems. A sub-agent passing a message to an orchestrator is not merely transmitting data. ATLAS now names the techniques that exploit this in the Cross-Agent Coordination surface: a malicious or compromised sub-agent hijacking the task graph of a trusted orchestrator by exploiting trust relationships established in multi-turn conversations.

Palo Alto Unit 42 documented the pattern in October 2025 as Agent Session Smuggling. The attack exploited implicit trust relationships between agents communicating over the Agent2Agent protocol during multi-turn conversations. Few established countermeasures exist in any reviewed framework.

The detection signal at this surface is structural rather than content-based. The question is whether a message arriving from a sub-agent carries instruction-shaped content that would change the orchestrator's plan. The provenance check sees that this message type has never carried planning directives before.

Why tool-name-level permissions are insufficient and what argument-level enforcement adds

Across the prompt injection, RAG poisoning, credential harvesting, and tool poisoning clusters, one failure mode recurs. Permissions are granted at the tool level, but the attack operates at the argument level. What is not authorized is the argument flowing into it.

Tool use is the outward axis of agent provenance. It is where an LLM agent moves from generating text to interacting with APIs, databases, code interpreters, and browsers. The attack surface is not which tool is called but what arguments flow into that tool and from where. PACE, published October 2026, addresses this by mediating every tool call immediately before it executes. Path confinement represents executable cuts of influence paths, while capability and effect verification checks schema-defined effects against authority compiled from the authenticated request.

The provenance types that together cover the technique surface are semantic and procedural. Semantic provenance links claims to supporting or contradicting evidence. The argument-level gap is not a research curiosity. It is the common thread running through every runtime-evidenced technique cluster ATLAS covers.

Where ATLAS's coverage genuinely ends and what sits outside the runtime program

An honest ATLAS-to-agent mapping must name what ATLAS does not cover, what runtime detection cannot see, and what no current framework addresses adequately. A coverage report that omits these gaps is marketing, not assessment. The Bucket 3 techniques are the clearest example. Bucket 2 techniques similarly require different tooling. CSPM and CIEM tools own them, not a runtime detection program.

Beyond the bucket boundaries, genuine coverage gaps remain inside ATLAS itself. Agent fingerprinting is an emerging technique class not yet covered at all. Oxford research on LLM browser agent fingerprinting showed that websites can passively identify which underlying model powers an agent from UI traces alone, so attackers can target known model weaknesses. The practitioner's job is not to find a framework that covers everything. It is to know which gaps they are accepting.

A repeatable workflow for translating ATLAS techniques into a working agent threat model

The mapping work translates into a four-step process. Step one is a surface inventory. Enumerate the agent's four detection surfaces as they actually exist in the deployment: what enters the context window and from where, which tools are called with what arguments, what identity and action boundaries exist, and whether the agent coordinates with other agents and over which protocols. Step two is the technique sort. Apply the three-bucket structure to the full ATLAS technique set. This immediately removes pre-runtime and configuration-state techniques from the runtime program's scope and clarifies which tool classes own them.

Step three is per-technique signal mapping. For each runtime-evidenced technique, identify which surface it crosses, which layers of the detection stack are required to see it, and what signal source feeds those layers. A technique mapped to a surface with no signal feeding it is not covered, regardless of what the matrix says.

Step four is the explicit gap register. Document which techniques fall into Bucket 2 and Bucket 3, which ATLAS gaps the team is accepting, and which controls correspond to each runtime-evidenced technique, including where no control exists yet. The coverage claim must rest on observed execution paths, not on whether a technique ID appears in a matrix.

The target output is not a checked matrix but a Verified Change Record. Each technique either has a proven control mapped to a real signal, or it appears in the gap register with an explicit acceptance decision. Opinion-based risk debates end when the evidence is structured this way, because the debate becomes about specific gaps and specific accepted risks rather than about whether the taxonomy was applied correctly.