MITRE ATLAS isn’t just a threat catalog, it’s a playbook for how AI systems break. In this blog, we explore what we can learn from it by doing the breaking ourselves: manipulating a RAG assistant with a sentence hidden inside a return policy, and bypassing a malware classifier by appending a few harmless-looking strings to a malicious file. Neither attack required a zero-day, stolen credentials, or insider access. Both are documented, named, and fully reproducible techniques straight out of the ATLAS framework.

This post walks through how that catalog actually gets used. Follow along: both demos are on GitHub 1. RAG prompt injection demo: github.com/sanjida-khanom/RAG-injection-demo_MITRE_ATLAS_Application 2. ML classifier evasion demo: github.com/sanjida-khanom/ML-evasion-demo_MITRE_ATLAS_Application

MITRE ATT&CK is a widely adopted knowledge base in security operations that catalogs how attackers behave against traditional IT systems, organized into tactics (their goals) and techniques (their methods). MITRE ATLAS is best understood as ATT&CK’s counterpart for artificial intelligence. Instead of cataloging attacks against networks, servers, and endpoints, it catalogs attacks against AI and machine learning systems: training pipelines, models, prompts, and inference APIs. It uses the same tactic-technique structure and even mirrors ATT&CK’s ID format, so a security team already fluent in ATT&CK can pick up ATLAS almost immediately.

Formally, MITRE ATLAS (which stands for the Adversarial Threat Landscape for Artificial-Intelligence Systems) is a free, publicly maintained knowledge base of adversary tactics, techniques, and real-world case studies specific to AI and ML systems. MITRE built it in collaboration with Microsoft and other industry partners, and has continuously expanded it since its 2020 launch as generative AI introduced entirely new categories of risk.

Understanding the Framework

• Tactics: the attacker’s goal, the “why”
• Techniques / Sub-techniques: the method used, the “how”, each with an ID like AML.T0051
• Case Studies: real documented incidents mapped to techniques
• Mitigations: defensive controls tied to each technique

ATLAS sits alongside other AI security references, not in place of them. OWASP’s Top 10 for LLM Applications is developer-facing, a checklist for code review. NIST’s AI RMF covers governance and org risk posture. ATLAS fills the gap between them: an adversary-centric catalog for planning red-team exercises, writing detection rules, or mapping a finding to an exact technique. Mature programs tend to cite all three.

The stakes aren’t hypothetical. Since August 2025, the EU AI Act has required providers of systemic-risk general-purpose AI models to run adversarial testing and show protection against unauthorized access. Regulators, auditors, and security teams need a shared, citable vocabulary for this, and ATLAS has become the default.

It now covers 16 tactics and 84 techniques, backed by 42 real-world case studies, and keeps growing as new attack classes are documented.

Next: two case studies, one against a modern LLM/RAG assistant and one against a classic ML classifier, each grounded in real incidents and mapped step by step to ATLAS tactic and technique IDs.

Walkthrough 1: Prompt Injection in a RAG-Based AI Assistant

Real-World Case: Morris II MITRE’s ATLAS team has documented Morris II, a proof-of-concept worm targeting GenAI email assistants built on retrieval-augmented generation (RAG). A hidden instruction is planted inside content the assistant later retrieves into its own context, no click or interaction from the victim required. Once retrieved, the model treats that instruction as part of the conversation and can be directed to leak data or take unauthorized action. This demonstrated attack is a major reason ATLAS expanded its generative-AI coverage through 2025 and 2026.

What makes this attack class hard to catch is where the malicious content lives. Traditional filters inspect things arriving at the edge of a system: an attachment, a login form, a file upload. RAG flips that model. The assistant is designed to trust whatever its retrieval step pulls back, treating it as reference material rather than external input. An indirect prompt injection hides inside that reference material, so by the time anything resembling “user input” is inspected, the instruction has already been folded into the model’s context as though it always belonged there.

Why It Matters

• RAG is now the default architecture behind enterprise chatbots, support assistants, and internal copilots
• The attacker never touches a login page or API; poisoned content just needs to end up somewhere the assistant will read it later (an email, a shared document, a support ticket)
• Standard input filtering misses this, because the model treats retrieved content as trusted background, not user input
• The same weakness applies to any agentic system that reads external content and can act on it: document summarizers, support bots, and web-browsing coding assistants all share the exposure

The exercise began with a question posed straight to the ATLAS matrix: which tactics apply to a system that ingests external content and acts on it? Initial Access, Execution, and Exfiltration stood out immediately, and under Initial Access, LLM Prompt Injection – Indirect (AML.T0051.001) matched the RAG assistant’s architecture almost exactly, a system built to trust retrieved content by default. That lookup decided what to build and test for.

How We Used ATLAS Here

1. Opened ATLAS’s Initial Access tactic and located AML.T0051.001 as the technique matching a system that trusts retrieved content by default.

