MITRE ATLAS

MITRE ATLAS is an ATT&CK-style knowledge base of adversarial tactics and techniques directed at AI-enabled systems, assembled from real-world observations, published research, and red team exercises. If you have used ATT&CK, the shape is familiar: tactics are the adversary’s objectives at each stage, techniques are the ways those objectives get achieved, and case studies tie chains of techniques into narratives that actually happened. Most people’s engagement with ATLAS stops at citing it in a slide. That is a waste. ATLAS is useful precisely because it gives you a sequence — a way to reason about what an adversary does before and after the moment your vulnerability scanner would have fired. This page is about using it as a working instrument.

ATLAS is a living knowledge base: tactics, techniques, and case studies are added and revised. Technique identifiers change, and a stale ID in a report is worse than no ID at all. Look up the current matrix before you cite anything — see Standards & References.

What ATLAS actually is

Three claims worth being precise about, because interview answers frequently get them wrong:

It is a knowledge base, not a control framework. It tells you what adversaries do. It does not tell you what to implement. Pair it with a control framework such as NIST AI RMF or ISO/IEC 42001 for the “what do we do about it” half.
It is grounded, not speculative. Entries derive from observed incidents and published research rather than brainstormed possibilities. That grounding is why it survives executive scrutiny in a way that a homemade threat list does not.
It covers the AI system, not just the model. Data pipelines, training infrastructure, model artifacts, serving endpoints, and increasingly the surrounding application are all in scope. Traditional cyber techniques appear alongside AI-specific ones, because real intrusions mix them.

How it is structured

Element	Meaning	How you use it
Tactic	The adversary’s objective at a stage (e.g. reconnaissance, initial access, persistence, exfiltration, impact)	Columns of the matrix; the skeleton of an engagement plan
Technique	A method of achieving a tactic	The finding-level unit; what you name in a report
Sub-technique	A narrower variant of a technique	Precision when the variant materially changes the control
Mitigation	Countermeasure associated with techniques	Starting point for your control mapping, not the end of it
Case study	A real chain of techniques against a real system	Evidence when arguing that a scenario is realistic

Read the matrix left to right as adversary progression, top to bottom as alternatives within a stage. The value is the left-to-right axis — that is the part OWASP-style lists do not give you.

Using ATLAS to structure a red team engagement

A red team plan built as “we will try prompt injection” is a demo. A plan built on tactics is an assessment. Walk the tactic columns in order and, for each one, write down what it means against this system, what you will attempt, and what evidence you will collect.

Tactic stage	Question for an agentic system	Typical objective evidence
Reconnaissance	What can an outsider learn about our agent, its tools, and its data sources?	Extracted tool inventory, endpoint names, model identity
Resource development	What would an attacker need to prepare — a poisoned document, a malicious tool server, a lookalike package?	Staged artifact, hosted and reachable
Initial access	How does attacker-controlled content reach the agent’s context?	Payload confirmed in context via retrieval or tool output
Execution	What does the agent do once influenced?	Tool call made that would not have occurred otherwise
Persistence	Can the influence survive the session?	Memory record or stored artifact that reproduces the behaviour
Privilege escalation / defense evasion	Can the agent be used to reach beyond its intended scope, or to avoid logging and gates?	Access to a resource outside task scope; an action with no audit record
Collection / exfiltration	What data can be gathered and moved out?	Data staged and egressed through an approved tool
Impact	What is the worst durable outcome?	Irreversible state change, cost blowout, degraded service

Scoping discipline: pick two or three tactics to go deep on rather than covering all of them shallowly. An engagement that proves initial access → execution → persistence end to end is more valuable than one that touches every column and demonstrates nothing. Practise this framing in Lab 3 — Prompt Injection Red Team and pick tooling from Red Team Tools.

Building a detection coverage matrix

The second high-value use is defensive: turn the tactic columns into rows and ask, honestly, whether you would see it.

Tactic	Would we detect it today?	Signal source	Gap
Initial access (untrusted content in context)	Partial	Retrieval logs with source provenance	Provenance not carried into the agent trace
Execution (tool invocation)	Yes	Tool-call log with arguments	Arguments truncated for large payloads
Persistence (memory write)	No	—	Memory writes not logged separately from completions
Exfiltration (data egress via tool)	Partial	Egress destination in tool args	No allowlist, no alert on new destination
Impact (irreversible action)	Yes	Approval gate events	Gate bypassed on the retry path

Three rules make this exercise useful rather than decorative. Score honestly — “we have logs somewhere” is a No unless someone can query it during an incident. Distinguish detection from prevention; both columns matter and conflating them hides risk. And attach each gap to a named owner and a ticket, because a coverage matrix with no follow-through is a document, not a control. The instrumentation this depends on is exactly what you build in Lab 4 — Agent Audit Trail.

A coverage matrix filled in from architecture diagrams rather than from actual queries against actual logs is worse than none — it manufactures confidence. Validate each “yes” by running the query.

ATLAS versus OWASP: sequence versus class

These are complementary, and being able to explain the difference cleanly is a reliable signal of depth.

	MITRE ATLAS	OWASP LLM / Agentic lists
Unit of analysis	Adversary technique in a sequence	Vulnerability or weakness class
Question answered	How would an attacker progress?	What is wrong with this system?
Best for	Red team plans, detection coverage, incident narrative	Design review, requirements, triage vocabulary
Time dimension	Explicit — stages ordered	Absent
Audience fit	Security operations, threat intel, offensive teams	Engineering, architecture, product security

Practical division of labour: use OWASP categories to classify a weakness you found, and ATLAS tactics to explain how an adversary would reach and exploit it. A finding that says “excessive agency (OWASP) reachable via untrusted content in retrieved documents, enabling execution and then persistence through agent memory” carries both, and reads as though a professional wrote it.

Worked example: one chain against a document-assistant agent

An agent that answers questions over an internal document corpus, with tools for retrieval, email, and a records API. Techniques are named by category here rather than by ID, deliberately — cite exact identifiers only after verifying them in the current matrix.

Stage (tactic)	What the adversary does	Technique category, in general terms	Defender signal
Reconnaissance	Probes the assistant with benign questions to learn which tools exist and how it describes its own capabilities	Discovery of AI system capabilities and model/tool inventory	Repeated capability-probing queries from one principal
Resource development	Prepares a document containing instruction-shaped text, tuned to retrieve for common internal queries	Crafting adversarial content / staging malicious artifacts	New document with unusually high retrieval hit rate
Initial access	Uploads the document through a normal ingestion path — a shared folder, a ticket attachment	Delivery via a legitimate data supply chain into the AI system	Ingestion event lacking a reviewed provenance record
Execution	A user’s routine query retrieves the document; the agent follows the embedded instruction and calls the records API and then the email tool	Adversary-influenced inference leading to tool invocation	Tool sequence never seen for this workflow; external recipient
Persistence	The agent writes a “learned preference” to durable memory that reproduces the behaviour in later, unrelated sessions	Poisoning of persistent context / stored artifacts	Memory write with an untrusted source in its provenance chain
Exfiltration / impact	Records are summarised and emailed outside the organisation; the behaviour repeats on a schedule until the memory is purged	Data collection and egress through approved channels	Egress to a first-seen destination; recurring identical task shape

Two things this chain teaches that a category list cannot. First, the vulnerability is at the execution step, but the durable damage comes from persistence — remediation that only patches retrieval leaves the poisoned memory in place. Second, every single step used an approved capability. Nothing was exploited in the memory-corruption sense; the system did exactly what it was built to do.

Writing a finding that references ATLAS correctly

Common failure modes, in rough order of frequency: citing a technique ID from memory (they change); attaching a technique to the wrong tactic; using ATLAS as decoration with no evidence behind it; and claiming a full chain when only one link was demonstrated.

A defensible finding structure:

Title:      Untrusted retrieved content drives unauthorised tool invocation
Tactic:     Execution (adversary-influenced inference -> tool call)
Chained to: Persistence via durable agent memory
Evidence:   Trace ID a41f — retrieved doc doc-7781 in context;
            records.export then mail.send within the same turn;
            memory write m-8842 with source=tool:web_fetch
Class:      OWASP LLM — prompt injection enabling excessive agency
Impact:     Any user able to add a document to the corpus can cause
            export and egress of records to an external address
Control:    Per-tool authorization on mail.send with recipient allowlist;
            memory write validation rejecting untrusted-source records

Rules that hold. State the tactic in words, and add an ID only if you verified it against the current matrix on the day you wrote the report. Every framework reference must be anchored to evidence you collected — trace IDs, log lines, screenshots. Name the chain honestly: if you demonstrated initial access and execution but only theorised persistence, say so explicitly. And give the remediation in the defender’s language, not the framework’s; nobody ships a fix called “mitigate this tactic.”

Common misuses to avoid

Misuse	Why it fails	Do this instead
Citing a technique ID from memory	IDs are revised; a wrong ID discredits the whole report	Name the tactic in words; verify IDs at write time
Mapping every finding to ATLAS	Some findings are ordinary application bugs	Map only where the adversary sequence adds information
Using ATLAS as a control checklist	It describes adversaries, not requirements	Pair with a control framework for the “so what do we build”
Claiming a full chain from one step	Overstating is the fastest way to lose credibility	Say explicitly which links were demonstrated
Building coverage matrices from diagrams	Manufactures confidence in absent logging	Validate each cell by running a query

A short adoption path

If your organisation has never used ATLAS, do not start by mapping everything. Start with one system and three weeks of narrow work.

Week 1 — inventory. List the AI system’s components, its tools, its data sources, and its identities. Nothing framework-shaped yet; ATLAS is useless against a system you cannot describe.
Week 2 — coverage. Fill in the detection matrix for five tactics only, validating each cell against real queries. Expect the honest answer to be worse than the assumed one.
Week 3 — one chain. Pick the highest-value chain from the coverage gaps and either test it or table-top it end to end. Produce one finding written in the structure above.

That output — an inventory, a validated coverage matrix, and one well-evidenced chain — is more persuasive in a review or an interview than a complete matrix mapping with nothing behind it. It is also a natural portfolio artifact; see Portfolio to Offer.

Where to go next

Vulnerability-class vocabulary to pair with these tactics: OWASP Top 10 for LLM Applications
Agent-specific threat mechanics: OWASP Agentic AI Threats & Mitigations
How these chains show up in production: Incident Patterns
Framework-to-control mapping: Governance and Evidence Automation
Building the artifacts that prove you can do this: Portfolio Artifacts

OWASP Agentic AI Threats & Mitigations Incident Patterns