How many MITRE ATLAS tactics and techniques are there?

Version 5.1.0, published in November 2025, carried 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations, and 42 real-world case studies. The February 2026 update added further techniques aimed at autonomous agents and the tools they invoke, covering context and memory poisoning, agent configuration tampering, credential harvesting, and exfiltration through tool calls.

Which ATLAS tactics can a gateway enforce against?

Reconnaissance and ML model access through destination control, execution and defense evasion through context window inspection, collection and exfiltration through prompt classification, agent persistence through per-tool-call authorization, and impact through per-identity volume policy. Discovery and credential access are partially covered, since the API-visible half is enforceable and the host-side half is not.

How does ATLAS compare to the ATT&CK framework?

ATLAS reuses ATT&CK's structure, with tactics as adversary objectives and techniques as the methods that achieve them, and adds tactics specific to machine learning such as ML model access and ML attack staging. Teams already running ATT&CK-based detection engineering find the model familiar, and the practical difference is that far more ATLAS techniques target a development pipeline than target a running production service.

Should ATLAS or the OWASP LLM Top 10 drive our control selection?

Use both for different purposes. The OWASP LLM Top 10 scopes engineering work against vulnerability classes, while ATLAS structures detection, red team scenarios, and incident reconstruction against adversary behaviour. The OWASP Agentic Top 10 mapping covers the agent-specific overlap that the 2026 ATLAS additions also address.

Do these controls require changing the model or the provider?

They operate at the HTTP boundary between the application and the model endpoint, so they are model-agnostic and need no retraining or provider-specific integration. The application continues to supply identity context, which is its role in any identity-aware design, while inspection, classification, routing, enforcement, and recording happen in the request path.

MITRE ATLAS AI Controls Mapping: Which Tactics Reach an HTTPS Request and Which Never Will

MITRE ATLAS carried 16 tactics and 84 techniques at version 5.1.0 in November 2025, with 56 sub-techniques, 32 mitigations, and 42 case studies behind them, and the February 2026 update pushed the matrix into autonomous agents. Reading it as a coverage exercise produces a spreadsheet where every row gets a green cell and nothing improves.

The useful reading starts with a question the framework does not ask: where does the adversary have to be standing. Around a dozen ATLAS techniques put the adversary somewhere your inference traffic passes, which makes them addressable by a control in the request path. The rest put them in a training pipeline, a package registry, or a filesystem holding model weights. I want to map the first group onto the control that actually fires, and name the second group as work for a different team rather than stretching a proxy across it.

The control point: one HTTPS request

Every mapping below resolves to the same moment. An HTTPS POST carries an assembled context window to a model endpoint, and a response comes back. At that instant the caller is known, the full prompt is available to inspect, the destination is chosen, and a record is either written or lost. An ATLAS technique that traverses that moment is controllable. One that never touches it is not, whatever a mapping spreadsheet says.

Reconnaissance and ML model access

Adversaries in these tactics learn what model sits behind an endpoint and establish a channel to it, whether by probing a production inference API or by reaching an endpoint nobody sanctioned. Destination-aware routing with an allowlist is the control, so requests reach approved endpoints and everything else fails closed. Evidence takes the form of a destination log naming every endpoint called, grouped by principal, which turns a volume spike into an attributable sequence rather than a busy service account.

Execution and defense evasion

Prompt injection in direct and indirect forms sits here alongside jailbreak techniques, and this is where most enterprise exposure concentrates. Inspection of the assembled context window before transmission is the control, applied to retrieved documents, tool output, and system instructions rather than to the user's typed message alone. Evidence is the transmitted context window stored against the policy decision made about it, which is the only artifact that shows what the model actually saw. The mechanics are covered in indirect prompt injection defense.

Collection and exfiltration

ATLAS treats the inference API as an exfiltration channel, and the 2026 agent techniques extend that to exfiltration through tool invocation. For an enterprise the pressing direction is outbound regulated data rather than extracted model internals. Prompt-level classification evaluated before transmission is the control, bound to per-role policy so a caller whose role lacks a basis for the data category is blocked. Evidence is a per-request classification decision joined to the destination that received it, which prompt-level DLP produces at transmission rather than at rest.

Persistence and privilege escalation in agent systems

The February 2026 additions cover context and memory poisoning, agent configuration tampering, and credential harvesting, which together describe an adversary who writes once and gets execution repeatedly. Per-call authorization on agent tool invocations is the control, applying the same identity binding and destination allowlist to calls the agent makes as to the original request. Evidence is an authorization decision recorded per tool call against the agent identity, retained long enough that the originating write is still in the window.

Impact

Denial of service against an ML system and cost harvesting both present as traffic shape. Per-identity rate and volume policy at the boundary is the control, with a fail-closed default. Evidence is the destination and volume record per principal, the same artifact the reconnaissance row produces, read for a different purpose.

Discovery and credential access, partially

Both tactics straddle the boundary. Where an adversary discovers model ontology or family through API responses, the request path sees it. Where credentials are harvested from a host, an environment file, or a CI secret store, nothing in your inference traffic will show it until the stolen credential is used, and by then the control that matters is whether an unrecognised caller reaching a model endpoint fails closed.

The mapping at a glance

The tactics this mapping does not cover

Naming the gaps is what separates a mapping from a marketing table. Training data poisoning against a model you build, ML supply chain compromise through a poisoned package or tampered pretrained model, direct access to model artifacts on disk, and physical or host-level compromise all appear in ATLAS and none of them traverse an HTTPS inference request. Controls for those live in the build pipeline, the artifact registry, dependency provenance, and host telemetry, and they belong to a different owner on the risk register.

My frank opinion: ATLAS is more useful to enterprises than its structure suggests and more often misused than any other AI security artifact I see. The matrix was assembled with model developers and researchers in view, and the companies adopting it are overwhelmingly consumers of hosted models. A mapping that gives equal weight to all 84 techniques produces confident coverage over ground the organisation does not stand on, while the dozen techniques aimed straight at its inference path get one row each.

DeepInspect

Each reachable row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call, evaluates identity, assembled prompt content, and destination on every request, enforces per-role and per-route policy with a fail-closed default, applies the same evaluation to agent tool calls and to responses, and writes a signed per-decision record before the response returns to the application.

For a team running ATLAS as its AI threat model, that turns the execution, exfiltration, persistence, and impact rows into controls with a per-decision record standing behind each one, and leaves the training and supply chain rows honestly assigned elsewhere. The audit evidence view covers what each artifact has to hold, and the ten-item checklist sequences the build. Book a technical deep dive at deepinspect.ai.