2. Built a small, self-contained RAG assistant (local LLM plus a vector store), with no real user data
involved. Keeping the pipeline local and disposable meant the exercise could be repeated safely as many
times as needed.

3. Planted one hidden instruction inside a test document, written to blend into normal-looking text rather
than read as an obvious command, consistent with how indirect-injection payloads are described in
ATLAS’s own case studies

4. Asked the assistant an ordinary question that would pull the poisoned document into its context. Nothing about the request looked unusual; the assistant was simply retrieving relevant material.

5. Watched the hidden instruction execute, overriding the assistant’s original task, the outcome ATLAS’s own technique description predicts: the model has no reliable way to separate instructions from the user from text that happened to be retrieved, so it follows both with equal weight.

6. Went back to the matrix to trace what came next. Once the instruction executes, ATLAS lists Execution (AML.T0051) as the following step, and if that instruction directs the assistant to leak data, Exfiltration via AI Inference API (AML.T0024) as the step after that. Logging each stage against the matrix as it happened, not after the fact, made the full chain visible before a single mitigation was chosen.

7. Pulled up ATLAS’s own mitigation list for AML.T0051 and tested each listed control directly against the running assistant, rather than improvising a fix and hoping it held.

Atlas Mapping

The Link column points to each technique’s official page on atlas.mitre.org, where the same tactic, name, and
ID can be verified directly.

Stage	ATLAS Tactic	Technique	ID	Link
Hidden instruction placed in retrievable content	Initial Access	LLM Prompt Injection – Indirect	AML.T0051.001	View Page
Instruction is retrieved and followed	Execution	LLM Prompt Injection	AML.T0051	View Page
Assistant leaks data or acts for the attacker	Exfiltration	Exfiltration via AI Inference API	AML.T0024	View Page

Reading the Chain

Initial Access here doesn’t look like a login bypass or a network exploit. It’s just content placement: the poisoned document needs to exist somewhere the assistant will eventually read, and that’s it. Execution then happens on its own, driven by the model’s own instruction-following behavior rather than any code the attacker had to run. And Exfiltration, when the attacker includes a data-leaking instruction, happens through the assistant’s own legitimate output channel. That last part is exactly why this attack class slips past tools built for traditional intrusions: nothing about the traffic looks wrong.

Mitigations

• Provenance tagging: label retrieved content with source and trust level, so instructions from the user can be told apart from text pulled from a document, and downstream logic can treat the two differently by default
• Input/output screening: check for injected-instruction patterns before content reaches the model, or before its response triggers an action, using the same pattern and anomaly detection a SOC already runs on other data streams
• Narrow permissions: the assistant shouldn’t be able to send data anywhere just because a document told it to; tool access needs the same authorization checks a human action would require

Walkthrough 2: Evasion Attacks on an ML Malware Classifier

Real-World Case: Cylance Bypass (AML.CS0003) and Palo Alto Botnet Detector (AML.CS0001) One of ATLAS’s most cited entries documents how researchers reverse-engineered a commercial ML-based malware detector, then found that appending a handful of strings copied from known-clean files onto a malicious file was enough to flip the classifier’s verdict from “malicious” to “safe,” a near-universal bypass rather than a one-off trick. A related case shows Palo Alto Networks’ security AI team demonstrating the same class of weakness in a neural-network-based botnet detector, defeated with a generic domain-name mutation technique.

What makes the Cylance case worth sitting with is how little the attackers actually needed to know. No model weights. No training data. No confirmation of which algorithm was even in use. Just enough queries against the live product to work out which features moved the decision boundary. That’s the realistic threat model for almost any deployed classifier: most attackers get black-box access at best, and ATLAS’s case-study library shows, again and again, that black-box access has been enough.

Why It Matters

• Static and dynamic ML classifiers are now standard inside antivirus, EDR, and intrusion-detection products
• A single crafted perturbation can undo months of training if the model was never evaluated against adversarial inputs
• This is textbook Defense Evasion, the same tactic category attackers use to slip past any ML-based gatekeeper, not just malware scanners
• The Cylance bypass generalized across an entire malware family rather than a single sample, which is what separates a real vulnerability from a lucky one-off evasion

Same method, applied to a different kind of system. A deployed classifier is exposed as an inference endpoint by design, so the relevant tactics sit later in the chain than they did in the RAG case, there’s nothing to plant or deliver here. ATLAS’s ML Attack Staging tactic covers preparing an attack once a model is reachable, and Craft Adversarial Data (AML.T0043) matched directly: build an input that a real attacker with only query access could plausibly construct. Reading that technique off the matrix first is what decided the shape of the exercise.

Using ATLAS to Build the Test

