OWASP Top 10 for Large Language Model Applications (2025)

The OWASP Top 10 for Large Language Model Applications is a community-voted, open-source taxonomy of the ten most critical security risks for applications built on large language models. The 2025 edition (v2.0) was published on 18 November 2024 by the OWASP GenAI Security Project under the OWASP Foundation and uses the designations LLM01:2025–LLM10:2025.

This page is a Modulos governance guide. The ten OWASP designations are referenced as factual taxonomic labels; everything else — definitions, governance implications, cross-mappings, and Modulos product references — is independently authored.

Quick decision

• Building a chatbot, copilot, or RAG system → the OWASP Top 10 for LLM Applications is your primary AI-security baseline. Use it for threat modelling, red-team scoping, and procurement responses.
• Building a multi-step autonomous agent → layer the OWASP Top 10 for Agentic Applications on top of this list. The LLM list still applies; agentic risks are additional.
• Running an enterprise AI governance programme → use OWASP as the control-level vocabulary inside higher-order frameworks (NIST AI RMF, ISO/IEC 42001). OWASP does not replace either; it feeds evidence into both.
• Subject to the EU AI Act → treat OWASP categories as technical evidence sources for the Article 15 cybersecurity, accuracy, and robustness obligations on high-risk providers, and for the risk-management system in Article 9. Compliance is determined by the Regulation, not by the OWASP list.

TL;DR

• The OWASP Top 10 for LLM Applications 2025 ranks ten security risks observed in production LLM applications. Designations: LLM01:2025 through LLM10:2025.
• Published by the OWASP GenAI Security Project on 18 November 2024 under Creative Commons Attribution-ShareAlike 4.0. Voluntary; no legal status by itself.
• The list covers prompt-handling, data-handling, supply-chain, output-handling, agency, leakage of internal prompts, retrieval-augmentation risks, factual integrity, and resource exhaustion.
• It does not cover classical web vulnerabilities (covered by the OWASP Top 10 for Web Applications) or autonomous-agent-specific risks (covered by the OWASP Top 10 for Agentic Applications).
• Consequence: treat the list as the shared vocabulary your security, engineering, and compliance teams use to scope LLM application threats and the evidence that mitigates them.

Primary source

OWASP Top 10 for LLM Applications 2025 — project page · v2.0 PDF (2024-11-18)

How the OWASP Top 10 for LLM Applications fits into AI governance

The OWASP Top 10 for LLM Applications operates one layer below the management frameworks. Frameworks like the NIST AI RMF and ISO/IEC 42001 describe the system for managing AI risk; OWASP names the specific risks that system is expected to evaluate and treat. In a complete programme:

• the risk-management framework (NIST AI RMF, or the ISO 42001 management system) provides the loop — identification, measurement, treatment, monitoring;
• OWASP populates that loop with named security risks, observable mitigations, and shared test categories;
• the EU AI Act and other regulations impose the legal obligations that the loop must demonstrably satisfy.

That layering is why this page maps each OWASP category to specific NIST subcategories, ISO 42001 Annex A themes, and EU AI Act Articles below.

The 10 LLM risk categories at a glance

OWASP Top 10 for LLM Applications 2025

LLM01:2025 Prompt Injectionadversary-supplied instructions override intended behaviour

LLM02:2025 Sensitive Information Disclosuresecrets, PII, or confidential data leak through outputs or traces

LLM03:2025 Supply Chaincompromised models, datasets, libraries, or hosting providers

LLM04:2025 Data and Model Poisoningmalicious training, fine-tuning, or retrieval data shapes model behaviour

LLM05:2025 Improper Output Handlingdownstream systems trust model output without validation

LLM06:2025 Excessive Agencymodel or agent holds more capability, autonomy, or permission than safe

LLM07:2025 System Prompt Leakageinternal prompts, policies, or tool schemas are exfiltrated

