OWASP Top 10 for LLM 2026: From Risk List to Audit Evidence

The OWASP Top 10 for LLM Applications got a new edition on 3 August 2026, and the order changed more than in any earlier release. Excessive Agency climbed to third place, System Prompt Leakage became Hidden Context Exposure, and for the first time the ranking was tested against a corpus of 7,714 real incidents. Most explainers stop at restating the ten entries. This guide reads the OWASP Top 10 for LLM the way an auditor or a market surveillance authority would: what moved, how the ranking was built, which EU obligations each entry touches, and which records prove you dealt with it.

Key takeaways

• The 2026 edition of the OWASP Top 10 for LLM was released on 3 August 2026. Eight of ten entries changed rank. Only Prompt Injection and Sensitive Information Disclosure kept their place.
• The ranking now blends a practitioner vote (75 percent) with an incident record (25 percent). Rank order is a consensus signal, not a risk score for your system.
• Appendix A of the OWASP Top 10 for LLM maps it to nine security frameworks. The EU AI Act and ISO/IEC 42001 are not among them, so compliance teams have to build that bridge themselves.
• Article 15(5) of the EU AI Act names data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. All five sit inside the OWASP Top 10 for LLM.
• The list is voluntary. The evidence behind it is not, once the AI Act, the Cyber Resilience Act, GDPR, NIS2 or DORA applies to you.

What is the OWASP Top 10 for LLM Applications?

The OWASP Top 10 for LLM Applications is a community-written awareness document that names the ten most critical security risks of applications built on large language models. It is maintained by the OWASP GenAI Security Project, part of the foundation whose web application Top 10 has shaped security testing since 2003. For a wider view of the discipline it belongs to, see our guide to AI security. Four editions of the OWASP Top 10 for LLM exist. Version 1.0 appeared on 1 August 2023, version 1.1 on 16 October 2023, the 2025 edition on 18 November 2024, and the 2026 edition on 3 August 2026. The current document runs to 122 pages under a CC BY-SA 4.0 licence. Each entry has a description, common examples, prevention and mitigation strategies, and attack scenarios. By our count the ten entries carry 96 numbered mitigation strategies between them, from 3 for Hidden Context Exposure to 19 for Sensitive Information Disclosure. The posture is set in the opening letter from the project leads: “Stop trying to build a model that cannot be fooled.” Build the system around the model, so that a fooled model breaks nothing important. That is an architecture claim, and it matters for governance, because it moves the control point from the model vendor to the team that deploys the application.

An awareness document, not a control standard

Nobody certifies against the OWASP Top 10 for LLM. It contains no binding requirements, no conformity scheme and no accredited auditors. It is a prioritised vocabulary: a shared set of names for what goes wrong, with suggested defenses. Its value in a compliance programme is that security engineers, penetration testers, vendors and auditors already use those names. A finding labelled LLM03 reads the same way in an AI red teaming report, a supplier questionnaire and a board paper. The scope is also narrower than the title suggests. The OWASP Top 10 for LLM owns the risk when the model is a component inside your application. When the model becomes an actor, with tools it can call, memory it carries between sessions and consequences it sets in motion downstream, OWASP hands over to its Top 10 for Agentic Applications, announced on 9 December 2025. That boundary has its own section below.

The OWASP Top 10 for LLM 2026 list: what moved