1. Opened ATLAS’s ML Attack Staging tactic and located Craft Adversarial Data (AML.T0043) as the technique matching an attacker with query-only access to a live classifier.
2. Trained a small malware-vs-benign classifier locally on a public dataset, never a live product, keeping the exercise self-contained with no real malware samples or production tooling involved.
3. Studied the classifier’s behavior and decision boundary the way the technique’s own description assumes an attacker would: treating it as a black box, watching outputs across many inputs, without weights, training data, or knowledge of the algorithm.
4. Crafted a perturbed sample using IBM’s Adversarial Robustness Toolbox (ART), an open-source library implementing the same family of gradient-based and query-based methods AML.T0043 describes.
5. Ran the perturbed sample back through the classifier and measured the drop in detection rate, quantifying the drop rather than just confirming a single sample slipped through.

6. Returned to the matrix once the sample bypassed the classifier. That outcome is Defense Evasion (AML.T0015), the tactic ATLAS lists as what Craft Adversarial Data achieves once submitted. Mapping the two stages to two distinct tactics made clear where a defense actually needs to sit: at staging, before the query pattern completes, not only at the classifier’s final verdict.

7. Pulled ATLAS’s recommended mitigations for AML.T0015 and applied them directly, then re-tested against the same perturbed samples. Re-testing is the step most often skipped and most important to keep, it’s the only way to confirm a fix closes the gap rather than just adding friction.

A classifier that caught 94 percent of malicious samples fell to 16 percent after one crafted perturbation. Adversarial training clawed back to 46 percent, real progress, but nowhere near a closed gap. That’s the kind of number that’s easy to write as a bullet point and easy to underestimate in practice.

ATLAS Mapping

Stage	ATLAS Tactic	Technique	ID	Link
Building the perturbed sample	ML Attack Staging	Craft Adversarial Data	AML.T0043	View Page
Perturbed sample bypasses the classifier	Defense Evasion	Evade AI Model	AML.T0015	View Page

Reading the Chain

Unlike the prompt-injection case, nothing needs to get into the system here. The classifier is already exposed as an inference endpoint by design. That’s why this chain starts at Reconnaissance instead of Initial Access, the attacker’s entire job is understanding the model well enough to craft an input, staged under ML Attack Staging, that achieves Defense Evasion the moment it’s submitted. There’s no delivery step to intercept, which is exactly why detection has to focus on the querying pattern itself rather than on the file that eventually slips through.

Mitigations

• Adversarial training: include adversarial examples in the training set so the model learns to resist small perturbations, rather than only ever seeing clean malicious and clean benign samples
• Ensemble verification: cross-check suspicious “clean” verdicts against a second, differently-trained model before trusting the result, since an evasion technique tuned against one architecture rarely transfers perfectly to another
• Recon monitoring: watch for repeated, near-duplicate submissions, a pattern that usually precedes an evasion attempt, since attackers typically need many queries to find the boundary they’re trying to cross

Seeing Both Exercises on the Matrix at Once

Laid side by side, the two chains only touch six of ATLAS’s sixteen tactics, and even fewer of its eighty-four techniques. That’s not a shortcoming of the exercises; it’s what a real, targeted red-team pass against a specific system looks like. Nobody tests the whole matrix at once. You test the slice that matches your architecture.

What These Two Cases Have in Common

A conversational GenAI system and a signature-style ML classifier don’t have much in common as technology. But run both through ATLAS and the same rhythm shows up twice: consult the matrix, then build and attack, then return to the matrix for the mitigation. ATLAS decided what to test, in what order, and against which list of fixes, in both exercises. A few other things held true across both:

• Both begin with the attacker studying normal behavior rather than attempting a brute-force break-in. Reading how a system responds is cheaper and quieter than trying to force it.
• Both exploit the model doing exactly what it was trained to do, just on an input the defenders never tested against.
• Both chains are short, three to four tactics from start to impact, typical of ATLAS-documented incidents compared to the longer chains common in traditional ATT&CK case studies.
• Both were closed the same way at a conceptual level: the fix has to happen during training or validation, not only during a post-deployment red-team exercise.

That overlap is the real case for learning ATLAS properly instead of memorizing technique names in isolation. Once the rhythm, matrix, build, attack, mitigate, is familiar, it transfers cleanly to whichever AI system a team gets asked to red-team next, GenAI or otherwise.

Key Takeaways

• ATLAS is a practical scaffold, not just a reference chart: every stage of both exercises had a specific tactic and technique ID attached before any mitigation work began
• Both walkthroughs followed the same rhythm: consult the matrix, then build and attack, then mitigate. That rhythm is reusable on almost any ML-based system, arguably ATLAS’s biggest practical advantage over a purely descriptive reading of its matrix
• Hands-on beats reading: running even a scaled-down version of one of these exercises against your own model teaches more than reading the matrix cover to cover; technique names stop being abstract once you watch AML.T0051 or AML.T0015 happen against something you built
• ATLAS Navigator, free at atlas.mitre.org, is the fastest way to see where your own system sits on the matrix, and exports directly into the kind of coverage layer a reviewer or auditor would expect
• For any team deploying LLM-based assistants or ML-based detection systems without having run either kind of exercise, that gap is worth closing before an external red team, or a real attacker, closes it first