LLM08:2025 Vector and Embedding WeaknessesRAG indexing, retrieval, and embeddings introduce attack and leakage paths

LLM09:2025 Misinformationconfidently incorrect output is acted on as truth

LLM10:2025 Unbounded Consumptioncost, latency, or capacity is exhausted by abuse or missing limits

LLM01:2025 Prompt Injection

In Modulos's words: an adversary supplies natural-language instructions — entered directly or smuggled into retrieved documents, tool responses, web pages, or attachments — that the model executes in place of its intended task.

Governance implications: prompt injection is structural, not a bug. Any system that ingests untrusted content through a model channel inherits the risk. Governance teams should treat the attack surface as the union of every input source the model sees, including search results, files uploaded by other users, and tool outputs; the risk register should reflect that breadth rather than only the user prompt.

Cross-framework mapping: NIST AI RMF MEASURE 2.7 (secure and resilient) and MAP 5 (impacts); ISO/IEC 42001 Annex A controls on AI system operation, monitoring, and information security; EU AI Act Article 15 (accuracy, robustness, cybersecurity) for high-risk providers.

Relevant Modulos surfaces: record the prompt-injection test suite in Runtime Inspection, link results to LLM01:2025 as a requirement, and document residual risk through reviews.

LLM02:2025 Sensitive Information Disclosure

In Modulos's words: the model emits — or its surrounding pipeline persists — data that should not have left the trust boundary: customer PII, credentials, internal documents, or content from another tenant.

Governance implications: disclosure rarely sits inside the model alone. Logs, traces, evaluation captures, and retrieval contexts are the more common leakage paths. Governance teams should map the full data flow — prompt to response to storage — and apply the access, retention, and minimisation rules a regulated data store would receive. Where personal data is in scope, GDPR obligations apply independently of any OWASP work.

Cross-framework mapping: NIST AI RMF MEASURE 2.10 (privacy-enhanced) and MANAGE 3; ISO/IEC 42001 Annex A controls on data for AI systems and information for interested parties; EU AI Act Article 10 (data governance) where high-risk training data is involved.

Relevant Modulos surfaces: document the data-flow map as evidence, evaluate canary-leak tests in Runtime Inspection, and track retention and access rules on prompts and traces.

LLM03:2025 Supply Chain

In Modulos's words: a third-party model, fine-tuning dataset, adapter, library, tokenizer, or hosting provider in the system's dependency graph carries an exposure that the application inherits at runtime.

Governance implications: an LLM application can introduce twenty or more new third-party dependencies. Vendor due-diligence work that was sufficient for classical SaaS dependencies is rarely sufficient for these AI-specific components; governance should expand inventories to AI-BOMs, validate licences and terms-of-service changes, and re-run reviews on every model upgrade.

Cross-framework mapping: NIST AI RMF GOVERN 6 (third-party risk) and MANAGE 3; ISO/IEC 42001 Annex A controls on supplier relationships and third-party AI; EU AI Act Article 25 (value-chain responsibility and provider reclassification — where distributors, importers, deployers, or others can become providers in defined circumstances) and Articles 51–56 (GPAI regime, especially Art 53 and, for systemic-risk GPAI models, Art 55).

Relevant Modulos surfaces: record the AI-BOM as evidence, link vendor reviews to LLM03:2025, and document re-review cadence at model upgrades.

LLM04:2025 Data and Model Poisoning

In Modulos's words: poisoning is a data-lineage failure: corrupted training examples, fine-tuning adapters, or retrieval entries can install hidden triggers or systematic wrong behaviour that later appears to be ordinary model output.

Governance implications: poisoning is harder than runtime attacks for defenders because the corrupted artefact looks identical to a clean one. Governance teams should treat data provenance as a first-class control: track origin, transformations, and approvers for every corpus the system touches; require evaluation deltas after every material data change; and prefer controlled retrieval over retraining when ingesting user-supplied knowledge.

