← Blog

MITRE ATLAS AI Audit Evidence: The Telemetry That Proves a Technique Fired

MITRE ATLAS reached 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations, and 42 case studies at version 5.1.0 in November 2025, with agent-focused techniques added in the February 2026 update. A technique is only useful in a review if you can show whether it fired. This walks the evidence artifacts that answer that question for the ATLAS tactics reachable over HTTP AI traffic, and names the tactics where no request-path telemetry helps.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationai-securityllm-securityauditforensic-auditai-governance
MITRE ATLAS AI Audit Evidence: The Telemetry That Proves a Technique Fired

MITRE ATLAS reached 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations, and 42 documented case studies at version 5.1.0 in November 2025, and the February 2026 update pushed further into autonomous agents with techniques covering context and memory poisoning, agent configuration tampering, and exfiltration through tool invocation. The matrix is built on the ATT&CK model, so it carries the same implicit promise: a technique in the matrix is a thing you can look for.

Looking for it requires telemetry, and this is where AI security work tends to stall. A red team maps its findings to ATLAS technique names, hands over a report, and the receiving team discovers that reproducing or refuting any of it after the fact means reading application logs that were never designed to answer the question. I want to walk the artifacts that actually answer "did this technique fire, and when," for the tactics that reach an enterprise over HTTP AI traffic.

Reconnaissance and ML model access

The early tactics cover an adversary learning what model sits behind an endpoint and getting a channel to it. Against a hosted model consumed through your application, that channel is your inference path, and probing it looks like ordinary traffic with unusual shape: a burst of prompts from one principal that walk model behaviour rather than doing work.

The artifact that answers this is a per-request record carrying the caller identity, the destination endpoint and model version, and a timestamp with enough precision to correlate. Volume anomalies mean nothing without the identity column, because a spike attributed to a shared service account tells you a service was busy and nothing about who was driving it.

Execution and defense evasion at the prompt layer

Prompt injection and jailbreak techniques sit here, in both direct and indirect forms, and they are the ATLAS entries most enterprises are actually exposed to. Indirect injection is the harder one to evidence, because the hostile instruction arrives inside retrieved content rather than from the user.

The artifact is the assembled context window as transmitted, stored alongside the decision made about it. Storing the user's typed message and discarding the retrieved fragments produces a record that shows a benign request and hides the payload. I set out the mechanics in indirect prompt injection defense, and the evidence requirement follows directly: whatever the model saw is what the log has to hold.

Collection and exfiltration through the inference API

ATLAS treats the inference API as an exfiltration channel in its own right, and the agent-focused February 2026 additions extend that to exfiltration through tool invocation. For an enterprise, the exposure runs in the direction the framework spends less time on: regulated data leaving through a prompt, rather than model internals leaving through a response.

Evidence here is a per-request classification of prompt content evaluated before transmission, joined to the destination that received it. That pairing is what converts "someone may have pasted customer records into a model" into a list of principals, timestamps, and endpoints. Document-level labels inherited from a source system answer a different question, which is why prompt-level DLP produces this artifact and a data catalogue does not.

Persistence in agent memory

The 2026 agent techniques introduce a problem the matrix did not previously have: an adversary who writes to memory once and gets execution repeatedly. Reconstructing that means finding the write, which happened in a request that looked unremarkable at the time, and then finding every later request that read it.

The artifact is a retained request log covering a window long enough to contain the write. Most AI logging retains days. The write that matters is regularly weeks old, which makes retention a security property rather than a compliance formality. AI audit log retention requirements covers the periods the various regimes expect and where they fall short of the forensic need.

Impact and cost harvesting

Denial of service against an ML system and cost harvesting both show as traffic. The evidence is a destination and volume record per principal, which is the same artifact from the reconnaissance row read a different way. Grouping by identity rather than by service is again the property that makes it usable.

The tactics no request log will help with

Being honest about coverage is what makes an ATLAS mapping credible. Several tactics sit outside anything an HTTP request path can see. Training data poisoning against a model you build, physical or filesystem access to model artifacts, ML supply chain compromise through a poisoned package or a tampered pretrained model, and model theft through direct access to weights are all real ATLAS entries and none of them touch your inference traffic. Evidence for those comes from build pipelines, artifact registries, and host telemetry.

My candid view: the gap between ATLAS's research framing and enterprise reality is wider than the framework's popularity suggests. A large share of the matrix describes attacks on models you train, while the enterprises adopting ATLAS overwhelmingly consume hosted models and are exposed through the request path. Mapping all 84 techniques with equal weight produces a spreadsheet that flatters coverage. Mapping the dozen that reach your traffic, and evidencing those properly, produces something a post-incident review can use.

What the evidence set looks like

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Five of the six rows come from one store. The sixth comes from somewhere else entirely, and saying so is part of the mapping.

DeepInspect

This is the evidence layer an ATLAS-mapped investigation reaches for on the traffic side. DeepInspect sits inline between your users or agents and the LLM APIs they call. Every request is evaluated for identity, prompt classification, and destination, policy is enforced per role and per route with a fail-closed default, and a signed, tamper-evident record is written before the response returns to the application.

That record holds the principal, the transmitted context window, the classification found in it, the model endpoint and version, the policy revision that governed the decision, and the outcome. When a red team report names a technique and asks whether it fired in production, the answer comes from a query rather than a reconstruction. The ATLAS controls mapping lines each in-boundary tactic up against the enforcement point that addresses it. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

What is MITRE ATLAS?

ATLAS is MITRE's knowledge base of adversary tactics and techniques against AI and machine learning systems, structured like ATT&CK with tactics as columns and techniques as rows. Version 5.1.0, published in November 2025, carried 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations, and 42 real-world case studies, and the February 2026 release added techniques aimed at autonomous agents and the tools they call.

Is ATLAS a compliance framework?

It is a threat knowledge base rather than a control catalogue, so nobody certifies against it. Its practical role in a compliance programme is as the threat-model input that justifies a control set, which is why ATLAS references turn up inside ISO 42001 audit evidence packages and risk assessments rather than as an assessment standard of their own.

How does ATLAS relate to the OWASP LLM Top 10?

They overlap and answer different questions. The OWASP LLM Top 10 ranks the vulnerability classes an application team should design against, while ATLAS describes adversary behaviour in sequence across tactics from reconnaissance through impact. Teams generally use OWASP to scope engineering work and ATLAS to structure detection, red teaming, and incident reconstruction.

Which ATLAS techniques can a gateway actually evidence?

The ones that traverse HTTP AI traffic: prompt injection in direct and indirect forms, jailbreak attempts, model and endpoint probing over the inference API, data exfiltration through prompts and through agent tool invocation, and volume-based impact techniques. Training-time poisoning, ML supply chain compromise, and direct access to model artifacts leave no trace in request traffic and need build and host telemetry instead.

How long do we need to retain AI request logs for ATLAS-style investigation?

Longer than most teams set by default. The agent persistence techniques added in 2026 turn on finding a memory write that may sit weeks before the behaviour it caused, so a seven-day retention window will regularly fail to contain the originating event. Regulatory floors sit at six months in several regimes and the forensic requirement is what usually sets the real number.