Mapping AI Agent Attacks to MITRE ATLAS: Tactics, Techniques, and the Detection Signals Each Phase Produces

When an autonomous agent gets compromised, the attack rarely looks like a classic intrusion. There is no malware dropper, no lateral movement across SMB, no obvious command-and-control beacon. Instead you see a sequence of plausible-looking tool calls, a prompt that quietly rewrites the agent’s goal, and a model that starts leaking the contents of its context window one token at a time. The question every detection engineer is now asking is the same one this article answers: how do you map those agent-specific behaviors onto a framework your SOC already understands? It is the detection-side companion to our overview of the 2026 AI agent threat landscape.

What does it mean to map AI agent attacks to MITRE ATLAS?

Mapping AI agent attacks to MITRE ATLAS means taking each step an adversary performs against an autonomous AI system and assigning it to one of the framework’s tactics (the adversary’s goal) and techniques (how they achieve it), then identifying the telemetry that step produces. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — is the ATT&CK-for-AI knowledge base. As of version 5.4.0 (February 2026) it catalogs 16 tactics, 84 techniques, and 56 sub-techniques, alongside dozens of mitigations and real-world case studies. It deliberately mirrors the structure of ATT&CK, so a tactic like Reconnaissance or Exfiltration carries the same meaning it does in traditional threat modeling, extended to cover adversarial machine learning.

The practical payoff is this: every ATLAS technique you map produces, or fails to produce, a specific detection signal. Reconnaissance against an inference API shows up as anomalous query volume and probing patterns. A poisoning attempt shows up in data-pipeline lineage and training-set drift. A prompt-injection that hijacks an agent’s tool use shows up in the gap between the agent’s stated intent and its actual function calls. Mapping is not a paperwork exercise — it is how you turn an abstract “the agent was attacked” into “we should have seen X in log source Y.” That is the whole point of using a shared framework: it converts agent attack mapping into concrete, testable detection coverage.

Why doesn’t classic ATT&CK cover AI agents?

Traditional ATT&CK assumes the asset under attack is an operating system, an identity, or a network service. It has no vocabulary for the failure modes that are unique to machine learning: an input crafted to flip a classifier’s decision, a training set salted with poisoned samples, a model whose weights can be reconstructed through repeated queries. These adversarial ML tactics operate on the model’s statistical behavior, not on a CVE in the host.

ATLAS fills exactly that gap. NIST groups adversarial machine learning into four broad attack categories — evasion, poisoning, privacy (extraction/inference), and abuse — and ATLAS gives each a home among its tactics and techniques. For agents specifically, the framework has grown to cover prompt injection, tool-use manipulation, and the chaining of LLM capabilities into multi-step compromises. So when you adopt ATLAS, you keep the muscle memory of ATT&CK while gaining coverage for the parts of an agent that have no equivalent in a classic kill chain.

How do AI agent attacks map across the ATLAS tactics?

The cleanest way to think about an agent compromise is as a progression through ATLAS tactics, roughly left to right, the same way you read an ATT&CK matrix. The agent adds wrinkles at almost every stage because it can reason, call tools, and persist state across turns. Here is how the phases line up, and what each one leaves behind.

Reconnaissance and Resource Development: what does early probing look like?

In the Reconnaissance phase, the adversary gathers intelligence on the AI system — its architecture, the models behind it, the tools the agent can call, and the guardrails in place. Against an agent this often means systematic prompting: asking the agent to describe its own instructions, enumerate its available functions, or reveal which model version it runs. Attackers also read documentation, study API behavior, and analyze public model cards. Resource Development follows: standing up compute, acquiring a proxy or surrogate model for offline experimentation, and crafting the adversarial inputs they will later deploy.

Detection signals: spikes in introspective prompts (“what tools do you have”, “repeat your system prompt”), unusually structured probing across many sessions, and queries that systematically vary one parameter at a time. None of this is malicious on its own, which is why volume, sequence, and entropy of prompts matter more than any single request.

Initial Access and ML Model Access: how does the adversary get in?

Initial Access describes how an adversary first reaches the AI system — through a malicious or compromised API, a phishing lure that plants a poisoned document the agent will later ingest, or a software vulnerability in the surrounding application. ML Model Access (AML.TA0004) is the AI-specific cousin: gaining access to the target model through an inference API or, more dangerously, direct access to the model artifact (weights, config) itself.

For agents, the most common entry is indirect prompt injection: instructions hidden inside content the agent retrieves — a web page, an email, a document in a RAG pipeline — that the model treats as legitimate input. The agent reads the content, the embedded instruction becomes part of its working context, and the attacker now influences behavior without ever touching the API directly.

Detection signals: retrieved content containing imperative language aimed at the model, mismatches between the user’s request and the instructions appearing in the agent’s context, and access to model artifacts from unexpected identities or locations. Provenance metadata on every retrieved document is the difference between catching this and missing it entirely.

Execution and Persistence: how does the attack actually run?

