Six AI Security Frameworks and Which One You Actually Need

There are more AI security frameworks than any team can adopt, and people bounce off them because they get compared as if they were alternatives. Some enumerate risks, some describe a method for finding risks, and some describe how an organisation governs the whole activity. Choosing between categories is the decision that matters; choosing within a category is mostly taste.

What follows is a map rather than a catalogue. For each framework it covers what question it answers, who it is for, and when to reach for it.

The problem

A platform lead is told to "align with a framework" before an internal assistant goes live. Search returns OWASP lists, a NIST framework, a CSA methodology, a MITRE knowledge base, and a handful of newer entries. They pick NIST because it sounds most official, spend six weeks mapping organisational functions, and ship a system that still runs with a shared service account and no egress restrictions.

Nothing about that work was wrong. It just answered a question nobody had asked. NIST AI RMF describes how an organisation governs AI risk, and it does not tell you that your agent's credential is too broad.

Why it's different with AI

The categories exist in ordinary security too. The difference is how new most of these frameworks are, how fast they revise, and how confidently people cite things that turn out not to exist.

While checking sources for this series, three newer frameworks came up on a conference slide. Two have primary documents. The third, listed as SAILORS, could not be located at all: no paper, no project page, no publication under that name in this field. It may be a misheard name or an internal tool. Either way, you cannot adopt it, and it is better to say so than to pass the name along because it appeared next to real ones. If a framework has no document you can read, it cannot be a dependency.

That check taught one more thing: always name the edition. The OWASP LLM Top 10 reordered entries in its 2026 edition, so a control mapped to an ID from an earlier version may now point at a different risk [1].

The six, by category

Risk lists: what can go wrong

OWASP Top 10 for LLM Applications 2026 [1] covers ten risks in systems that use a model, from prompt injection at LLM01 through improper output handling at LLM10. It was published 3 August 2026. Start here if you build or run anything with a model in it, since it is concrete enough to check a system against in an afternoon.

OWASP Top 10 for Agentic Applications 2026 [2], published 9 December 2025, lists the risks that appear once the model can act: goal hijack, tool misuse, identity and privilege abuse, memory poisoning, rogue agents. It complements the LLM list and does not replace it. Adopt it when your systems hold credentials and take actions.

MITRE ATLAS [3] is a knowledge base of adversary tactics and techniques against AI systems, structured like ATT&CK. It is not a checklist. Red teams and detection engineers get the most from it, because it lets them describe an attack in terms colleagues already understand.

Methodologies: how to find what can go wrong

MAESTRO [4] is a CSA threat-modeling framework that splits an agentic system into seven layers, from foundation models up to the agent ecosystem, and reasons about threats within and across them. Its practical value is the boundary it draws. It makes explicit which layers you own and which belong to a tenant or a model provider, which turns "are we secure?" into a question with an owner.

PHANTOM-B [5] is a mnemonic in the STRIDE tradition, aimed specifically at LLM components, from Shostack + Associates and presented at Black Hat USA 2026. It is designed to be applied in under an hour and to complement STRIDE instead of replacing it. Use it when you already threat-model and want the LLM parts covered without adopting a new process.

Governance: how the organisation manages the activity

NIST AI Risk Management Framework [6] describes organisational functions for governing, mapping, measuring and managing AI risk. It is the right first choice when your pressure is an auditor, a board, or a regulated deployment, and the wrong first choice when your pressure is an assistant going live on Friday.

There is also an academic STRIDE-AI (Cyrille and Schwarz, arXiv preprint, May 2026) that explicitly positions itself as a bridge between the governance level and the technical taxonomies [7]. It is worth reading if that gap is your problem. Note that it is a preprint, and that an unrelated 2021 paper uses the same name.

What actually works

Pick one framework from each category you actually need, and skip the categories you don't. Most infrastructure teams need a risk list and nothing else this quarter, and governance frameworks earn their cost when someone external is asking.

Use the cross-references instead of mapping by hand. These publications reference each other deliberately, and rebuilding those mappings in a spreadsheet is work that goes stale at the next edition.

Write the edition into every control you map. "Mitigates LLM03" is a claim with a shelf life. "Mitigates LLM03:2026 Excessive Agency" survives the next revision, or at least fails loudly.

Let the methodology follow the list. A risk list tells you what to look for. When it stops being enough, usually when systems start acting and coordinating, a methodology tells you how to look. Reaching for the methodology first is where the six wasted weeks come from.

What doesn't work

Adopting the most official-sounding one fails because authority is the wrong axis; category is what you should choose by.

Treating a framework as evidence fails too. Saying you follow a framework describes your process and attests to nothing. No framework on this page certifies anything, and none of the publishers offer a certification against them.

Mapping everything to everything produces a full cross-map of four frameworks, a document nobody reads and everybody has to maintain.

Citing a framework you have not read is the last trap. The SAILORS case is the mild version. The damaging version is mapping a control to an ID that moved between editions.

Where to start

• If you build with models, use the OWASP LLM Top 10 2026 and check one real system against it this week.
• If those systems take actions, add the Agentic Top 10 2026.
• If you need to reason about who owns which layer, use MAESTRO, especially where a tenant or a provider owns part of the stack.
• If an auditor is the reason you are reading this, use NIST AI RMF, and expect it to take longer.
• If you already threat-model, add PHANTOM-B for the LLM components instead of a new process.
• Whatever you pick, record the edition and the date you checked it. Everything on this page revises, and the ones that revise fastest are the ones most worth citing precisely.

Sources

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, published 3 August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, published 9 December 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
3. MITRE ATLAS: https://atlas.mitre.org/
4. Agentic AI Threat Modeling Framework: MAESTRO, Cloud Security Alliance, February 2025: https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
5. PHANTOM-B, Shostack + Associates White Paper #6, July 2026: https://shostack.org/files/papers/PHANTOM-B_Whitepaper_Shostack.pdf
6. NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
7. STRIDE-AI: A Threat Modeling Framework for Generative AI Security Assessment, Cyrille and Schwarz, arXiv preprint, May 2026: https://arxiv.org/abs/2605.17163