Cross-framework mapping: NIST AI RMF MAP 4 (third-party / data risks) and MEASURE 2.7 (secure and resilient); ISO/IEC 42001 Annex A controls on data for AI systems and AI system lifecycle; EU AI Act Article 10 (data governance) and Article 15 (robustness).

Relevant Modulos surfaces: document data provenance and ingestion approvals, evaluate post-update evaluation deltas in Runtime Inspection, and link backdoor-detection tests to LLM04:2025.

LLM05:2025 Improper Output Handling

In Modulos's words: downstream code, UI, or tools consume the model's output as trusted content — executing, rendering, querying, or acting on it — without the validation a system would apply to any other untrusted user input.

Governance implications: an LLM that emits JSON, SQL, shell, or HTML is producing untrusted input by definition. Treating model output as a trust boundary — parameterised queries, schema validation, content-security policies, approval gates before consequential actions — is design discipline. Governance teams should require this boundary in architecture review, not after incidents.

Cross-framework mapping: NIST AI RMF MEASURE 2.7 (secure and resilient) and MANAGE 2; ISO/IEC 42001 Annex A controls on AI system operation and verification; EU AI Act Article 15 (cybersecurity) and Article 14 (human oversight — the provider-side design obligation for high-risk systems).

Relevant Modulos surfaces: document the output-handling boundary in architecture evidence, link schema validation and policy checks to LLM05:2025, and track approval-gate decisions through reviews.

LLM06:2025 Excessive Agency

In Modulos's words: the model — or an agent built on top of it — holds tool permissions, action scopes, or autonomy levels broader than what the surrounding controls can safely supervise.

Governance implications: excessive agency is rarely a single decision. It accumulates: a new tool, a widened scope, a dropped step-up approval. The governance task is keeping the cumulative envelope visible — tools, scopes, budgets, loop bounds, approval gates — and reviewing changes the way a production-database permission change is reviewed. Article 14 of the EU AI Act anchors the provider-side design obligation for human oversight on high-risk systems.

Cross-framework mapping: NIST AI RMF GOVERN 1 (policies) and MANAGE 1 (treatment); ISO/IEC 42001 Annex A controls on AI system roles, responsibilities, and operation; EU AI Act Article 14 (human oversight design) and Article 15 (robustness).

Relevant Modulos surfaces: document the agent's tool and scope inventory, link approval-gate evidence to LLM06:2025, and track changes through reviews.

LLM07:2025 System Prompt Leakage

In Modulos's words: internal text the application relies on — system prompts, hidden policies, tool schemas, retrieval instructions — is extracted by an adversary and used to plan a bypass or attack.

Governance implications: the practical lesson is that system prompts are configuration, not secrets. Anything that must remain confidential — credentials, authorisation logic, business rules — belongs in code or an enforcement layer outside the model. Governance teams should require this separation as a design rule; the corresponding test is whether the system's security posture would survive an adversary who reads every prompt.

Cross-framework mapping: NIST AI RMF MEASURE 2.7 (secure and resilient) and GOVERN 1; ISO/IEC 42001 Annex A controls on AI system operation and information security; EU AI Act Article 15 (cybersecurity).

Relevant Modulos surfaces: document the prompt-extraction test suite, link results to LLM07:2025, and track design decisions that move sensitive logic out of prompts.

LLM08:2025 Vector and Embedding Weaknesses

In Modulos's words: the retrieval and embedding layer — vector stores, indexing pipelines, embedding models, retrieval policies — becomes either an attack path into the model or a leakage path out of it.

Governance implications: RAG architectures collapse the boundary between document store and prompt channel. A poisoned document, a misclassified embedding, a cross-tenant index, or an unfiltered retrieval all become injection or disclosure vectors. Governance teams should treat the vector store as a permissioned data store — tenancy partitioning, source validation, provenance tagging, retrieval scoping — rather than an inert search index.

