ATLAS is MITRE's knowledge base of adversary tactics and techniques against AI-enabled systems, structured the same way ATT&CK structures adversary behavior against conventional systems. It carries technique identifiers, real-world case studies, and mitigations, which lets an AI security program use the same detection-engineering vocabulary the rest of the security organization already speaks.

What is the MITRE ATLAS ID for prompt injection?

AML.T0051, LLM Prompt Injection. It has two sub-techniques: AML.T0051.000 for direct injection, where the adversary submits the malicious prompt to the model's interface or API, and AML.T0051.001 for indirect injection, where the payload is embedded in content the model later retrieves or processes, such as a document in a RAG system or a scraped web page.

How is MITRE ATLAS different from the OWASP LLM Top 10?

The OWASP Top 10 for LLM Applications is a ranked risk list for builders: what tends to go wrong, ordered by prevalence and impact. ATLAS is an adversary-behavior model for defenders: what an attacker does, in sequence, with identifiers that map to detections. They complement each other, and several ATLAS techniques map directly onto OWASP entries, with AML.T0057 corresponding to sensitive information disclosure and AML.T0053 to excessive agency.

Which ATLAS techniques can a policy gateway enforce against?

The ones that cross the HTTP AI boundary. Direct and indirect prompt injection both arrive inside the assembled context window that the proxy parses. Jailbreak is observable in the response. Data leakage is a classification decision on the payload with an identity attached. Plugin compromise is an authorization decision at the tool invocation. Training-data poisoning is an artifact problem that never touches the request path, and a gateway that claims coverage of it is describing something it never sees.

Should a red team scope AI engagements against ATLAS?

Yes, because it produces findings the blue team can act on. A finding written as "the model was jailbroken" prompts an argument. A finding written as "AML.T0051.001 via a poisoned Confluence page reached AML.T0054 and then AML.T0057, exfiltrating customer records through the summarization endpoint" names the entry, the state, the objective, and the control point that was missing at each step.

MITRE ATLAS and Prompt Injection: Mapping AML.T0051 to Control Points You Can Actually Enforce

MITRE ATLAS assigns prompt injection the identifier AML.T0051 and defines it as crafting malicious prompts that cause a language model to ignore aspects of its original instructions and follow the adversary's instead. It splits into two sub-techniques: Direct, at AML.T0051.000, where the adversary submits the prompt to the model's interface or API, and Indirect, at AML.T0051.001, where the payload is embedded in data the model later retrieves, such as a document in a RAG pipeline or a web page it scrapes (MITRE ATLAS).

ATLAS is built on the ATT&CK model, which is why it is worth using in preference to a ranked risk list. It describes a sequence rather than a set. An adversary injects in order to reach a state, and the state is worth something because of what it permits next. Mapping the chain gives you the control points.

The distinction between .000 and .001 is operational, not academic

Direct injection arrives in the field the user typed. It is in scope for any control that examines user input, including the application's own validation.

Indirect injection never appears in anything the user typed. The payload sits in a Confluence page, a PDF in a shared drive, a product description in a catalog, or an MCP tool description, and it reaches the model when the retrieval pipeline pulls it into the context window. The application validated the user's input and passed it. The injection travelled in the part of the prompt the application assembled on the user's behalf.

That is why prompt-side input validation reports clean while the deployment is being exploited. The two sub-techniques enter the context window through different doors, and only one of those doors has a validation step in a typical build.

The control that covers both examines the fully assembled context window, after retrieval, after system-prompt injection, after tool descriptions are appended, immediately before the HTTP call to the model leaves the process.

The techniques downstream of AML.T0051

Injection is the enabling step. Three ATLAS techniques sit behind it and describe what the adversary is actually after.

AML.T0054, LLM Jailbreak. The model is moved into a state where its trained refusal behavior stops holding, and the adversary can then direct it without the usual limits. The observable form is a refusal-to-compliance flip inside a session: the model declines a request, then complies with a rephrasing of it a few turns later.

