I was in a meeting recently where someone asked a simple question: “Which OWASP list should we use for our AI security review?”

Nobody could answer it. Not because the people in the room were incompetent. The opposite, actually — they’d all read the lists, which is precisely why they couldn’t answer. There are five of them now. Five OWASP AI security lists. Each one a Top 10, except the one that’s a 200-page guide. They overlap, contradict, and occasionally talk past each other. When someone finally pulled up Matt Adams’ OWASP AI Top 10 Comparator — a tool that exists specifically because the proliferation problem is bad enough to need its own website — the room collectively sighed.

That sigh captured a real frustration. The people who built these lists are smart, dedicated security professionals doing genuinely hard work in a domain that changes every few months. The lists contain real insights. The problem is not that OWASP AI guidance is wrong; it is that it is fragmented across artifacts optimized for different eras and audiences. When you have five documents that partially overlap, use different terminology for the same risks, and target subtly different deployment patterns, the result isn’t guidance — it’s homework.

But there’s a better way to think about this. Before I explain why five lists happened, let me give you what you actually came for: how to do practical AI security work without drowning in cross-references.

Start With Your System, Not a List

Here’s the approach I’ve seen work for teams that are tired of checking boxes and still getting pwned.

The Lethal Trifecta

Simon Willison has a framework he calls the Lethal Trifecta. It’s not a list of ten risks. It’s a three-part test:

  1. Private data access — the AI system can see sensitive information.
  2. Untrusted content — the AI system processes input from sources you don’t control.
  3. External communications — the AI system can reach out to the outside world.

If your system has all three, you have a prompt injection problem. Period. It doesn’t matter what list you’re following or what ID code you assign to it. The risk is real and it’s severe.

The beauty of the Lethal Trifecta is that it’s a test, not a list. You look at your system’s architecture and ask: does it have all three properties? If yes, you have work to do. If no, you’re probably fine for now.

It also highlights something the lists miss: it’s not individual risks that kill you, it’s combinations. LLM01 (Prompt Injection) is dangerous primarily when combined with LLM06 (Sensitive Information Disclosure) and LLM02 (Insecure Output Handling). The trifecta captures this interaction naturally. The lists, by enumerating risks individually, tend to obscure it.

One important caveat. The trifecta is excellent for immediate triage, but passing the test (i.e., missing one leg) can produce a false sense of security. Consider an internal RAG system with private data and untrusted content but no external communications — a “two-legged” system. It passes the trifecta, but it remains vulnerable to significant internal data exfiltration through indirect prompt injection, and to “jailbreak-to-inference” attacks where an adversary manipulates the model’s reasoning to extract sensitive information through crafted queries that don’t require outbound channels. The trifecta tells you where the highest-priority risk lives. It doesn’t tell you the system is safe.

I’m not saying it replaces the lists. It doesn’t cover supply chain risks, model theft, or training data poisoning. But as a practical triage tool for the most common and dangerous class of LLM vulnerabilities, it’s more useful than any Top 10 list I’ve seen.

The Three-Layer Practitioner Framework

For everything beyond the trifecta, instead of cross-referencing five overlapping lists, think about AI security as three layers:

Layer 1: Model security. Protect the model itself — model theft (LLM10/ML05), training data poisoning (LLM03/ML02/ML10), and supply chain vulnerabilities (LLM05/ML06). This layer ensures the model you’re running is the model you think you’re running, and that it wasn’t corrupted during training or deployment.

One thing to be honest about: for most AppSec engineers, Layer 1 is a black box. The article correctly notes this maps to infrastructure security, but the remediation for Layer 1 often requires Data Science intervention, not just engineering controls. If you don’t own the training pipeline — and most teams consuming foundation models through APIs don’t — your Layer 1 controls are limited to vendor due diligence, contract terms, and runtime monitoring. The OWASP lists describe Layer 1 risks thoroughly; they’re less helpful on what to do when you can’t access the weights.

Layer 2: Interface security. Protect the inputs and outputs — prompt injection (LLM01), insecure output handling (LLM02), input manipulation (ML01), and overreliance (LLM09). This layer ensures that the model’s inputs can’t corrupt its behavior and that its outputs can’t corrupt downstream systems. It applies to any system that processes external input.

Layer 3: Agent security. Protect the actions — excessive agency (LLM08), insecure plugin design (LLM07), and the agentic-specific risks from the newest list. This layer ensures that when AI systems take actions — calling APIs, executing code, modifying data — those actions are bounded, monitored, and auditable. It only applies to systems that do things, not just systems that say things.

This model has useful properties. It’s architecture-driven: look at your system and say “we need Layer 1 and Layer 3 but not Layer 2” or “we need all three.” It absorbs the overlap naturally: model theft is a Layer 1 concern regardless of which list calls it what. And it maps to existing security practices: Layer 1 is like infrastructure security, Layer 2 is like application security, and Layer 3 is like operational security.