<table header-row=”true”> <tr> <td>2026 ID</td> <td>Entry</td> <td>2025 rank</td> <td>What changed</td> </tr> <tr> <td>LLM01</td> <td>Prompt Injection</td> <td>1</td> <td>Holds first place. Now covers cross-modal attacks hidden in images, audio or video, and injections that persist in memory or a retrieval corpus</td> </tr> <tr> <td>LLM02</td> <td>Sensitive Information Disclosure</td> <td>2</td> <td>Holds second. Disclosure surfaces now include tool-call arguments, reasoning traces, logs, embeddings and timing side channels</td> </tr> <tr> <td>LLM03</td> <td>Excessive Agency</td> <td>6</td> <td>Up three places. Root causes unchanged: excessive functionality, excessive permissions, excessive autonomy</td> </tr> <tr> <td>LLM04</td> <td>Supply Chain</td> <td>3</td> <td>Down one. Now covers promoted model artefacts that are not what they claim to be, adapters and conversion pipelines</td> </tr> <tr> <td>LLM05</td> <td>Data and Model Poisoning</td> <td>4</td> <td>Down one. Absorbs fine-tuning subversion and poisoning through retrieval ingestion</td> </tr> <tr> <td>LLM06</td> <td>Unbounded Consumption</td> <td>10</td> <td>Up four. Reframed around cost asymmetry: reasoning models, multimodal inputs and agent loops</td> </tr> <tr> <td>LLM07</td> <td>Misinformation</td> <td>9</td> <td>Up two, pulled up by the incident record</td> </tr> <tr> <td>LLM08</td> <td>Hidden Context Exposure</td> <td>7</td> <td>Renamed from System Prompt Leakage and widened to retrieved policy text, tool schemas and any hidden context</td> </tr> <tr> <td>LLM09</td> <td>Vector and Embedding Weaknesses</td> <td>8</td> <td>Down one. Scope now includes vector-backed agent memory and semantic caches</td> </tr> <tr> <td>LLM10</td> <td>Improper Output Handling</td> <td>5</td> <td>Down five, the largest fall. Adds terminal control characters, auto-fetching renderers and insecure generated code</td> </tr> </table> Three points follow from the 2026 OWASP Top 10 for LLM. Agency is where the damage lands. OWASP calls the rise of Excessive Agency “the most consequential move on the list”, because the vote and the incident record agree. An assistant that only answers can mislead. An assistant that can send email, write to a database or issue a refund can act on a manipulated instruction. The entry’s three root causes are a usable review checklist: does the application have tools it does not need, permissions wider than the task, or the ability to act without approval? The identifiers changed meaning. New risks were folded into existing entries instead of creating thin new categories, so the ten names are mostly familiar. The numbers are not. LLM03 meant Supply Chain in 2025 and means Excessive Agency in 2026. LLM06 meant Excessive Agency and now means Unbounded Consumption. Any risk register, test plan or supplier questionnaire that cites a bare identifier is now ambiguous. Write the year with the identifier (LLM03:2026) and re-key older records. Hidden context is assumed discoverable. The renamed LLM08 tells developers to design as if the system prompt, retrieved policy text and tool schemas can be extracted. No credentials in the prompt, and no reliance on hidden instructions as the only authorisation check. For a control owner this becomes a simple test: if the full context window leaked tomorrow, what would an attacker gain?

How the 2026 ranking was built: a vote tested against incidents

Every earlier edition of the OWASP Top 10 for LLM rested on practitioner judgment alone. For 2026 the project team assembled 7,714 incidents from public vulnerability databases and an AI-harm database, built classifiers to read them, and sorted the 6,639 that carried enough detail. The final order gives the community vote three quarters of the weight and the incident data one quarter. The two sources disagreed in instructive places:

• Prompt Injection. Practitioners rank it first. Ranked by the raw incident record alone, it falls out of the top ten. OWASP reads this as a defense effect: teams fight injection hard, so fewer clean exploits reach a public database. The exposure is still real, as the zero-click flaw tracked as CVE-2025-32711 showed in a production assistant.
• Misinformation. Voters placed it near the bottom, the incident record near the top, the widest gap on the list. It landed seventh.
• Sensitive Information Disclosure. The one place at the top where belief and evidence agree.

For a risk register, three consequences matter more than the ranking itself.

1. Rank is not severity for your system. A customer-facing assistant with no tools has little LLM03 exposure. An internal agent with write access has a great deal. Score each entry against your own architecture.
2. Public incident counts undercount well-defended risks. The Cloud Security Alliance’s research note on the 2026 edition puts it plainly: “absence of incidents is not evidence of absence of risk”.
3. Misinformation is now a security entry, not only a quality issue. When a fluent wrong answer drives a decision or a tool call, it becomes a wrong action. That links the OWASP Top 10 for LLM to accuracy duties, and to what we describe in our piece on hallucination as the main generative AI risk.

