MITRE ATLAS: A Technical Guide for Enterprise AI Threat Coverage

How the MITRE ATLAS matrix is organized

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) catalogs adversary behavior against AI-enabled systems. Like ATT&CK, it separates tactics (what the adversary is trying to achieve) from techniques (how those goals are pursued). The matrix presents tactics as columns spanning the AI and ML lifecycle and operations. Techniques and subtechniques sit in the cells and link to mitigations and publicly mapped case studies.

Tactics commonly referenced across ATLAS include reconnaissance, resource development, initial access, ML model access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, collection, AI attack staging, exfiltration, and impact. AI-specific techniques documented in the matrix include data poisoning, model poisoning, prompt injection (including indirect prompt injection), model evasion, membership inference, model inversion, model theft, and extraction of sensitive data through model outputs.

Mitigations in ATLAS are reference controls mapped to techniques. Examples include sanitizing training data, input validation and sanitization, output filtering, access control, audit logging, adversarial ML training, ensemble methods, and restrictions on library loading. Practitioners should treat these as design inputs for control selection, not as a compliance checklist with guaranteed effectiveness metrics. Because ATLAS is versioned and updated as new techniques and case studies appear, enterprises should cite the ATLAS version used in architecture reviews, baselines, and assessments.

Where ATLAS extends beyond ATT&CK for agentic systems

ATT&CK remains the primary catalog for enterprise IT and OT adversary behavior on hosts, identities, and networks. ATLAS extends threat-informed defense into areas ATT&CK does not fully cover: ML supply chains, training and inference pipelines, model repositories, prompts, retrieval content, and AI agent tool use.

Enterprise AI agents that call tools, use retrieval-augmented generation, retain memory, or participate in multi-agent orchestration expand the attack surface along paths that map cleanly to ATLAS. Indirect prompt injection via untrusted documents or tool responses can drive execution through tool misuse. Collection and exfiltration can occur through crafted prompts or unsafe model outputs. Impact can reach connected systems when agents hold excessive agency over APIs, data stores, or privileged actions. Host and network ATT&CK mappings alone often miss these ML- and prompt-centric procedures.

OWASP guidance on LLM applications highlights related risks such as prompt injection, insecure output handling, sensitive information disclosure, and excessive agency. Security teams commonly cross-map those risks to ATLAS techniques when assessing agents. Public crosswalks can differ slightly; enterprises should document their own mapping rationale and keep it version-pinned alongside ATLAS.

Training-time and supply-chain techniques (poisoning, compromised models or plugins) differ operationally from runtime threats such as evasion, prompt injection, inference abuse, and model extraction. Control design should reflect that split: provenance and approval workflows for models and tools on one side; input/output policy, authorization on tool actions, and inference-time telemetry on the other.

Architecture patterns that align to ATLAS-relevant techniques

Effective coverage starts with trust boundaries and enforcement points that match how agents actually act, not only how models generate text.

Using ATLAS to prioritize runtime policy and agent permissions

Map each production agent’s concrete capabilities before selecting controls. Inventory tools, data stores, identities, outbound network paths, and whether the agent can initiate external actions. From that inventory, derive a shortlist of relevant ATLAS techniques. Whole-matrix compliance exercises create noise; capability-specific mapping produces an actionable control backlog.

Prioritize runtime enforcement for high-agency behaviors. Restrict tool scopes to the minimum required operations. Constrain parameters to allowed resources and schemas. Require step-up or human approval for sensitive actions. Enforce rate and quota limits. Block unrestricted code execution, broad filesystem access, and similarly dangerous tools by default. Pair these controls with input validation and structured output handling, including filters aimed at sensitive disclosure and unsafe downstream execution, where prompt injection and output abuse techniques apply.

Instrument immutable audit logs that capture prompts, retrieval metadata, tool calls and parameters, policy allow or deny decisions, model identity and version, and the acting principal. Traditional endpoint and network logs are usually insufficient for ATLAS-aligned investigation. Red-team staging agents with scenarios drawn from ATLAS case studies and OWASP LLM risks, then feed failures into control design and detection engineering.

Governance should give ATLAS a shared language across SecOps, MLOps, and platform teams. Pair technique mappings with organizational risk functions such as those in the NIST AI RMF (govern, map, measure, manage). Define acceptable-use and permission policies for agent identities as distinct from human users, including access reviews on tool scopes and break-glass procedures. Require version-pinned ATLAS mappings in architecture review for any agent that can take external actions or touch sensitive data, and retain audit evidence adequate for incident response involving automated actions.

Practical prioritization sequence

1. Inventory agent tools, data stores, identities, and outbound paths.
2. Shortlist ATLAS techniques that match those concrete capabilities.
3. Enforce least privilege, parameter constraints, approvals, and rate limits at runtime.
4. Validate inputs and structure outputs where injection and disclosure techniques apply.
5. Log prompts, tool calls, policy decisions, model version, and acting principal immutably.
6. Red-team with ATLAS-aligned and OWASP LLM scenarios; track failures to control owners.
7. Pin ATLAS version in architecture review and align mappings to NIST AI RMF functions.

Evaluation criteria for ATLAS-aligned runtime security

• Explicit technique mapping Which ATLAS tactics and techniques are mapped for agents (for example prompt injection, tool misuse, exfiltration via outputs), and how is the mapping maintained as ATLAS evolves?
• Runtime enforcement primitives Least-privilege tool access, parameter constraints, human-in-the-loop gates, rate limits, and denial of high-impact actions at a policy enforcement point.
• Untrusted content handling Controls that treat retrieved content and third-party tool responses as untrusted to reduce indirect prompt injection and chained tool abuse.
• Telemetry and operations fit Emission of prompts, tool calls, policy decisions, and model or version identity in forms that integrate with existing SIEM and SOAR workflows.
• Evidence from adversarial testing Red-team or evaluation results against ATLAS-aligned scenarios for your agent architectures, with failures tracked to control owners.
• Governance and identity model Distinct agent identities, permission reviews, audit retention for automated actions, and version-pinned ATLAS references in design reviews.