It also makes the governance challenge clearer. If you’re a CISO, you need policies for all three layers. If you’re a security engineer, you need technical controls for the layers relevant to your system. If you’re an auditor, you need evidence that all applicable layers are addressed. The three-layer model gives everyone a shared vocabulary without requiring them to cross-reference five documents.

This isn’t a replacement for the OWASP lists. It’s a way of organizing them. The lists contain valuable detail — specific attack patterns, mitigation strategies, references. But the detail is more useful when organized around architectural layers than when scattered across overlapping Top 10s.

What Actually Works

Beyond the trifecta and the three layers, here are the approaches I’ve seen effective teams use.

Data flow analysis. Instead of enumerating risks, trace the data. Where does sensitive data enter? Where does untrusted data enter? Where do they mix? What can the system do with the mixed data? This is traditional security thinking applied to AI, and it works because it’s architecture-driven rather than list-driven.

Threat modeling the agent loop. For agentic systems, the core loop is: observe → plan → act → observe. At each stage, ask: what could go wrong? What if the observation is manipulated? What if the plan is influenced by adversarial input? What if the action has unintended side effects? This is more useful than any list because it’s specific to your system.

Abuse case development. Instead of asking “what could go wrong?”, ask “what would an attacker want to achieve?” For an AI agent with CRM access, the attacker goals might be: exfiltrate customer data, modify pricing records, send phishing emails from the company’s domain. Each goal generates specific test cases that map to specific architectural weaknesses. This is more productive than starting with “LLM01: Prompt Injection” and trying to imagine all the ways it could manifest.

Red teaming with specific goals. Not generic “try to break the AI” exercises, but goal-oriented red teaming: “Can you make the agent send an email to an external address?” “Can you make it delete a database record?” “Can you extract the system prompt?” Specific goals produce specific findings. Generic red teaming produces generic reports.

Continuous monitoring. The lists are static, but AI system behavior is dynamic. The most effective security teams instrument their AI systems to detect anomalous behavior in real time — unusual API call patterns, unexpected data access, outputs that deviate from normal distributions.

Address shadow AI. Most practitioner frameworks assume you’re reviewing a known, approved system. In practice, the problem often starts with discovering that developers have already integrated LLM APIs into existing pipelines without a security review. Before you secure the AI system you know about, find the ones you don’t. Scan for unmanaged API key usage, unsanctioned model endpoints, and “just trying it out” scripts that made it to production.

Mind the security-latency tradeoff. Real-world security controls for AI — LLM-based guardrails, complex output scanning, multi-step approval chains — introduce latency. For real-time applications like customer-facing chatbots or live coding assistants, a 500ms guardrail check can mean the difference between a usable product and a frustrated user. A practical framework has to account for this tension. Not every control can run synchronously. Some need to be async post-processing. Some need to be sampling-based rather than inspecting every interaction. The OWASP lists describe what to do but rarely address the performance cost of doing it.

These approaches share a common trait: they’re grounded in the specific system you’re securing, not in a generic list of risks. They require you to think about your architecture, your data flows, and your threat actors. They’re harder than checking a list. They’re also more effective.

Why the Lists Miss Things

The three-layer model and the practitioner approaches above are useful, but they have gaps. And those gaps reveal something important about why static lists struggle.

Context window persistence attacks. LLMs maintain conversation context — a shared state between user and system. Attacks that manipulate this state through gradual context poisoning across a long conversation represent a risk that doesn’t fit neatly into existing categories. You’re not injecting a single malicious instruction. You’re slowly shifting the model’s behavior over hundreds of turns until it does something it wouldn’t have done at turn one. Corll (2026) has shown that multi-turn prompt injection attacks distribute malicious intent across conversation turns, exploiting the assumption that each turn is evaluated independently — and that a simple weighted-average scoring approach fails to detect them because it converges to the per-turn score regardless of turn count. This is the AI equivalent of a long con, and it’s not in any Top 10.

Multi-agent adversarial dynamics. The Agentic AI list addresses single-agent risks, but adversarial interactions between multiple agents are largely unexplored in standards. If your coding agent and your deployment agent both have elevated permissions and they interact, the attack surface isn’t just the union of their individual risks — it’s something more complex. Agent-to-agent social engineering, where one agent crafts inputs specifically designed to manipulate another agent’s behavior, is a class of risk the research community is starting to examine. Shapira et al. (2026) demonstrated this in a two-week red-teaming study of autonomous agents deployed with persistent memory, email, Discord, and shell access. Documented failures included unauthorized compliance with non-owners, cross-agent propagation of unsafe practices, and partial system takeover — not through direct exploitation, but through the agents’ own autonomous reasoning over manipulated information environments. The attacker never touches your system directly — they just influence the information environment your agents operate in.

