MITRE ATLAS

Artificial intelligence systems do not fail only because a model makes a bad prediction. They can also fail because someone deliberately shaped the data, probed the model, stole its behavior, bypassed its safeguards, or used it as a path into the wider organization. MITRE ATLAS gives defenders a shared language for these attacks. It does not sell a product or promise complete protection. It helps teams ask better questions, describe what they see, and connect artificial intelligence risk to the security work they already know how to do.

Start with the system, not the model

An artificial intelligence system is more than an algorithm. It includes training data, code, features, prompts, application programming interfaces, deployment pipelines, monitoring, people, and business processes. The model is important, but it is only one part of the machine.

That matters because attackers usually look for the cheapest path to their goal. If changing a training file is easier than breaking cryptography, they may change the file. If stealing outputs from a public endpoint is easier than stealing the model itself, they may do that. If a prompt can make a chatbot ignore its instructions, the attack may look more like social engineering than classic exploitation.

MITRE ATLAS exists because these paths are real enough, common enough, and different enough from traditional software attacks that defenders need a specific map for them.

What MITRE ATLAS is

MITRE ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It is a knowledge base of adversary tactics and techniques against artificial intelligence systems. A tactic is the attacker’s immediate objective, such as gaining access or evading detection. A technique is a way to achieve that objective, such as poisoning training data or extracting model behavior through repeated queries.

MITRE, a not-for-profit organization that operates federally funded research and development centers in the United States, is also known for MITRE ATT&CK, which stands for Adversarial Tactics, Techniques, and Common Knowledge. ATT&CK describes how attackers operate in enterprise, cloud, mobile, and industrial environments. ATLAS plays a similar role for artificial intelligence, while recognizing that artificial intelligence has its own attack surfaces and failure modes.

The value of ATLAS is not that every entry is new. Some attacks against artificial intelligence use familiar steps: reconnaissance, credential theft, supply chain compromise, and data exfiltration. The value is that ATLAS shows where those steps intersect with model training, model serving, data pipelines, and the behavior of learned systems.

How ATLAS is organized

ATLAS is organized around the way an adversary moves from intent to action. At the highest level are tactics, which describe what the adversary is trying to accomplish. Under tactics are techniques and sub-techniques, which describe how the adversary might do it. Many entries include examples, references, mitigations, and detection ideas.

This structure gives teams a common vocabulary. A data scientist, security engineer, product owner, and executive may each describe the same concern differently. ATLAS lets them say, for example, that a proposed system is exposed to data poisoning during training or prompt injection during use. That shared phrase makes it easier to assign ownership and decide what evidence would prove the risk is being managed.

ATLAS is also empirical in spirit. It includes techniques observed in research, public incidents, demonstrations, and plausible adversary behavior. That does not mean every technique is equally likely in every environment. A fraud model, a medical imaging system, a recommender, and a general-purpose chatbot face different pressures.

An AI attack path in plain terms

Consider a company that deploys a customer support assistant. The assistant uses a large language model, internal documents, user prompts, and tools that can open tickets or look up account data. A traditional security review might focus on authentication, authorization, logging, and network exposure. Those remain essential. ATLAS adds questions about how the model and its surrounding context can be manipulated.

An attacker might first study the system by sending harmless-looking prompts and observing the answers. They might then craft input that attempts to override the assistant’s instructions. If the assistant can call tools, the attacker may try to make it call the wrong tool or expose data it should not reveal. If the organization later uses conversations to improve the system, the attacker may try to seed misleading examples into that feedback loop.

The point is not that every assistant will fall to this exact path. The point is that artificial intelligence systems often create paths where inputs are both data and instructions. ATLAS gives names to those paths so teams can design controls before the system is under pressure.

Using ATLAS for threat modeling

Threat modeling is the practice of asking what can go wrong, who might cause it, how they might do it, and what should be done about it. ATLAS is useful because it supplies a tested vocabulary for the how. It helps a team move from a vague statement such as “the model could be attacked” to a sharper statement such as “an attacker could poison fine-tuning data to make the model mishandle a class of requests.”

A practical session starts with the system boundary. What data enters the system? Who can influence it? What decisions or actions does the model support? What tools can it call? What outputs matter? The team then walks through relevant ATLAS tactics and techniques, selecting only those that make sense for the design.

The output should not be a long list of fears. It should be a small set of testable risks, each tied to an owner, a control, and a signal. A control might be data provenance checking, human approval for high-impact actions, rate limiting, red-team testing, or model monitoring. A signal might be unusual query patterns, sudden accuracy shifts, suspicious training examples, or policy-violating outputs.

