Using MITRE ATLAS to Make AISecOps Threat-Informed

MITRE ATLAS is the threat-informed part of my AISecOps framework set.

NIST AI RMF explains how to govern risk. The two OWASP lists describe important classes of LLM and agentic application risk. ATLAS describes how adversaries pursue objectives across an AI-enabled system.

That makes it useful for threat modeling, detection engineering, adversarial testing, threat intelligence, and incident response. It gives those teams a common vocabulary for an attack path instead of a collection of product-specific alerts.

What ATLAS is

ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE models it after ATT&CK, using tactics, techniques, subtechniques, mitigations, and case studies to describe attacks against AI systems.

The live matrix changes as the field develops. At the time of writing, it contains 16 tactics, 173 techniques, 35 mitigations, and 63 case studies. It can be filtered across predictive AI, generative AI, agentic AI, and enterprise platforms, and it distinguishes between feasible, demonstrated, and realized techniques.

That maturity field is valuable. A lab result and a technique observed in a real incident should both inform a program, but they should not automatically receive the same priority.

ATLAS also connects to ATT&CK where a technique is inherited from ordinary enterprise intrusion behavior. An attacker may begin with a familiar path such as valid accounts or supply chain compromise, then move into AI-specific behavior such as prompt injection, RAG poisoning, model access, agent tool poisoning, or context manipulation.

OWASP names the risk. ATLAS models the path.

Consider a malicious tool.

The OWASP Agentic Top 10 classifies it as an agentic supply chain vulnerability and possibly tool misuse. That is useful for requirements and architecture.

ATLAS can describe a longer sequence: the adversary develops or publishes a poisoned tool, gains a path into the agent’s runtime, influences tool selection or output, invokes another capability, collects information, and exfiltrates it. Each stage suggests a different prevention, detection, or response opportunity.

This difference makes the frameworks complementary:

• OWASP is good for application requirements and review checklists.
• ATLAS is good for attack narratives, telemetry planning, detections, exercises, and coverage analysis.
• NIST AI RMF is good for ownership, measurement, treatment, and lifecycle decisions.

Start with the system, not the whole matrix

Trying to cover every ATLAS technique is not a useful first goal. Begin with one agent and its real attack surface.

Document:

• public and internal entry points;
• users and non-human identities;
• prompts, retrieval, memory, and data pipelines;
• models and inference services;
• tools, MCP servers, plugins, and peer agents;
• code execution and serving infrastructure;
• logs, traces, approvals, and response controls;
• sensitive outcomes an adversary would want.

Then select ATLAS techniques that match those surfaces and outcomes. A read-only internal summarizer has a different technique set from an internet-facing agent with memory, code execution, and financial tools.

This risk-based selection produces a defensible threat model without pretending that matrix coverage is a score.

Build detections from attack hypotheses

An ATLAS mapping becomes operational when it produces a detection hypothesis.

For each selected technique, write:

1. What would the adversary need to do?
2. Which component would observe it?
3. What event, field, or correlation would distinguish it from normal behavior?
4. How quickly should the program detect it?
5. What should happen after detection?

For agent tool poisoning, telemetry might include catalog changes, definition hashes, publisher identity, version changes, requested scopes, first use after update, unusual tool selection, parameter anomalies, and new outbound destinations.

For context poisoning, the program might record memory writes, source provenance, retrieval frequency, integrity status, cross-session reuse, and behavior changes after retrieval.

For LLM prompt injection, useful evidence can include the untrusted source, isolation boundary, classifier result, tool request that followed, authorization decision, and whether the action matched the original user goal.

The technique ID should appear in the detection record and runbook. That makes it possible to ask which techniques have telemetry, which have logic, which have been exercised, and which remain blind spots.

Use case studies for adversarial testing

ATLAS case studies keep a red-team plan tied to observed or realistically demonstrated behavior.

A useful exercise does not simply paste jailbreak strings into a chat box. It emulates an attack chain against the deployed architecture:

• seed hostile content into a source the agent is expected to trust;
• alter a tool or its metadata;
• attempt to move from one agent identity to another;
• poison context and wait for later retrieval;
• manipulate an output that downstream code will process;
• force repeated calls or recursive delegation;
• test whether containment stops the sequence.

The goal is not only to make the model fail. It is to learn whether the surrounding controls prevent that failure from becoming an incident and whether the monitoring tells the story afterward.

Exercise results should update architecture, detections, playbooks, and risk decisions. Red teaming that produces a report but no control change is unfinished work.

How it fits the eight AISecOps domains

AISecOps domain	ATLAS use
Governance and inventory	Links system records and risk tiers to applicable tactics, techniques, and case studies
Secure development and deployment	Converts likely techniques into security requirements and test cases before release
Identity and access	Models credential access, valid accounts, privilege escalation, delegation, and lateral movement
Data protection	Models collection, model or data access, context theft, and exfiltration paths
Threat detection and monitoring	Provides the main vocabulary for telemetry requirements, detection content, and coverage reporting
MCP and tool governance	Covers poisoned tools, malicious runtime components, unsafe invocation, and supply chain paths
Incident response and adversarial testing	Structures scenarios, runbooks, investigation timelines, containment, and post-incident lessons
Vulnerability and supply chain management	Connects vulnerable or poisoned components to adversary use and prioritization

ATLAS will naturally receive the most use in domains five and seven, but the earlier domains create the controls and evidence those operational teams depend on.

Make a coverage matrix that means something

A simple program matrix can track:

• selected ATLAS technique;
• affected workloads or risk tiers;
• preventive control;
• required telemetry;
• detection status;
• runbook status;
• last exercise date and result;
• known gap and owner.

Avoid one percentage for “ATLAS coverage.” A technique may have a preventive control but no detection. A detection may exist without the telemetry needed in every environment. A runbook may never have been exercised. Those states should remain visible.

Coverage should also follow the live matrix. New agentic techniques, mitigations, and case studies need a regular review path into threat models and detection priorities.

A practical operating loop

I would use ATLAS in a recurring loop:

1. Select workloads by risk tier and business impact.
2. Map their real components and trust boundaries.
3. Choose relevant ATLAS techniques and case studies.
4. Write attack hypotheses and telemetry requirements.
5. Build detections and investigation guidance.
6. Emulate the highest-priority paths.
7. Fix architecture and response gaps.
8. Record results through NIST AI RMF’s Measure and Manage cycle.
9. Revisit the selection when the workload or ATLAS changes.

The OWASP LLM Top 10 and OWASP Agentic Top 10 help decide which weaknesses deserve controls. ATLAS helps a security team think through how an adversary could combine those weaknesses into an operation.

That is what makes it valuable to AISecOps. A program should not only know which controls it has. It should know which attacker behaviors those controls are meant to stop, which behaviors it can see, and what the team will do when prevention fails.