What the OWASP Top 10 for LLM does not map: the EU AI Act and ISO/IEC 42001

Appendix A of the 2026 OWASP Top 10 for LLM consolidates mappings to nine external frameworks, each pinned to a version: the OWASP Top 10 for Agentic Applications, OWASP GenAI Data Security 2026, MITRE ATLAS, MITRE ATT&CK, CWE, NIST AI 600-1, the NIST AI RMF, the CSA AI Controls Matrix and the OWASP AI Vulnerability Scoring System. All nine are security or risk taxonomies. Neither the EU AI Act nor ISO/IEC 42001 is among them. The AI Act is named three times in 122 pages, all around LLM02, and one mention still dates high-risk obligations to August 2026, a date that the Digital Omnibus, Regulation (EU) 2026/1744, moved to 2 December 2027 for Annex III systems. That is not a flaw in a security document. It is a gap for anyone who must show a regulator how security work answers a legal duty. The bridge is shorter than it looks. Article 15(5) of the EU AI Act requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance, and it lists the AI-specific vulnerabilities to address: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws. Each one has a home in the OWASP Top 10 for LLM. The crosswalk below is our reading, not an OWASP or Commission mapping. <table header-row=”true”> <tr> <td>Entry</td> <td>EU AI Act hook</td> <td>Evidence an auditor asks for</td> </tr> <tr> <td>LLM01 Prompt Injection</td> <td>Art. 15(5) adversarial inputs; Art. 55(1)(a) adversarial testing</td> <td>Test report per release against attackers who know the defense; inventory of untrusted input channels</td> </tr> <tr> <td>LLM02 Sensitive Information Disclosure</td> <td>Art. 15(5) confidentiality attacks; Art. 10; GDPR Art. 32</td> <td>Data classification of every context source; redaction test results; disclosure incident playbook</td> </tr> <tr> <td>LLM03 Excessive Agency</td> <td>Art. 14 human oversight; Art. 26 deployer duties</td> <td>Tool and permission register per application; approval rule for high-impact actions; tool-call logs</td> </tr> <tr> <td>LLM04 Supply Chain</td> <td>Art. 25 value chain; Art. 15(5) pre-trained components</td> <td>Model and dataset provenance records; signed component inventory; supplier assessments</td> </tr> <tr> <td>LLM05 Data and Model Poisoning</td> <td>Art. 10 data governance; Art. 15(5) data and model poisoning</td> <td>Dataset lineage; validation of fine-tuning and retrieval ingestion; approval of retraining</td> </tr> <tr> <td>LLM06 Unbounded Consumption</td> <td>Art. 15(4) resilience to errors and faults</td> <td>Spending caps; rate limits; circuit-breaker test results; cost alerts</td> </tr> <tr> <td>LLM07 Misinformation</td> <td>Art. 15(1) and (3) declared accuracy; Art. 14(4)(b) automation bias</td> <td>Accuracy and groundedness metrics; evaluation results; user guidance on overreliance</td> </tr> <tr> <td>LLM08 Hidden Context Exposure</td> <td>Art. 15(5) confidentiality attacks</td> <td>Secrets scan of prompts and tool schemas; proof that authorisation is enforced outside the model</td> </tr> <tr> <td>LLM09 Vector and Embedding Weaknesses</td> <td>Art. 10; Art. 15(5); GDPR Art. 32</td> <td>Tenant-isolation tests at retrieval; ingestion provenance log; deletion procedure for embeddings</td> </tr> <tr> <td>LLM10 Improper Output Handling</td> <td>Art. 15(5) model flaws; Cyber Resilience Act Annex I</td> <td>Output-encoding tests; inventory of downstream sinks; secure development records</td> </tr> </table> For ISO/IEC 42001, the same artefacts land inside the management system: the Annex A controls on the AI system life cycle (verification and validation, operation and monitoring, event logs), on data for AI systems (quality and provenance), on third-party and customer relationships, and on the use of AI systems. A certification auditor will not ask whether you are “OWASP compliant”. They will ask how you identified AI security risks and what you decided for each. A decision record per entry is a clean answer.

