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 call for destination control. Context-window inspection addresses execution and defense evasion. Prompt classification covers collection and exfiltration. Agent persistence needs authorization for model requests, while impact needs 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.

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 is the useful catalog for AI-specific adversary behavior, but an enterprise consuming hosted models needs a narrower reading than a model developer. The MITRE ATLAS site and the maintained ATLAS data repository describe techniques across training, model artifacts, and deployed inference. Only the techniques that traverse a model request can be evaluated by a request-path control.

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.

TL;DR

ATLAS covers AI threats across model development and deployed inference. An HTTP AI gateway can enforce only the techniques that cross a request to an LLM endpoint.
Use destination control, context inspection, prompt classification, and identity-bound decision records for the request-path techniques.
Assign training, supply-chain, artifact, and host compromise to their owning controls instead of treating a gateway mapping as complete coverage.

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

Keep a short control register for the request-path techniques:

Reconnaissance and model access: destination allowlist routing fires during request routing and creates a per-identity destination record.
Execution and defense evasion: context-window inspection fires before transmission and records the transmitted prompt with the decision.
Collection and exfiltration: prompt classification runs before transmission and records the data class and outcome for that request.
Agent persistence: authorization for model requests made by an agent records the agent identity, allowed route, and decision. Tool-endpoint authorization remains a separate control.
Impact: per-identity rate and volume policy acts at the request boundary and supplies a volume record by principal.
API-visible discovery: response policy can record the response-path decision. Host-side credential acquisition needs identity and endpoint controls outside the inference request.

The tactics this mapping does not cover

Naming the gaps is what separates a mapping from a marketing table. Training-data poisoning belongs with the training team. A poisoned package or altered pretrained artifact belongs with supply-chain controls. Access to model artifacts on disk and host compromise require endpoint and host telemetry. Those ATLAS scenarios do not traverse an HTTPS inference request, so they need 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.