The OWASP LLM Top 10 2026 for AI auditors

When an organization puts a large language model into a product, an AI auditor needs a way to ask whether the obvious attacks have been thought about. The OWASP Top 10 for LLM Applications is the most widely used answer: ten risks, each with the controls OWASP recommends. ISACA's AAIA exam content outline names no framework, but its topic on threats and vulnerabilities specific to AI, and its task on evaluating "the organization's threat and vulnerability management programs specific to AI", are where the list earns its place, and three of our AAIA lessons use it. This guide reads the 2026 edition as an auditor uses it: as a test plan, with the control OWASP calls for in each risk and the evidence to ask for.

The short answer

• Ten risks for systems built on language models, in the 2026 order: prompt injection, sensitive information disclosure, excessive agency, supply chain, data and model poisoning, unbounded consumption, misinformation, hidden context exposure, vector and embedding weaknesses, and improper output handling.
• Prompt injection cannot be prevented outright. OWASP's 2026 edition says "no reliable prevention mechanism exists today", so the defense is in the architecture around the model.
• Each risk comes with controls, which is what makes the list usable as audit criteria once an organization adopts it.
• Name the edition. The project's main LLM Top 10 page still lists the 2025 entries, while the 2026 edition reorders and renames some of them.
• Not named by ISACA, but close to the outline's topic on threats and vulnerabilities specific to AI.

Why an AI auditor uses the list

An auditor reviewing an AI system built on a language model meets a problem ordinary IT controls do not fully cover: the model reads text, and text can carry instructions. OWASP's 2026 edition puts it plainly: "Prompt injection is intrinsic to current generative AI: LLMs make no architectural distinction between instructions and data, and their behavior is stochastic, so no reliable prevention mechanism exists today". It follows that "Defense is therefore architectural", and an auditor's job is to check whether that architecture exists.

The list gives the auditor two things. The first is coverage: ten risks that together describe how a language model application fails, so a review that has considered all ten is unlikely to have missed a whole class. The second is criteria: each entry ends with prevention and mitigation strategies, which an organization that adopts the list has, in effect, accepted as its standard.

Our OWASP guide for AAISM candidates reads the same edition for a security manager, with the 2025 numbering, the new ranking method and the controls in depth. This guide takes the auditor's angle and does not repeat it.

The 2026 edition, and which list to cite

The project's own LLM Top 10 page still shows the 2025 entries, from "LLM01:2025 Prompt Injection" to "LLM10:2025 Unbounded Consumption". The 2026 edition, published as a document in August 2026, reorders the list and renames one entry; in its own words, "What used to be System Prompt Leakage is now Hidden Context Exposure". For an auditor, the point is to cite the edition you test against. A finding framed against "LLM03" means excessive agency in 2026 and supply chain in 2025, so a finding without the year can mislead its reader.

The ten risks as a test plan

The 2026 entries are grouped below by what fails. For each, the control in OWASP's words, then the evidence an auditor can ask for, which is our suggestion.

What the model reads

LLM01:2026 Prompt injection. OWASP defines it as input, from a user, a retrieved document, a tool or memory, that "alters the model's behavior in ways the application developer did not intend". Because it cannot be prevented, the controls are the other entries' controls: limited permissions, validated outputs, separated duties. Evidence to ask for: the threat model's treatment of indirect injection through documents and tools, and red-team results on it.

LLM09:2026 Vector and embedding weaknesses. Retrieval stores decide what the model sees, so they carry their own access risks. OWASP: "Enforce tenant scoping inside the index query, not as a post-retrieval filter, and validate it server-side. A client-supplied scope is a suggestion, not a control." Evidence to ask for: how the retrieval store enforces who may see which documents, and who may add documents to it.

What the model can do

LLM03:2026 Excessive agency. An assistant with tools can act, and the risk is acting beyond its task. OWASP's first control: "Limit the tools that LLM agents are allowed to call to only the minimum necessary." Evidence to ask for: the list of tools and permissions each agent holds against what its task needs, and which actions need a human's approval.

LLM10:2026 Improper output handling. Model output passed straight to other systems can become code, queries or markup. OWASP: "Treat the model as any other user, adopting a zero-trust approach, and apply proper input validation on responses coming from the model to backend functions." Evidence to ask for: where model output is consumed, and the validation or encoding at each point.

What the model learns from

LLM04:2026 Supply chain. Models, adapters, datasets and platforms all come from somewhere. OWASP: "Carefully vet data sources and suppliers, including T&Cs and privacy policies, and only use trusted suppliers." Evidence to ask for: the inventory of third-party models and data, the vendor assessments, and how a model's origin is verified before use.