Which law makes this evidence demandable

The OWASP Top 10 for LLM is voluntary. What it describes is not, once one of these regimes applies to you.

• EU AI Act, Article 15. It binds high-risk AI systems. After the Digital Omnibus, Annex III systems must comply from 2 December 2027 and Annex I products from 2 August 2028. Start with how to classify a system as high-risk.
• EU AI Act, Article 55. Providers of general-purpose AI models with systemic risk must conduct and document adversarial testing and ensure adequate cybersecurity protection for the model and its physical infrastructure (Article 55). These duties have applied since 2 August 2025, and the Commission’s enforcement powers over those providers started on 2 August 2026.
• Cyber Resilience Act. Regulation (EU) 2024/2847 covers products with digital elements, which includes most commercial software that embeds a language model. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform, with an early warning within 24 hours and a notification within 72 hours (Jones Day summary). The full essential requirements apply from 11 December 2027. Article 12 of the same regulation deems a high-risk AI system that meets those requirements to satisfy the cybersecurity requirement of Article 15 of the AI Act.
• GDPR, Article 32. Security of processing applies to any application that touches personal data, whatever its AI Act risk class. LLM02 and LLM09 describe personal data breaches before they happen.
• NIS2 and DORA. Essential and important entities, and financial entities, already owe risk management measures and incident reporting for their ICT systems. A language model application is one of those systems. DORA has applied since 17 January 2025.

Two dates belong in the project plan. Annex III high-risk obligations on 2 December 2027 and full application of the Cyber Resilience Act on 11 December 2027 fall nine days apart. A team that keeps one security file, structured by OWASP entry and cross-referenced to both regulations, prepares for both at once. The harmonised standard on AI cybersecurity was still in preparation at CEN-CENELEC in mid-2026, so a recognised public taxonomy is, for now, the most defensible structure for your own analysis.

From the OWASP Top 10 for LLM to evidence: a six-step method

1. Inventory every language model application. For each one, record the model, the context sources, the tools, the memory stores and the downstream sinks. Without an AI inventory, nobody can say which entries are in scope. A registry such as the AI Sigil AI Registry keeps that record per system.
2. Decide applicability entry by entry. Write “applies”, or “does not apply” with the reason. OWASP itself notes that a retrieval system without vectors has no LLM09 attack surface. A recorded rejection is evidence. Silence is a gap.
3. Select mitigations and name an owner. Choose from the 96 strategies in the OWASP Top 10 for LLM, map each to a control you already run where one exists, and name the artefact that proves it.
4. Test before release and after every change. A new model version, system prompt, tool or retrieval corpus reopens LLM01, LLM03 and LLM08. OWASP asks for tests against adaptive attackers who have read the deployed defense, not a static suite. Our guide to adversarial AI covers the attack families.
5. Put the supply chain in the contract. LLM04 and LLM05 cannot be closed by testing alone. Provenance, signing, vulnerability notice and change notification belong in vendor due diligence and in the agreement.
6. Set incident thresholds and clocks in advance. Decide what counts as a serious incident under Article 73 (see AI incident reporting), an actively exploited vulnerability under the Cyber Resilience Act and a personal data breach under GDPR, and who files within 24 or 72 hours.

Each step leaves a record. Together they form what security teams would recognise as a statement of applicability for language model risk: ten entries, a decision for each, a control, an owner and a test result. That file is what turns the OWASP Top 10 for LLM from a poster on the wall into audit evidence.

LLM Top 10 or Agentic Top 10: which list applies

OWASP draws the line by role. If the model is a component that returns text to your code, the OWASP Top 10 for LLM applies. If the model is an actor that calls tools, keeps memory and triggers downstream effects, the OWASP Top 10 for Agentic Applications applies as well. Appendix A maps every LLM entry to its agentic counterparts. Excessive Agency, for example, shows up there as ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse and ASI08 Cascading Failures. Most enterprise deployments sit on the boundary. A chat assistant gains one connector, then a second, then write access, and nobody re-scopes the risk analysis. Two checks help.

