AI Security Frameworks Compared: NIST, OWASP, ATLAS

Search for AI security frameworks and you get four names back — NIST AI RMF, the OWASP Top 10 for LLM Applications, MITRE ATLAS, and ISO/IEC 42001 — usually presented as if a team has to pick one. They are not alternatives. Each answers a different question, and a program that adopts only one of them has a predictable, specific gap. This piece maps what each document actually contains, what it deliberately leaves out, and how the four compose into a single stack.

The layer model

The fastest way to stop treating these as competitors is to notice which question each one answers.

• NIST AI RMF answers how do we organize ourselves to manage AI risk? It is a process framework.
• ISO/IEC 42001 answers how do we prove that organization to an auditor? It is a certifiable management system standard.
• MITRE ATLAS answers what will an adversary actually do to this system? It is a threat-intelligence catalog.
• OWASP Top 10 for LLM Applications answers what goes wrong in the application we are shipping? It is an application risk list.
• The EU AI Act answers what are we legally required to do? It is law, not guidance.

Governance frameworks tell you to identify threats. They do not tell you what the threats are. Threat catalogs tell you what attackers do. They do not tell you who signs off on the residual risk. Skipping either half produces the two failure modes that show up most often in AI security programs: a thorough governance binder with no idea what an actual attack looks like, or a red team with excellent findings that nobody is accountable for closing.

NIST AI RMF: the process spine

The AI Risk Management Framework (AI RMF 1.0) is voluntary, sector-agnostic, and organized around four core functions:

• GOVERN — the cross-cutting function: policies, accountability, culture, and the structures that make the other three repeatable rather than heroic.
• MAP — establish context. What is the system for, who does it affect, what are the interdependencies, what does “risk” mean for this deployment.
• MEASURE — analyze and track the identified risks with quantitative and qualitative methods, including the ones that are hard to measure.
• MANAGE — allocate resources, respond, recover, and communicate.

The framework’s most useful property is also the one that frustrates people expecting a checklist: it prescribes almost no controls. It tells you to characterize trustworthiness across dimensions like validity, reliability, safety, security and resilience, accountability and transparency, explainability, privacy, and fairness — then leaves the technique selection to you.

The gap that leaves is partly filled by the Generative AI Profile (NIST AI 600-1), a companion document that enumerates risks specific to generative systems — including confabulation, information integrity, information security, data privacy, harmful bias, human-AI configuration, and value chain and component integration — and maps suggested actions back onto the four core functions. If a team has read the AI RMF and concluded it is too abstract to act on, the Generative AI Profile is the document they were actually looking for.

What it does not give you: an adversary model, a certificate, or a way to tell a customer you comply.

MITRE ATLAS: the adversary catalog

ATLAS is structured as a matrix in the same shape as ATT&CK, with tactic columns running from reconnaissance and resource development through initial access, ML model access, execution, persistence, defense evasion, discovery, collection, ML attack staging, and exfiltration to impact. Under each column sit techniques with AI-specific mechanics: model evasion, training-data poisoning, model extraction, prompt injection, and supply-chain compromise of models and their dependencies. ATLAS also publishes case studies drawn from real incidents and published research, which is what makes it usable in threat modeling rather than only in slide decks.

Its value is that it is descriptive and specific. It will tell you that an attacker who cannot reach your weights can still recover a functional copy through query access, and it will name the technique so two teams can talk about the same thing. The mechanics behind several of those techniques are covered in more depth in adversarial examples in machine learning explained and what a prompt injection attack is.

What it does not give you: mitigations at the level of engineering detail, prioritization for your context, or any governance structure. ATLAS is a map of the terrain, not a plan.

OWASP Top 10 for LLM Applications: the shipping checklist

The 2025 edition is the shortest document of the four and the one most likely to survive contact with a sprint planning meeting. It names ten application-level risk categories — prompt injection at the top, then sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. A category-by-category walkthrough of what each one means in practice is in the OWASP Top 10 for LLM applications explained.

Its scope is narrow on purpose: it covers the application you are building, not the organization building it and not the model provider’s training pipeline. That narrowness is why it is the right first document for an engineering team and the wrong one for a risk committee.

What it does not give you: governance, audit evidence, or coverage of risks that live outside the application boundary.

