MITRE ATLAS and the OWASP Agentic AI Top 10 both address AI agent security, but they are not competing versions of the same list — they answer different questions for different audiences. OWASP's Top 10 tells a builder what to prioritize when designing an agent system. MITRE ATLAS tells a red team or threat-intelligence function how an adversary actually executes an attack against one, technique by technique. This post covers what each framework is actually for, how ATLAS has grown to cover agentic AI specifically, and when a team needs both rather than one.
OWASP's Agentic AI Top 10: what to design against
The OWASP Agentic AI Top 10 guide enumerates the ten highest-priority risk categories specific to agentic systems — the OWASP-style prioritized list format that has become the default way security teams communicate "these are the things most likely to hurt you first" to builders who do not have time to read a full threat-intelligence corpus. We cover the full ASI01–ASI10 list and what each category means for an engineering team in that guide directly, so this post does not re-list it here.
What matters for this comparison is the shape of the artifact: a top-10 list is a prioritization tool. It is designed to be short enough that a builder can hold it in their head while making design decisions — what permissions an agent gets, how tool calls are scoped, what output gets validated before it reaches a downstream system. Its value is in what it leaves out as much as what it includes: by forcing a ranked list of ten, OWASP is making a prioritization call on behalf of teams who do not have unlimited security budget.
MITRE ATLAS: how the attack actually happens
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a different kind of artifact entirely. It is a comprehensive matrix of adversary tactics and techniques against AI systems, modeled explicitly on the structure of MITRE ATT&CK — the framework most security teams already use for traditional threat modeling and red-team planning. Where ATT&CK organizes techniques by tactic (initial access, execution, persistence, exfiltration, and so on) for conventional IT systems, ATLAS applies the same structure to AI-specific and, increasingly, agent-specific attack paths.
This makes ATLAS the right reference when the question is not "what should we worry about" (OWASP's job) but "given that we are worried about X, what does a real attacker actually do to achieve it, and in what sequence." A red team planning an adversarial exercise against an agent deployment, or a threat-intelligence function trying to map a novel incident to known technique categories, reaches for ATLAS because it is built for exactly that granularity.
ATLAS has expanded specifically for agentic AI
ATLAS was not originally agent-specific — it grew out of adversarial ML research broadly — but recent versions have expanded significantly to cover agentic systems. MITRE ATLAS reached version 5.1.0 in late 2025, covering 16 tactics and 84 techniques. An October 2025 collaboration with Zenity Labs added 14 new agent-focused techniques specifically, covering:
- Context and memory poisoning — manipulating what an agent retains or retrieves across turns to influence later behavior.
- Agent configuration tampering — altering an agent's permissions, tool access, or instructions outside its intended change process.
- Credential harvesting — extracting credentials or tokens an agent holds or can reach through its tool access.
- Exfiltration via AI agent tool invocation — using an agent's own legitimate tool-calling capability as the exfiltration path, rather than a separate attacker-controlled channel.
ATLAS is reported in secondary coverage to have received a further update — described as version 5.4.0 — in February 2026 that added more agent-focused techniques; treat that specific version number and date as reported rather than independently confirmed, and check the current release directly on atlas.mitre.org before citing a specific version in your own documentation.
The direction of travel is clear regardless of the exact version numbering: ATLAS's maintainers are actively extending the framework to cover agent-specific attack surface, which makes it an increasingly relevant reference for teams doing agent threat modeling, not just traditional model-security work.
Side-by-side comparison
| OWASP Agentic AI Top 10 | MITRE ATLAS | |
|---|---|---|
| Format | Prioritized top-10 risk list | Full tactics/techniques matrix (16 tactics, 84 techniques as of v5.1.0) |
| Primary audience | Builders and product security teams | Red teams, threat-intel functions, security architects |
| Question it answers | "What should we design against first?" | "How does an adversary actually execute this, step by step?" |
| Structure modeled on | OWASP's established Top 10 format (LLM Top 10, Web App Top 10) | MITRE ATT&CK |
| Best used during | Design and architecture review | Red-team planning, incident technique mapping, detection engineering |
| Depth per item | Category-level, prioritized | Technique-level, exhaustive within scope |
When a team needs both
The two frameworks are complementary rather than substitutable, and most mature agent-security programs end up using both, at different points in the same workflow:
- Design phase — start with OWASP. When you are deciding what controls to build into a new agent system, the top-10 framing keeps the team focused on the highest-priority categories instead of getting lost in an 84-technique matrix before there is even a system to defend.
- Threat modeling and red-teaming — bring in ATLAS. Once a system exists and you are planning an adversarial test, ATLAS gives your red team concrete techniques to attempt within each risk category OWASP flagged, rather than leaving "test for excessive agency" as an underspecified instruction. Our red-teaming AI agents playbook and continuous adversarial testing for AI agents cover how to structure that testing program in practice.
- Incident response — map back to ATLAS technique IDs. When something goes wrong, mapping the observed behavior to a specific ATLAS technique gives your team a shared vocabulary for the postmortem and a way to check whether related techniques in the same tactic category are also exposed. For the specific agent failure modes ATLAS's recent agent-focused techniques cover, see AI agent memory poisoning defenses, threat model: agent credential theft, and threat model: indirect prompt injection.
- Detection engineering — build against ATLAS technique categories. Security teams building detection rules for agent behavior get more mileage from ATLAS's granularity than from OWASP's category-level framing, because detections need to target specific behavioral patterns, not broad risk categories.
Neither framework replaces the OWASP LLM Top 10 either — that earlier, narrower list focuses on risks in the underlying LLM layer rather than agentic behavior specifically; see the OWASP LLM Top 10 for agents for how that relates to the agentic list. And neither framework is a controls checklist the way the CSA AI Controls Matrix is — both ATLAS and the OWASP list describe risk and attacker behavior, not the specific controls you implement in response.
Praesidia is an AI agent security and governance control plane — agent identity and access, guardrails, audit evidence, and cost controls in one place — and the guardrails and monitoring it provides are the kind of control layer a team builds in response to the risk categories both frameworks describe, not a substitute for doing the threat-modeling work itself.
Common questions
Do we need to adopt both frameworks formally, or is one enough? It depends on your team's stage and function. A product team building its first agent gets more immediate value from the OWASP list, because it is short enough to inform design decisions directly. A security team standing up red-teaming or detection engineering for agents will need ATLAS's granularity regardless of whether the product team also uses OWASP. Most organizations end up using both, owned by different functions.
Is MITRE ATLAS specific to agentic AI, or does it cover AI security generally? ATLAS covers adversarial machine learning and AI security broadly — it predates the current wave of agentic AI. Recent versions, including the techniques added through the Zenity Labs collaboration in late 2025, have specifically extended it to cover agent-specific attack paths like memory poisoning and tool-invocation exfiltration, but the framework's scope is not limited to agents.
How does ATLAS relate to MITRE ATT&CK? ATLAS is explicitly modeled on ATT&CK's structure — tactics organizing techniques into the phases of an attack — extended to cover AI and agent-specific adversary behavior. If your team already uses ATT&CK for traditional threat modeling, ATLAS should feel structurally familiar rather than requiring you to learn an entirely new framework shape.
Where does the OWASP Agentic AI Top 10 come from, and how does it differ from the older LLM Top 10? The Agentic AI Top 10 is a newer, purpose-built list focused on risks specific to autonomous, tool-using agent systems — permission scope, delegation, tool invocation — distinct from the earlier OWASP LLM Top 10, which focuses on risks in the underlying language-model layer (prompt injection into the model itself, training-data risks, and similar). See the full ASI01–ASI10 breakdown in the pillar guide for the complete list.
How often should we re-check which techniques ATLAS covers for agents? Given how actively the agent-focused portion of ATLAS has been updated — a major agent-specific expansion in October 2025 and further updates reported since — treat it as a living reference to re-check at least twice a year, or whenever you are planning a red-team exercise against a newly agentic system, rather than a document you consult once and consider complete.