• Record three attributes per application in the inventory: tools, persistent memory, and the ability to act without approval. When any of them changes, apply both lists.
• Use the “lethal trifecta” that OWASP cites from Simon Willison as a pre-deployment question. An agent that can read private data, ingest untrusted content and communicate externally has the conditions for high-impact exploitation. Removing any one of the three removes them.

Human approval is the control OWASP returns to most often, and also the one it trusts least at volume: approval fatigue degrades reviewer judgment. That is a design problem for human oversight, not a box to tick. For the governance model around agents, see our guide to autonomous AI agents and the comparison of agentic AI vs generative AI. France’s ANSSI and Germany’s BSI reach a similar conclusion in their joint paper on Zero Trust design principles for LLM-based systems.

FAQ

What is the OWASP Top 10 for LLM in simple terms? The OWASP Top 10 for LLM is a ranked list of the ten most critical security risks in applications built on large language models, written by the OWASP GenAI Security Project. Each entry explains how the failure happens, gives examples and proposes defenses. It is free, licensed under CC BY-SA 4.0 and updated roughly every year. Security teams use it to scope tests, vendors use it to describe coverage, and auditors increasingly use it as a reference vocabulary. What changed in the OWASP Top 10 for LLM in 2026? Eight of ten entries changed rank. Excessive Agency rose from sixth to third, Unbounded Consumption from tenth to sixth and Misinformation from ninth to seventh. Improper Output Handling fell from fifth to tenth. System Prompt Leakage was renamed Hidden Context Exposure. The method changed too: the practitioner vote was weighted at 75 percent and an incident record of 7,714 cases at 25 percent. Is the OWASP Top 10 for LLM mandatory? No. The OWASP Top 10 for LLM is a voluntary awareness document with no certification scheme. The risks it names are covered by binding rules, though: Article 15 of the EU AI Act for high-risk systems, Article 55 for general-purpose models with systemic risk, the Cyber Resilience Act for products with digital elements, and GDPR Article 32 wherever personal data is processed. Using the OWASP Top 10 for LLM to structure your evidence is a choice. Having the evidence is not. How does the OWASP Top 10 for LLM relate to the EU AI Act? The OWASP Top 10 for LLM carries no mapping to the AI Act. The closest anchor is Article 15(5), which lists data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. Those correspond to LLM05, LLM04, LLM01, LLM02 with LLM08 and LLM09, and LLM10. Excessive Agency connects to human oversight in Article 14, and Misinformation to the accuracy levels that Article 15 requires providers to declare. Is prompt injection still the number one risk? Yes. In the 2026 OWASP Top 10 for LLM it holds first place on the strength of the practitioner vote. Ranked by public incident data alone it would fall out of the top ten, which OWASP attributes to mature teams containing attempts before they become reportable. The UK’s NCSC makes the underlying point in its note that prompt injection is not SQL injection: models do not separate instructions from data, so the surface cannot be closed, only contained. What is the difference between the LLM Top 10 and the Agentic Top 10? The OWASP Top 10 for LLM covers the model as a component inside an application. The Agentic list, announced on 9 December 2025, covers the model as an autonomous actor with tools, memory and downstream effects. They are designed to be used together. If your application can call tools or act without a human approving each step, read both.

Conclusion

The OWASP Top 10 for LLM is the most widely shared vocabulary for language model security, and the 2026 edition made it more honest by testing belief against an incident record. It remains a security document. It does not tell you which law applies, when, or what a regulator will ask to see. That part is yours: an inventory, a decision per entry, a named control and owner, a test result after every change, and incident clocks agreed in advance. The dates are close enough to plan against, with Cyber Resilience Act reporting already live and December 2027 bringing both the high-risk obligations and full product requirements. AI Sigil links each language model application in the registry to its applicable entries, selected controls, test results and incident decisions, so the answer to an auditor is a report, not a reconstruction.