Cross-framework mapping: NIST AI RMF MAP 4 (data) and MEASURE 2.7 / 2.10 (secure and resilient, privacy-enhanced); ISO/IEC 42001 Annex A controls on data for AI systems and information security; EU AI Act Article 10 (data governance) and Article 15 (cybersecurity).

Relevant Modulos surfaces: document the RAG architecture and retrieval-scoping policy, evaluate RAG-injection regression tests in Runtime Inspection, and link results to LLM08:2025.

LLM09:2025 Misinformation

In Modulos's words: the model emits confidently stated content that is false, fabricated, or misleading — and a downstream user, system, or decision treats it as accurate.

Governance implications: misinformation differs from other categories because the harm originates from confidence rather than compromise. The governance question is where confidently false outputs become consequential, and what evidence-checking, citation, or review is required there. High-impact domains require a different oversight posture than internal tooling. Articles 50 (transparency to natural persons) and 14 (human oversight) interact with this risk for in-scope systems.

Cross-framework mapping: NIST AI RMF MEASURE 2.3 (system performance) and MEASURE 2.9 (explainable and interpretable); ISO/IEC 42001 Annex A controls on AI system performance evaluation and information for interested parties; EU AI Act Articles 50 and 14 where applicable.

Relevant Modulos surfaces: document factuality and grounding evaluation results in Runtime Inspection, link reviews to LLM09:2025, and track UI risk-communication decisions through evidence.

LLM10:2025 Unbounded Consumption

In Modulos's words: the system has no effective upper bound on the work an LLM call can do — input length, output length, recursion depth, tool loops, total spend — so an adversary or accidental loop can exhaust budget, latency, or capacity.

Governance implications: unbounded consumption surfaces in operations before security. The governance work is treating cost and rate as security controls of equal standing to access controls: per-tenant budgets, hard caps on agentic loops, circuit breakers on tool calls, anomaly alerts on spend. Where the LLM is on the critical path for revenue-producing workflows, unbounded consumption also becomes an availability risk.

Cross-framework mapping: NIST AI RMF MEASURE 2.7 (secure and resilient) and GOVERN 1 (policies); ISO/IEC 42001 Annex A controls on AI system operation, monitoring, and incident management; EU AI Act Article 15 (robustness).

Relevant Modulos surfaces: document budget and rate-limit policies as evidence, evaluate consumption-anomaly signals in Runtime Inspection, and link incident-response records to LLM10:2025.

How to operationalize OWASP Top 10 for LLM Applications in Modulos

Modulos turns the OWASP taxonomy into executable governance by treating each category as a requirement, attaching evidence to its mitigations, and running the supporting evaluations on a schedule.

A typical setup:

1. Requirements — each OWASP category (LLM01:2025 through LLM10:2025) is a requirement on the AI system project. Status reflects whether the supporting controls and evidence are in place.
2. Controls — the mitigation patterns sit as named controls on the project: prompt-injection regression suite, output-validation boundary, secrets hygiene, RAG retrieval scoping, vendor review, budget and rate limits.
3. Evidence — design documents, threat models, AI-BOM entries, vendor reviews, and incident postmortems are recorded once and linked to multiple controls. The same AI-BOM evidence supports LLM03:2025 and, for instance, the NIST AI RMF Manage spoke.
4. Runtime Inspection — prompt-injection regression, factuality evaluation, output-handling negative tests, retrieval-poisoning checks, and consumption-anomaly signals run on a schedule. Results attach to the corresponding requirements and feed remediation loops when they regress.
5. Reviews — sign-off and exception decisions are captured as reviews against the requirement, with the reviewer, rationale, and effective date recorded.

Framework mapping

Four layers, one reusable spine.

Frameworks

EU AI ActRegulatory

ISO 42001Standard

Requirements

Art. 9.1Risk management

Art. 10.2Data governance

6.1.1Risk assessment

Components

Risk identification