LLM05:2026 Data and model poisoning. Tampered data can change what a model does. OWASP: "Track dataset and model lineage using SBOM/ML-BOM (e.g., CycloneDX), enforce signing and verification, and continuously validate data integrity across lifecycle stages." Evidence to ask for: lineage records for training and fine-tuning data, and the integrity checks run on them.

What the model reveals

LLM02:2026 Sensitive information disclosure. OWASP defines it broadly: a system that "exposes confidential, regulated, privileged, or proprietary data through a channel the data subject, controller, or system owner did not authorize". One of its foundational controls: "Scrub PII at ingest." Evidence to ask for: what personal or confidential data reaches training sets, prompts and retrieval stores, and what filters sit on the way out.

LLM08:2026 Hidden context exposure. System instructions and operating context can be extracted. OWASP's first control: "Do not embed credentials, secrets, or security-critical configuration directly in the system prompts or hidden context." Its working assumption is blunt: "Assume all context available to the LLM could also be available to users." Evidence to ask for: a review of system prompts for secrets, and where credentials actually live.

What the model gets wrong, and what it costs

LLM07:2026 Misinformation. "The core risk is that the incorrect output is trusted and acted upon." OWASP's first control: "Require outputs to be grounded in authoritative and current sources." Evidence to ask for: how answers are grounded, which outputs are checked before anyone acts on them, and how errors are reported.

LLM06:2026 Unbounded consumption. A model can be used to run up cost or deny service. OWASP: "Apply rate limiting and user quotas to restrict the number of requests a single source entity can make in a given time period." Evidence to ask for: limits per user and per key, cost monitoring, and the alert that fires before a budget is gone.

From the list to findings

Using the list well is a matter of discipline more than knowledge. Three habits help an auditor:

• Start from the system, not the list. Not every risk applies to every system: an assistant with no tools cannot have excessive agency, and one with no retrieval store has no vector store to secure. Record which of the ten were judged not to apply, and why.
• Test the architecture, not the prompt. Since OWASP says prompt injection has no reliable prevention, a finding that recommends a stronger system prompt misses the point; the controls that hold are around the model, in permissions, output handling and human approval.
• Frame findings against the edition. Cite "LLM03:2026 Excessive Agency", not "LLM03", and link the control OWASP recommends, so the reader can see the standard the finding applies.

A worked example

Take a retailer's customer-support assistant that runs on a vendor's model, answers from a help-center index, reads customers' order details, and can issue refunds up to a set amount through a tool. Walking the list against it, in our reading:

• It reads untrusted text (customer messages and help articles), so prompt injection (LLM01) and the retrieval index's access rules (LLM09) apply.
• It can act, issuing refunds, so excessive agency (LLM03) asks whether the refund limit and any approval step match the task, and improper output handling (LLM10) asks how the refund tool checks what the model passes it.
• It is built on a vendor's model, so supply chain (LLM04) and poisoning (LLM05) ask how the model and any fine-tuning data were vetted.
• It handles order details, so sensitive information disclosure (LLM02) asks what reaches the model and what can come back out, and hidden context exposure (LLM08) asks whether its system prompt holds anything secret.
• It answers policy questions customers act on, so misinformation (LLM07) asks how answers are grounded in the current policy.
• It is public, so unbounded consumption (LLM06) asks what stops one visitor from running up the bill.

All ten apply here, which is common for a public assistant with a tool. A narrower system, say an internal summarizer with no tools and no retrieval, would leave several out, and the review should say which and why.

How the list meets the AAIA's outline

ISACA's outline does not mention OWASP, and the mapping here is ours. Topic 2F, "Threats and Vulnerabilities specific to AI", is the list's natural home, and the tasks it serves include evaluating "the organization's threat and vulnerability management programs specific to AI", "the organization's identity and access management program specific to AI" (which excessive agency tests directly), and "vendors and supply chain management programs specific to AI solutions" (supply chain and poisoning). Misinformation and output handling reach into supervision and testing too.

How the list shows up in a question

AAIA questions on these risks tend to give a situation and ask you to recognize it, often before anything has gone wrong:

Where to start

Our AAIA lesson on threats and vulnerabilities specific to AI teaches the attacks and the controls around the model, with questions that ask what an auditor should conclude. A free account opens AI models and requirements in full, lessons, questions and flashcards; full access is a single payment with nothing to renew. For the frameworks an organization adopts beside the list, see the NIST AI RMF for AI auditors, and for the law, the EU AI Act for AI auditors.