Map Red-Team Findings to MITRE ATLAS

Tier: Advanced · Workflow area: AI red-team program & tooling

ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is the ATT&CK-style knowledge base of real-world tactics and techniques against ML/AI systems. This playbook maps your own red-team results onto ATLAS tactics and techniques so your program produces coverage analysis, not just a to-do list — turning scattered findings into a defensible picture of your defensive posture.

When to reach for this

• •
  You have a triaged set of confirmed findings (from pb-44) and need to express them in an industry-standard threat framework.
• •
  Leadership, auditors, or a threat-modeling exercise ask "which adversary techniques are we exposed to, and where are our blind spots?"
• •
  You want to reason about coverage — which ATLAS techniques you actively test for versus never probe — to steer the next red-team sprint.
• •
  Skip a full ATLAS mapping for a single tactical fix; reach for it when building or reporting on the program.

The workflow

1. 1.

   Learn the ATLAS structure. ATLAS mirrors ATT&CK: tactics (the adversary's goal — Reconnaissance, ML Attack Staging, Defense Evasion, Exfiltration, Impact) contain techniques (the how — for example, LLM Prompt Injection, LLM Jailbreak, LLM Plugin Compromise, Erode ML Model Integrity, LLM Data Leakage).

2. 2.

   Map each confirmed finding to a technique. For every backlog item, name the ATLAS technique it demonstrates and the tactic it serves.

   Copy

   Finding: indirect injection via poisoned RAG document → system-prompt disclosure
     Tactic:    Defense Evasion / Exfiltration
     Technique: AML.T0051 LLM Prompt Injection (Indirect)
                AML.T0057 LLM Data Leakage
     Evidence:  garak leakreplay + confirmed manual repro (ticket SEC-214)
   

3. 3.

   Build a coverage matrix. List the ATLAS techniques relevant to your architecture (an LLM+RAG+tools app touches injection, jailbreak, data leakage, plugin/tool compromise, model-provenance and supply-chain techniques). Mark each as tested-and-passing, tested-and-failing, or never-tested.

4. 4.

   Surface the blind spots. The never-tested column is the finding. If your scans never exercise, say, ML supply-chain or memory-poisoning techniques that apply to your design, that is a coverage gap to feed into the next sprint — not evidence of safety.

5. 5.

   Reference ATLAS case studies for realism. ATLAS documents real incidents (RAG poisoning, model-integrity attacks). Use them to sanity-check that your severity and likelihood assessments match observed adversary behavior.

6. 6.

   Version the mapping with the app. Store the coverage matrix alongside the red-team suite so it evolves as the architecture and the framework do; ATLAS is updated as new AI attack techniques emerge.

Verify before you trust it

The mapping is trustworthy when it is complete against your architecture and honest about coverage. Completeness check: walk the ATLAS technique list and confirm that every technique applicable to your system's design (does it use RAG? tools? external model supply chain? persistent memory?) appears in your matrix with a status — a technique that applies but is absent is an undocumented blind spot. Honesty check: for every technique marked "tested and passing," point to the specific probe or test case and a passing run that exercises it; "passing" with no test behind it is wishful mapping. The deliverable is complete only when there are no applicable-but-unlisted techniques and no "covered" claims without evidence.

Pitfalls

• Mapping to make coverage look good. The point is to expose blind spots. Marking techniques "covered" without a test that exercises them defeats the exercise and misleads leadership.
• Ignoring techniques your design invites. An agent with tools and memory has a wider ATLAS surface than a stateless chatbot. Scope the matrix to your actual architecture, not a generic checklist.
• One finding, one technique. A single indirect-injection-to-exfil chain often spans several tactics and techniques. Map the full chain, not just the entry point.
• Treating ATLAS as static. The framework adds techniques as new AI attacks emerge. A mapping done once and never revisited drifts out of date.
• Confusing ATLAS with OWASP. They are complementary — OWASP LLM/Agentic Top 10 is a risk taxonomy for builders; ATLAS is an adversary-technique taxonomy. Use both; do not substitute one for the other.

Tools

• MITRE ATLASthe free adversary-technique knowledge base and navigator for AI systems; the tactic/technique vocabulary and case studies at the center of this task.
• Garaksupplies probe results whose failure classes map cleanly onto ATLAS techniques like prompt injection and data leakage.
• PyRITsupplies multi-turn attack chains that often span several ATLAS tactics, making them the richest input to the coverage matrix.

Client-safe variant

An ATLAS coverage matrix is an excellent client deliverable because it communicates risk in a standard framework without exposing raw exploits. In an engagement, build the mapping from the client's own confirmed findings, keep the evidence references (ticket IDs, prompts, outputs) inside their boundary, and hand over the matrix as a living artifact their security team maintains. Present the blind-spot analysis as the prioritized next-sprint recommendation. Use only publicly published ATLAS content — the framework is free and open — and avoid attributing techniques to the client's specific customers or data. Do not carry one client's coverage matrix or discovered techniques into another engagement.