What is MITRE ATLAS?
By Identra · Updated
MITRE ATLAS is a public knowledge base of adversary tactics and techniques against AI-enabled systems, modeled on MITRE ATT&CK. Security teams use it to describe realistic attacks on their AI deployments and to plan threat models and tests that show whether defenses hold.
What is in MITRE ATLAS?
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE maintains it, and it is laid out like ATT&CK. Tactics are what the attacker wants. Techniques are how they get it. Case studies tie techniques to attacks that were seen in the wild or shown in research.
It covers more than chatbots. Attacks on models, on the pipelines that feed them and on the applications built around them are all in scope. Read the matrix on the official ATLAS site instead of a copy in someone's slide deck. It gets updated.
The day-to-day value is shared language. An engineer says prompt injection and the risk lead hears 'the bot said something rude'. ATLAS gives both of them the same definition to point at.
How is MITRE ATLAS different from ATT&CK?
ATT&CK describes attacker behavior across enterprise IT, cloud and mobile. ATLAS adds the AI-specific part. Real attacks cross both.
Say an attacker phishes a SharePoint site owner, then edits a policy page that Microsoft 365 Copilot later pulls into answers for employees. The phish and the account abuse are ATT&CK territory. Copilot repeating the planted text is ATLAS. Put the whole path in one threat model, or the handoff between the two gets lost.
What does it cover?
- ATT&CK
- Attacker behavior across IT, cloud and mobile
- ATLAS
- Attacker behavior against AI-enabled systems
Where does it fit in the SharePoint example?
- ATT&CK
- The phished account and the page edit
- ATLAS
- Copilot surfacing the planted instructions
What do you get out of it?
- ATT&CK
- The access path and the logs that would show it
- ATLAS
- AI-specific scenarios to test along that path
How do you use ATLAS for AI threat modeling?
Start with one workflow you run today. A support assistant that reads Zendesk tickets and drafts replies is a good size. Write down who uses it, what it retrieves, which model it calls, what tools it holds and whose credentials those tools run under.
Then go to the matrix and pull techniques whose prerequisites match. A technique on the list is a candidate. It doesn't mean you're exposed.
For agents, record whose authority each tool call uses. A wrong answer is embarrassing. An agent exporting customer records with a support rep's token is an incident. AI agent identity is how you trace model behavior to what the agent can actually reach.
- The asset and the bad outcome. 'Customer records leave the support workflow' is specific enough.
- Every place an attacker can add content or swap a dependency.
- For each path, the access the attacker needs, what the AI would do and what breaks.
- An owner, a control and a test that proves the control works.
What does an ATLAS scenario look like?
Say a support assistant reads vendor PDFs and can send email. An attacker plants text in one PDF telling it to pull confidential account notes and mail them to an outside address. That's indirect prompt injection crossing over into tool use.
The questions that decide the outcome sit outside the model. Can the assistant read those notes at all? Can its email tool send outside the company domain? Does anything ask a person first?
Run it with synthetic records and a mailbox you control. Log whether the assistant followed the planted text, called the tool, got authorized and actually sent. A hostile reply on screen is not a breach.
How do you turn ATLAS findings into controls?
Put controls on the boundaries the scenario depends on. Least privilege limits which records the assistant can retrieve and which destinations its tools accept. Retrieved text is untrusted input. Authorization happens in the application, outside the model.
AI red teaming is where you find out whether any of it holds up against a motivated tester. ATLAS lists mitigations, but it isn't a mandatory control checklist. The list below is ordinary deployment practice.
- Enforce document permissions at retrieval and again when a tool acts.
- Require approval for external sends, with the exact recipient and data on screen.
- Log the request, the retrieved content, the tool call, the decision and the result together.
- Rerun the scenario after any model, tool or permission change.
What does an ATLAS mapping actually prove?
Less than people hope. A mapping says a scenario resembles known adversary behavior. Whether your control stops it is a separate question that only a test answers. Keep four records apart: techniques considered, scenarios tested, attacks observed and controls verified.
Open findings go to AI risk management with an owner and a decision attached.
How Identra thinks about it
Identra shows security teams which AI apps, accounts and agents are in use across the browser, the endpoint and connected identity, SaaS and cloud providers. Teams can govern AI access and sensitive data by policy, use recorded agent runs with their allowed or blocked outcome as evidence in threat model tests, and revoke risky OAuth grants that open the attack paths an ATLAS review turns up.
Go deeper: AI security, built on identity
Frequently asked questions
Is MITRE ATLAS only for large language models?
No. It covers attacks on AI systems broadly, including traditional machine learning models and the data pipelines behind them.
Is MITRE ATLAS a compliance certification?
No. It's a knowledge base. Mapping a system to ATLAS certifies nothing and doesn't show that defenses work.
Should every ATLAS technique be in our threat model?
Only the ones whose prerequisites fit your deployment. Write down why the rest are out of scope and look again when the architecture changes.
Can ATLAS help investigate an AI incident?
Yes. Analysts use it to name what they observed. Keep hypotheses separate from what the logs confirm.
How is an ATLAS technique different from a vulnerability?
A technique is attacker behavior. A vulnerability is a weakness in your system that might allow it. A matching technique doesn't mean your deployment is exploitable.