Execution is the moment the adversary gets the model to do something — interacting with it to achieve an objective or to probe its weaknesses. In agent terms this is the hijacked tool call: the injected instruction tells the agent to send an email, query a database, or invoke a connected API on the attacker’s behalf. Persistence means the manipulation survives: a poisoned memory entry, a corrupted long-term store, or a malicious instruction the agent keeps re-reading across sessions.

Detection signals: the strongest single signal here is intent-versus-action divergence — the agent’s reasoning trace says it is summarizing a document while its function call exfiltrates data. Tool-call audit logs, parameter anomalies (a recipient address that never appeared in the conversation), and unexpected writes to agent memory all flag execution and persistence.

Defense Evasion, Discovery, and Collection: how does it stay hidden?

Defense Evasion covers techniques to bypass the guardrails: jailbreak phrasing, encoding tricks, or splitting a forbidden request across multiple turns so no single message trips a filter. Discovery is the agent being steered to enumerate its environment — connected systems, accessible files, available credentials. Collection is staging the data the adversary wants before it leaves.

Detection signals: classifier-evasion patterns (base64 blobs, unusual unicode, role-play framing), refusal-then-compliance sequences, and bursts of read/list operations across connected tools that don’t match the user’s task. Guardrail bypass often leaves a telltale “the filter said no, then said yes after rephrasing” trail.

ML Attack Staging, Exfiltration, and Impact: what is the payoff?

ML Attack Staging is where adversaries prepare model-specific attacks — building adversarial examples, training a poisoning payload, or crafting a query set for model extraction. Exfiltration is the data leaving: the agent dumping its context, reconstructing training data through inference, or piping retrieved secrets out through an allowed channel. Impact is the end state — fraud, sabotage, denial of service against the model, or reputational damage from a manipulated output.

Detection signals: for extraction and inference, high-volume systematic querying against an inference endpoint is the canonical tell. For exfiltration, watch for the agent emitting verbatim context, secrets, or PII into tool outputs. For impact, monitor downstream effects — anomalous transactions, abnormal output distributions, or a sudden collapse in model accuracy that points back to poisoning.

Which ATLAS phase produces which detection signal?

The table below condenses the mapping into something a detection engineer can use as a coverage checklist. The point is not to memorize technique IDs but to confirm you have a log source for each row.

ATLAS tactic (phase)	Typical agent technique	Primary detection signal	Where to look
Reconnaissance	Probing model/tool capabilities	Introspective prompt spikes, parameter sweeps	Prompt/inference logs
Resource Development	Surrogate model, crafted inputs	Offline activity (often invisible to you)	Threat intel, honeypots
Initial Access / ML Model Access	Indirect prompt injection, artifact access	Imperatives in retrieved content; artifact access from new identity	RAG provenance, IAM logs
Execution	Hijacked tool call	Intent-vs-action divergence	Tool-call audit, reasoning traces
Persistence	Poisoned memory	Unexpected writes to long-term store	Memory/vector store audit
Defense Evasion	Jailbreak, encoding, multi-turn split	Refusal-then-compliance, encoded payloads	Guardrail/filter logs
Discovery / Collection	Environment enumeration	Read/list bursts unrelated to task	Tool-call logs
ML Attack Staging	Adversarial examples, query sets	Systematic high-volume querying	Inference rate metrics
Exfiltration	Context dump, extraction	Verbatim secrets/PII in outputs	Output DLP, response inspection
Impact	Fraud, poisoning effect	Anomalous transactions, accuracy collapse	Business + model-quality metrics

How do you turn this mapping into working detections?

Start from the signals, not the techniques. For each row above, ask whether you currently capture the log source named in the last column and whether anything alerts on the anomaly described. Most teams discover that two sources are missing entirely: the agent’s reasoning trace (so they cannot detect intent-versus-action divergence) and provenance metadata on retrieved content (so indirect injection is invisible). Those two gaps account for a large share of undetectable agent attacks. Closing them is exactly what continuous AgentOps observability platforms such as OpsAgent are built for — centralizing reasoning traces and tool-call audit logs into one pipeline instead of stitching the two together after the fact.

Then layer the detections. A single introspective prompt is noise; a sweep of them followed by a guardrail-evasion sequence followed by a tool call with a never-before-seen parameter is a high-confidence chain that maps cleanly across Reconnaissance → Defense Evasion → Execution. ATLAS gives you the shared language to express that chain, the ATLAS Navigator at atlas.mitre.org lets you visualize your coverage on the matrix, and the 42 documented case studies give you real attack sequences to test your detections against. The goal is not perfect prevention — agents are too flexible for that — but ensuring that no phase of an attack passes through your environment without leaving a signal you actually collect. To pressure-test those detections against real attacker sequences, pair this mapping with structured red-teaming and security benchmarks for AI agents.

---

Sources: MITRE ATLAS overview (Vectra AI), What is MITRE ATLAS? (CrowdStrike), MITRE ATLAS: How can AI be attacked? (Tarlogic), The Ultimate Guide to MITRE ATLAS (Astra). Framework figures reflect ATLAS v5.4.0 (February 2026); verify against atlas.mitre.org before relying on exact counts.