Impact analysis

Evidence

Risk registerDocument

Test resultsArtifact

Controls

The reusable spine

One control satisfies many requirements across many frameworks, and groups the components and evidence beneath them.

Risk assessment process

Data validation checks

Reusable

Edge from any layer card crosses into the Controls spine — the same control may serve a regulatory article, a standards clause, a downstream component, and the evidence that closes it.

Evidence linked to an OWASP category may also support selected NIST AI RMF or ISO/IEC 42001 objectives, subject to scope, system classification, and assessor judgment.

See it in Modulos

Modulos turns the OWASP LLM Top 10 into named requirements, linked evidence, and scheduled runtime evaluations.

Request a demo

Cross-framework mapping (preview)

OWASP cluster	NIST AI RMF (selected)	ISO/IEC 42001 (thematic)	EU AI Act (selected)
Prompt and output integrity (LLM01, LLM05, LLM07)	MEASURE 2.7 (secure and resilient), MANAGE 2	AI system operation and monitoring; information security	Art 15 (accuracy, robustness, cybersecurity), Art 14 (human oversight design)
Data and retrieval (LLM02, LLM04, LLM08)	MAP 4, MEASURE 2.10 (privacy-enhanced), MEASURE 2.11 (fair — with harmful bias managed)	Data for AI systems; AI system lifecycle	Art 10 (data governance), Art 15
Supply chain and value chain (LLM03)	GOVERN 6, MANAGE 3	Supplier relationships; third-party AI	Art 25 (value-chain responsibility and provider reclassification); Arts 51–56 (GPAI regime, especially Art 53 and, for systemic-risk GPAI models, Art 55)
Agency and oversight (LLM06)	GOVERN 1, MANAGE 1	Roles, responsibilities, and operation	Art 14 (human oversight design), Art 15
Factual integrity and transparency (LLM09)	MEASURE 2.3, MEASURE 2.9 (explainable and interpretable)	Performance evaluation; information for interested parties	Art 50 (transparency to natural persons), Art 14
Operations and resilience (LLM10)	MEASURE 2.7, GOVERN 1 (policies)	Operation, monitoring, incident management	Art 15 (robustness)

Cross-framework references are conditional on role, system classification, and applicable obligations. For the full pairwise treatment see the framework comparison hub.

Related pages

OWASP for AI security (hub)

The OWASP GenAI Security Project hub — LLM and Agentic Top 10 together

OWASP Top 10 for Agentic Applications

The companion taxonomy (ASI01–ASI10) for autonomous and multi-agent systems

NIST AI RMF — Measure

The NIST function where OWASP categories appear as evaluation targets

NIST AI 600-1 — Generative AI Profile

NIST's GenAI-specific risk profile; overlaps directly with OWASP LLM categories

EU AI Act guide

Where Article 15 cybersecurity and Article 14 oversight obligations land

Source attribution

The OWASP Top 10 for Large Language Model Applications 2025 is published by the OWASP GenAI Security Project under the OWASP Foundation, licensed under Creative Commons Attribution-ShareAlike 4.0. The ten category designations (LLM01:2025–LLM10:2025) are referenced on this page as factual taxonomic labels. All definitions, governance implications, cross-framework mappings, and Modulos product references on this page are independently authored and are not derivative of OWASP descriptive text. "OWASP" and "OWASP Top 10" are trademarks of the OWASP Foundation; references on this page are descriptive use and do not imply endorsement, certification, or affiliation.

Disclaimer

This page is for general informational purposes and does not constitute legal advice or security advice. References to the OWASP Top 10 for Large Language Model Applications reflect the publicly available text at the time of writing; for binding interpretation in your jurisdiction, consult the primary source at genai.owasp.org/llm-top-10/ and qualified counsel. The page links to the OWASP project under CC BY-SA 4.0 for source clarity; no endorsement, certification, or affiliation by the OWASP Foundation is claimed.