MITRE ATLAS AI Compliance Checklist: Ten Actions Against the Techniques That Reach Your Traffic
MITRE ATLAS carries 16 tactics and 84 techniques as of version 5.1.0 in November 2025, with agent-focused additions landing in February 2026. Most of the matrix describes attacks on models you train. This checklist works the subset that reaches an enterprise consuming hosted models over HTTP, giving ten actions with the ATLAS tactic each one addresses and the evidence it produces, and marking the techniques that need build-pipeline work instead.
Version 5.1.0 of MITRE ATLAS, published in November 2025, holds 16 tactics and 84 techniques with 56 sub-techniques, 32 mitigations, and 42 case studies behind them. A February 2026 update added techniques aimed at autonomous agents, covering context and memory poisoning, agent configuration tampering, credential harvesting, and exfiltration through tool invocation.
Working the whole matrix is the wrong instinct for an enterprise. A large share of ATLAS describes attacks on models an organisation trains itself, and the companies adopting the framework mostly consume hosted models through an application. This checklist covers the subset that reaches you through HTTP AI traffic, in the order the tactics tend to run, with the artifact each action produces. Items 9 and 10 name the work that sits outside the request path.
1. Attribute every model request to a named principal
Route AI traffic so a named user or agent, rather than a shared API key, is attached to each prompt. Evidence is a per-request record showing which principal sent which prompt to which model. This addresses nothing on its own and makes every item below usable, because reconnaissance, exfiltration, and impact techniques are all detected by grouping traffic by identity, and one service credential collapses every caller into a single row.
2. Allowlist model destinations and fail closed on the rest
Restrict outbound AI calls to approved endpoints, with anything unrecognised blocked rather than logged. This addresses the ML model access tactic directly, since an adversary reaching an unmanaged endpoint from inside your network bypasses every control you built on the sanctioned path. Evidence is a destination log naming every endpoint called during the period, which reliably surfaces calls nobody registered. The same reconciliation drives shadow AI discovery.
3. Store the assembled context window, not the user's message
Capture the prompt as transmitted, including retrieved documents, tool output, and system instructions. This addresses the indirect prompt injection sub-techniques under execution and defense evasion, where the hostile instruction arrives inside retrieved content. Evidence is the transmitted context window stored against the decision made about it, and a log holding only the typed message will show a benign request and hide the payload.
4. Classify prompt content before transmission
Evaluate the classification of the context window at the boundary, tied to per-role policy so a caller without a basis for the data category gets blocked. This addresses the collection and exfiltration tactics in the direction that matters to an enterprise: regulated data leaving through a prompt. Evidence is a per-request classification decision joined to the destination that received it.
5. Inspect the response, not only the request
Apply classification and policy to model output before it returns to the caller. This addresses sensitive information disclosure and the output-handling techniques, and it is the only place a response carrying data the caller was never entitled to can be caught. Evidence is a response-side classification and policy record joined to the request that produced it.
6. Constrain what an agent's tool calls may reach
Where agents invoke tools that make further HTTP calls, apply the same destination allowlist and identity binding to those calls. This addresses the February 2026 additions covering exfiltration through tool invocation and credential harvesting, where the model's own judgement about a destination is the only thing standing between an instruction and an outbound request. Evidence is a per-call authorization decision recorded against the agent identity that made it.
7. Retain request logs long enough to contain the originating event
Set retention so a memory or context write can still be found weeks after the behaviour it caused. This addresses the agent persistence techniques, where an adversary writes once and gets execution repeatedly. Evidence is a retained request log with a stated window. Seven days is a common default and it regularly fails to reach the write. AI audit log retention requirements covers what the regimes ask for against what an investigation needs.
8. Keep the evidence write path outside the application
Ensure the record is produced by a system the application making the AI call has no custody over, so it survives selective logging, later modification, and crash-loss between the model response and the log commit. This addresses the practical failure mode behind every detection above, and the reasoning sits in You Own the AI Liability, Not the Vendor.
9. Cover the training and supply chain techniques somewhere else
Poisoning of training data, tampering with a pretrained model, and compromise of an ML package leave no trace in inference traffic. Evidence for these comes from build pipeline logs, artifact registry attestations, and dependency provenance. Put them on the same risk register and give them a different owner, because a request-path control that claims this ground is the fastest way to lose a security architect's trust.
10. Run a red team against the in-boundary subset and reconcile the findings
Exercise prompt injection, jailbreak, and exfiltration paths against production configuration, then check whether your telemetry shows each attempt. My honest take: this reconciliation step is the one that changes programmes, because the usual result is that the attack succeeded and the log recorded a successful request with no indication anything happened. Finding that out from your own red team costs a week. Finding it out during an incident costs the investigation.
Where the checklist concentrates
Items 1 through 8 fire at the same moment: an HTTPS POST carrying a context window to a model endpoint. The ATLAS controls mapping sets out which tactic lands on which enforcement point, and the audit evidence view covers what each artifact has to contain to answer a post-incident question.
DeepInspect
Eight of these ten items produce evidence at the boundary between your users or agents and the LLM APIs they call, and DeepInspect sits at that boundary. It binds identity to each request, captures and classifies the assembled context window before transmission, enforces per-role and per-route policy with a fail-closed default, allowlists and records destinations including agent tool calls, inspects the response, and writes a signed per-decision record the application never had custody of.
For a team working ATLAS, items 3 and 8 are the two that decide whether the rest is real, because the transmitted context window is the only artifact that shows what the model actually saw and write-path independence is what makes it evidence. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Can you be compliant with MITRE ATLAS?
No certification exists. ATLAS is a threat knowledge base rather than a control standard, so it gets used as the threat-model input that justifies a control set, informs red team scope, and structures incident reconstruction. Auditors increasingly ask which threat model drove a control selection, and an ATLAS mapping is a defensible answer to that question inside an ISO 42001 or SOC 2 programme.
- How many ATLAS techniques apply to an enterprise using hosted models?
Roughly a dozen of the 84 reach an enterprise through its inference traffic, concentrated in reconnaissance, ML model access, execution, defense evasion, collection, exfiltration, and impact. The bulk of the matrix addresses model development, training pipelines, and direct artifact access. Scoping honestly to the reachable subset produces better coverage than mapping every row.
- Does this checklist replace the OWASP LLM Top 10?
They sit next to each other. The OWASP LLM Top 10 enumerates vulnerability classes for application design, while ATLAS models adversary behaviour in sequence. Running both means the engineering backlog comes from OWASP and the detection and red team scope comes from ATLAS, with a large overlap in the controls that satisfy either.
- What changed in the 2026 ATLAS updates?
The February 2026 release extended the matrix into autonomous agents, adding techniques for context and memory poisoning, agent configuration tampering, credential harvesting, and exfiltration through the tools an agent invokes. That shifts the exposure from a single prompt-response exchange to a sequence of them, which is why retention and per-tool-call authorization appear as separate items on this list.
- Do these controls require access to model internals?
They operate on HTTP traffic between the application and the model endpoint, so they work in front of any hosted or self-hosted model with no retraining or provider-specific integration. Techniques targeting weights, training data, or the ML build pipeline sit outside that boundary, which is exactly why item 9 assigns them elsewhere rather than claiming coverage.