We've Seen This Movie Before
Most detection engineers remember the first time they saw an ATT&CK Navigator heatmap in an executive presentation. Lots of green, a coverage percentage in a big font, and a room full of people nodding. What the slide didn't show was how many of those green cells were backed by rules that had never been tested, depended on data nobody was collecting, or were mapped to a technique because it was the closest match available.
I used to work for a SIEM vendor that claimed out of the box coverage for every single ATT&CK technique. The problem was that a technique was considered “covered” if there was a single rule that aligned with the technique. As an example, there was a rule that looked for Mimikatz activity on windows devices and aligned with the OS Credential Dumping technique (T1003). The problem with this was that it covered exactly one variation of credential dumping on one very specific technology. It didn’t take into account that credential dumping could happen elsewhere or that any given organization might not even use windows devices at all. It was a “one size fits all” approach to security which was fundamentally flawed.
AI adoption is creating a new attack surface, and MITRE has a framework for it: ATLAS. It's genuinely useful for detection teams. It's also about to end up on a lot of executive slides. This post covers what ATLAS is, how to use it alongside ATT&CK, and why it should be the foundation of your AI detection strategy rather than a new number to report.
What ATLAS Is
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It's a knowledge base of adversary tactics and techniques targeting AI, built on real-world attacks and demonstrations from AI red teams. If you've worked with ATT&CK, the structure will feel familiar. Tactics describe the adversary's goal, techniques describe how they get there, and each technique has an ID, in this case prefixed with AML.
Many of the tactics carry over directly from ATT&CK, like Reconnaissance, Initial Access, and Exfiltration. Others are specific to AI, like AI Model Access and AI Attack Staging, which cover how an adversary gains access to a model and prepares an attack against it.
The framework is also moving fast. The November 2025 release contained 84 techniques. As of the September 2026 release, it contains 120 techniques across 16 tactics. A lot of that growth covers agentic AI: attacks against the tools agents call and the registries they pull those tools from.
Detecting Attacks on AI Systems
Here's where things get practical, and where most teams hit their first wall. ATLAS techniques often happen in places your SIEM has never looked.
Take LLM Prompt Injection (AML.T0051). If your company runs an internal chatbot or an AI assistant connected to company data, a prompt injection attack against it doesn't touch an endpoint or a firewall. It lives in the prompts and responses flowing through the application. If those aren't logged somewhere you can search, there's nothing to detect against.
The same goes for a newer technique like Publish Poisoned AI Agent Tool (AML.T0104), where an adversary publishes a malicious tool or skill for agents to install. Detecting the downstream effects means knowing which tools your agents have installed, when, and what they did once invoked.
So the first step with ATLAS usually isn't writing rules. It's asking for telemetry:
- Prompt and response logs from AI applications
- Agent tool installation and invocation logs
- Access and audit logs for model endpoints, registries, and training data stores
- API gateway logs for inference traffic
[Personal anecdote: your experience getting a new, unfamiliar log source onboarded, or a client conversation where the AI team and the security team realized nobody owned AI logging]
Mapping ATLAS Alongside ATT&CK
ATLAS doesn't replace ATT&CK. The two are complementary, and real attacks against AI systems usually involve both.
An adversary might use Valid Accounts (T1078) to get into a cloud environment, access a model registry, and exfiltrate model artifacts. The middle of that chain is ATLAS territory. The beginning and end are classic ATT&CK, and you probably already have detections for them.
A few practical guidelines for mapping:
- Map to both when both apply. A detection for unusual access to a model registry through a cloud API might reasonably map to an ATT&CK technique and an ATLAS technique. That's fine, and it gives a truer picture than forcing a single answer.
- Don't force a mapping. If a rule doesn't cleanly fit an ATLAS technique, leave it unmapped. A loose mapping inflates coverage and misleads whoever reads it next.
- Start with what you run. An organization using a third-party AI assistant has a very different threat model than one training and hosting its own models. Filter ATLAS to the techniques that apply to your actual AI assets before you start counting anything.
The Scorecard Trap
This is the part that matters most. ATLAS makes a terrible scorecard.
A large share of ATLAS techniques happen somewhere you'll never have visibility. Resource Development techniques happen on the adversary's infrastructure. Poisoning of public training data happens long before the data reaches you. Some techniques are addressed by mitigations like input filtering or model hardening rather than detection at all. None of those are gaps in your detection program. They're just outside what detection can do.
Put a coverage percentage against all 120 techniques on a slide and one of two things happens. Either the number looks alarmingly low and leadership asks why, or someone finds creative ways to make it go up. Neither outcome makes anyone more secure.
What ATLAS does well is give you a structured way to answer the questions that actually drive an AI detection program:
- What AI systems do we run, and which techniques apply to them?
- Which of those techniques can detection realistically address, and which belong to other controls?
- What telemetry do we need to detect the ones in scope?
- Which of our existing ATT&CK detections already cover the edges of these attack chains?
Those answers become the foundation. Rules come after, and coverage numbers, if you report them at all, should be scoped to the techniques you've decided are in scope for detection.
Because the framework is growing so quickly, that foundation also needs regular maintenance. New techniques will apply to your environment, existing ones will get refined, and your mappings should be revisited as the framework changes.
Piecing It All Together
ATT&CK heatmaps taught the industry a lesson: a framework built to share knowledge turns into a vanity metric the moment it becomes a scorecard. ATLAS gives detection teams a head start on a new and fast-moving attack surface. The teams that get the most out of it will be the ones who use it to decide what to build and what telemetry to ask for, not the ones with the greenest slide.
At Rilevera, we see framework mapping as the starting point of the conversation about coverage alignment, not the end of it. Whether you're working in ATT&CK, ATLAS, or both, the goal is the same: knowing what you can actually detect.
Sources