AML.T0057, LLM Data Leakage. Sensitive data, including intellectual property, leaves through the model. It maps to OWASP's LLM02 sensitive information disclosure. This is the technique with a dollar figure attached: IBM's Cost of Data Breach research found shadow AI-linked breaches cost $670,000 more on average, exposed customer PII in 65% of cases against 53% across all breaches, and took 247 days to detect (IBM).

AML.T0053, LLM Plugin Compromise. The model's tool surface is turned against the environment, mapping to OWASP's LLM06 excessive agency. Sysdig's July 1, 2026 JadePuffer disclosure is this technique at full extension: an LLM agent running recon, credential theft, lateral movement, and database extortion without a human in the loop (Sysdig).

Read them together and the chain reads: inject, achieve state, then exfiltrate or act. Controls placed against the objectives, rather than against the enabling technique alone, survive an adversary who finds a new way to inject.

Mapping the chain to control points

| ATLAS technique | Where it lands | Control point | Enforceable inline | |---|---|---|---| | AML.T0051.000 Direct injection | User input field | Input classification at the request boundary | Yes | | AML.T0051.001 Indirect injection | Retrieved content, tool descriptions | Assembled context-window classification | Yes | | AML.T0054 Jailbreak | Model state | Response-side refusal-flip detection | Yes | | AML.T0057 Data leakage | Prompt or response payload | Data classification plus identity-bound egress policy | Yes | | AML.T0053 Plugin compromise | Tool invocation | Per-invocation authorization against the requesting identity | Yes | | Training-data poisoning | Model artifact | Artifact provenance and signing | No | | Model extraction via API | Query volume and pattern | Per-identity rate policy | Partially |

Five of the seven land on the HTTP AI boundary, because that is where the prompt, the response, the identity, and the tool invocation all become visible at the same moment. Training-time poisoning does not cross it at all, and I would rather say so than map an artifact problem onto a proxy.

The detection engineering view

An ATLAS mapping is only worth the detections it produces. Write one event per AI decision, tagged with the technique it evidences:

The injection_source field is the one that earns its keep. When an indirect injection fires, the value of the detection is the pointer to the poisoned artifact, because the same document will fire again on the next retrieval for a different user. A detection that reports "prompt injection blocked" and omits the source has closed one request and left the corpus poisoned.

What ATLAS gives you and what it leaves open

ATLAS gives you a shared vocabulary with the rest of the security organization, a structure for red-team scoping, and case studies drawn from real incidents. It maps cleanly onto ATT&CK-shaped detection engineering, which means AI detections stop being a separate practice with its own dashboard.

What it leaves open is the enforcement question. A technique catalog describes adversary behavior. It says nothing about where in your architecture a decision can be made, and with Mandiant's M-Trends 2026 finding the median handoff from initial access to a secondary threat group at 22 seconds in 2025, down from over eight hours in 2022 (Help Net Security), a detection that fires into a queue describes an outcome that has already happened.

The mapping above is worth doing because it terminates in control points rather than in a heat map. I cover the detection side in prompt injection detection and the layered defenses in prompt injection defense in depth.

DeepInspect

This is exactly what DeepInspect does. DeepInspect is a stateless proxy at the AI request boundary, sitting between authenticated users or agents and any HTTP-based LLM endpoint. It parses the fully assembled context window, which is where both ATLAS sub-techniques converge, scores it for injection and jailbreak signals, evaluates the data classification of its contents against the verified identity and role of the caller, and permits, redacts, or denies inline with a fail-closed default at under 50 ms of overhead in internal testing.

Every decision writes a signed record carrying the identity, the model and version, the policy version in force, the signal scores, and the ATLAS technique the detection evidences, committed before the response returns to the calling application. That gives a SOC AI detections in the same shape as its ATT&CK detections, produced by a component the application under investigation does not control.

If your red team maps to ATLAS and your production controls stop at the application's input validation, book an AI readiness assessment.