The decisions leaders and practitioners face

ATLAS becomes most useful when it informs decisions, not when it sits in a policy document. Leaders must decide which artificial intelligence systems are important enough to receive deeper review, how much risk is acceptable, and who owns the controls. Practitioners must decide where to place tests, what to log, how to protect data pipelines, and when to require a human in the loop.

A small internal classifier that ranks low-risk documents may need lightweight controls. A model that approves loans, guides clinical work, trades financial instruments, or uses tools to change customer accounts needs stronger evidence. ATLAS helps make that difference explicit because it ties risk to specific attacker behavior.

The hard part is prioritization. Teams can exhaust themselves trying to defend against every published technique. A better approach is to rank techniques by exposure, impact, and feasibility. Exposure asks whether an attacker can reach the relevant surface. Impact asks what harm follows if the attack succeeds. Feasibility asks how much skill, access, time, and money the attacker likely needs.

• Inventory artificial intelligence systems that affect money, safety, rights, privacy, or critical operations.
• Identify who can influence training data, prompts, model inputs, tools, and feedback loops.
• Prioritize ATLAS techniques that match real exposure rather than treating the whole catalog as equally urgent.
• Require stronger testing and approval for systems that can take actions, not only produce text or scores.
• Assign clear owners for data integrity, model behavior, application security, and incident response.

What ATLAS does not solve

ATLAS is not a maturity model. It does not by itself tell an organization how good its artificial intelligence security program is. It is not a compliance standard. It does not certify that a model is safe. It is also not a substitute for secure software development, access control, privacy engineering, model evaluation, or incident response.

ATLAS can make a weak program look more disciplined if teams simply copy technique names into a spreadsheet. The useful work is in connecting those names to the system: which component is exposed, what control exists, how the control was tested, what telemetry would show an attack, and who would respond.

Another limit is that artificial intelligence changes quickly. New model architectures, deployment patterns, and agentic systems can create new combinations of risk. ATLAS is valuable because it provides a stable way to think, but defenders should expect the catalog to evolve.

A simple way to begin

Start with one system that matters. Draw its data flows from collection to training, evaluation, deployment, user interaction, logging, and feedback. Mark where outsiders, customers, vendors, employees, or automated processes can influence the system. Then review the ATLAS techniques that touch those areas.

For each relevant technique, write one sentence in the form: “An adversary could do X at Y to cause Z.” For example: “An adversary could submit crafted support messages into the feedback dataset to cause the assistant to learn an unsafe response pattern.” This form forces clarity about action, location, and consequence.

Then choose a small number of controls and tests. Do not try to solve everything in the first pass. The goal is to establish a repeatable habit: understand the system, name the plausible attacks, reduce the highest risks, and watch for evidence that assumptions have changed.

1. Pick one deployed or soon-to-be-deployed artificial intelligence system.
2. Draw its data, model, prompt, tool, and feedback paths.
3. Use ATLAS to name the plausible adversary techniques.
4. Rank the risks by exposure, impact, and feasibility.
5. Add controls, tests, logs, and response steps for the highest risks.
6. Repeat when the system, data, model, or business use changes.

Glossary

Artificial intelligence

Artificial intelligence is software that performs tasks normally associated with human judgment, such as classification, prediction, generation, or decision support.

MITRE ATLAS

MITRE ATLAS is the Adversarial Threat Landscape for Artificial-Intelligence Systems, a knowledge base of attacks and defenses for artificial intelligence systems.

MITRE ATT&CK

MITRE ATT&CK is the Adversarial Tactics, Techniques, and Common Knowledge framework for describing how adversaries operate in digital environments.

Tactic

A tactic is the immediate objective an adversary is trying to achieve, such as gaining access, evading detection, or extracting information.

Technique

A technique is a specific method an adversary can use to achieve a tactic.

Data poisoning

Data poisoning is an attack in which an adversary corrupts training or feedback data to change a model’s future behavior.

Prompt injection

Prompt injection is an attack that uses crafted input to make a language model ignore, override, or misuse its intended instructions.

Threat modeling

Threat modeling is a structured way to identify what can go wrong, how it could happen, and what controls should reduce the risk.

Model monitoring

Model monitoring is the practice of watching a deployed model for changes in behavior, performance, inputs, or outputs that may indicate problems or attacks.