ISO/IEC 42001: the certifiable one

ISO/IEC 42001:2023 specifies an AI management system — the AI equivalent of what ISO/IEC 27001 does for information security. It follows the same harmonized structure (context, leadership, planning, support, operation, performance evaluation, improvement) and carries an Annex A control set covering areas such as AI policy, roles and responsibilities, resources for AI systems, impact assessment, the AI system lifecycle, data management, information for interested parties, and third-party and customer relationships.

The distinguishing feature is that an accredited body can certify against it. That matters commercially long before it matters technically: it is the artifact that answers a procurement questionnaire. Its structural overlap with NIST AI RMF is high enough that organizations frequently run AI RMF as the internal working model and use ISO/IEC 42001 as the external attestation.

What it does not give you: technical depth. A conformant management system says nothing about whether your retrieval pipeline is injectable.

The EU AI Act: the obligation floor

Regulation (EU) 2024/1689 is binding law, not a framework, and it sorts systems into risk tiers: prohibited practices, high-risk systems carrying the bulk of the compliance obligations, limited-risk systems subject to transparency duties, and everything else. It layers a separate obligation set onto general-purpose AI models, including technical documentation and, above a compute threshold, systemic-risk duties. Article 15 requires high-risk systems to achieve appropriate levels of accuracy, robustness, and cybersecurity, and explicitly calls out resilience against attempts to alter use or behavior by exploiting system vulnerabilities — the clause that turns adversarial robustness from a research topic into a regulatory requirement.

The Act’s phased application timeline, as adopted, staggers the obligations across several years rather than switching them on at once. That timeline has itself been subject to amendment proposals, which is why the compliance date a vendor quotes should always be checked against the current consolidated text rather than a 2024 explainer. Coverage of that legislative movement runs through the May 13 AI security week digest.

What it does not give you: applicability outside its jurisdictional scope, or implementation detail. Harmonized standards fill that in, and they are still maturing.

Side by side

Composing them on one control

The stack is easiest to see traced through a single risk. Take indirect prompt injection against a retrieval-augmented assistant.

1. OWASP names it: LLM01 Prompt Injection, with LLM05 Improper Output Handling and LLM06 Excessive Agency as the categories that determine blast radius.
2. ATLAS supplies the adversary framing and a shared identifier: LLM Prompt Injection is AML.T0051, split into Direct (AML.T0051.000) and Indirect (AML.T0051.001), so the retrieval-corpus variant has a name two teams can agree on — plus what precedes it in the chain and what the attacker reaches for once the model is following injected instructions.
3. NIST AI RMF places it: MAP identifies the retrieval corpus as untrusted input, MEASURE defines how injection success rate is evaluated, MANAGE decides whether the residual risk is accepted and who accepted it.
4. ISO/IEC 42001 produces the evidence: the documented lifecycle process, the impact assessment, and the record that the decision in step 3 was made by an accountable owner.
5. EU AI Act sets the floor: if the assistant is a high-risk system, Article 15 robustness and cybersecurity requirements make the mitigation mandatory rather than discretionary.

No single document supports all five steps. Any one of them alone leaves a step unowned.

Where to start

• Shipping an LLM feature this quarter. Start with OWASP. It maps directly onto engineering work and requires no program to exist first.
• Building a threat model or scoping a red team. Start with ATLAS, then use OWASP to prioritize by what your architecture actually exposes.
• Asked by leadership to “have an AI risk program.” Start with NIST AI RMF plus the Generative AI Profile. Adopt ISO/IEC 42001 when a customer or a deal requires the certificate, not before.
• Placing a system on the EU market. Start with the Act’s risk classification, because it determines which obligations are mandatory and therefore constrains everything above.

What none of them cover well

All of them are weakest in the same place: the operational middle. They describe risks and structures more confidently than they describe detection engineering — what telemetry to emit from an inference endpoint, what an injection attempt looks like in logs, what threshold triggers a page. That gap is closing slowly, and it is where most of the practical work now sits.

To keep the framework and policy movement in view without reading every consultation document, the personalized AI-Sec digest builder filters this site’s tagged coverage down to the policy and framework categories, and the primary-source library collects the standards themselves in one place.