Supply chain at the data layer. LLM05 and ML06 cover supply chain risks, but they focus on model artifacts and training pipelines. If your RAG system indexes content from the internet, and that content is adversarially crafted, you have a supply chain vulnerability that none of the lists adequately address. This is prompt injection’s ugly cousin: not direct injection into the prompt, but injection into the retrieval corpus that feeds the prompt. Research on indirect prompt injection through retrieved content has demonstrated this is practical, not theoretical.

These blind spots aren’t random. They cluster at the boundary between what’s established and what’s emerging. The lists tend to fight the last war.

How We Got Five Lists Instead of One

Now that you have a framework, here’s why the framework was needed in the first place.

The five lists — OWASP Top 10 for LLM Applications v1.1 (2023-24), v2 (2025), the ML Security Top 10 (2023), the AI Security & Privacy Guide (200 pages), and the Agentic AI Top 10 (2025-26) — capture three distinct eras of AI. The ML Top 10 was written for traditional models: classifiers, functions, mathematical adversarial examples. The LLM Top 10 was written for language models: natural language inputs, instruction-following, prompt injection. The Agentic AI Top 10 was written for autonomous systems: planning, tool use, action chains. Each list is a fossil record of its era, and the eras overlap because organizations deploy all three simultaneously.

OWASP responded the way standards bodies do: by creating working groups. The LLM group formed in 2023. The ML group was already working. The Agentic AI group spun up in 2025. Each group produced its own list, each correct by its own lights. But nobody stepped back and asked: are we helping?

The original OWASP Top 10 for Web Applications works because web security is mature. SQL Injection has been understood since the 1990s. The attack patterns are stable enough that a list updated every three years remains relevant. AI security has none of that stability. The attack surface has transformed completely at least three times in three years. A static Top 10 can’t keep up. By the time the list is published, the deployment patterns have moved on.

The overlap compounds the problem. Model Theft appears as LLM10, ML05, and presumably in the Agentic AI list. Supply Chain Vulnerabilities appear as LLM05, ML06, and in the Agentic AI list. Three IDs for “you imported something malicious.” The ML Top 10 has two entries for poisoning (ML02 and ML10); the LLM Top 10 collapses them into one. The ML list has more granularity, but fewer people read it, so the distinction is lost on most practitioners.

Then there’s the governance trap. The 200-page AI Security & Privacy Guide is the most comprehensive document OWASP has produced on AI security. It’s contributing to international standards. But in practice, it rarely surfaces in sprint planning. Teams tend to memorize “Prompt Injection is #1” and treat the Top 10 as a checklist. The most comprehensive guidance is the least actionable; the most actionable guidance is the least comprehensive.

Matt Adams built the OWASP AI Top 10 Comparator specifically to map these overlaps. It’s a thoughtful tool — but the fact that it needs to exist tells you something about the state of the standards. The root cause is structural: OWASP is organized as working groups, and each group produces its own deliverable with its own scope, contributors, and timeline. There’s no mechanism for consolidation.

The OWASP AI Exchange and the GenAI Security Project are trying to provide synthesis. But they’re competing for attention with the Top 10 lists, which brings us back to the original problem: too many documents, not enough consolidation.

There’s a deeper dynamic at work. The demand for simplicity in a domain that resists it shows up everywhere in security — cloud, containers, mobile. Each time, it took years for the community to develop domain-specific thinking that matched the actual threat model. AI security is going through the same process, but faster and with higher stakes. Companies aren’t waiting for guidance before deploying AI agents. The gap between “we checked the Top 10” and “our system is actually secure” is significant, and it’s growing.

What I Tell People

When people ask me which OWASP AI security list to use — the question that started this whole thing — here’s what I say.

Don’t start with a list. Start with your system.

Draw the architecture. Where does sensitive data flow? Where does untrusted input enter? What actions can the system take? These three questions will tell you more about your security posture than any Top 10 list.

Then use the three-layer model to pick the right reference material. Model security concern? Look at Layer 1 risks across all lists. Interface security? Layer 2. Agent security? Layer 3. Use the lists as reference material, not as checklists.

And always apply the Lethal Trifecta test. If your system has private data access, processes untrusted content, and has external communications, you have a prompt injection risk. Full stop. No list required.

Also: find your shadow AI before it finds you. Scan for unmanaged LLM API usage and unsanctioned model endpoints. And factor latency into your control design — not every guardrail can run synchronously.

Finally, watch the field. AI security moves fast enough that any static document is outdated within months. Follow researchers like Carlini and Willison. Monitor MITRE ATLAS for evolving attack patterns. Read the incident reports when they come out. The lists are snapshots. The field is a movie.

Five OWASP AI lists and none of them alone is enough. The good news is that you don’t need all five — you need to think clearly about your system’s architecture. The three-layer model and the Lethal Trifecta will get you further than any checklist. The lists are useful once you know what you’re looking for. They just shouldn’t be where you start.

References: