What Is the OWASP Top 10 for LLM Applications?
- 9 hours ago
- 29 min read
If your team has shipped a chatbot, a retrieval-augmented assistant, or an autonomous agent in the past year, you have already inherited a set of security risks that classic web application checklists were never built to catch. The OWASP Top 10 for LLM Applications exists because prompt injection, data leakage through a RAG pipeline, and an over-permissioned AI agent are not hypothetical problems; they are the specific, documented ways real LLM applications get attacked in production today. This guide walks through every risk in the current 2025 list, in plain English, with the architecture, testing, and lifecycle practices that turn awareness into an actual defense.
TL;DR
The OWASP Top 10 for LLM Applications 2025 (v2.0) ranks the ten most critical AI application security risks, from prompt injection to unbounded consumption.
It is a voluntary awareness resource, not a certification, compliance standard, or complete security program.
Prompt injection has held the top spot since the project's 2023 origin because it enables many of the other nine risks.
Real attacks chain multiple risks together, so layered, defense-in-depth controls matter more than any single fix.
The list works best alongside NIST AI RMF, MITRE ATLAS, and existing OWASP frameworks like ASVS and API Security Top 10.
A separate, newer OWASP Top 10 for Agentic Applications (2026) complements this list for autonomous, tool-using agents.
What Is the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLM Applications is a community-ranked list of the ten most critical security risks in applications built on large language models. The current 2025 edition (v2.0), published 18 November 2024, runs from LLM01 Prompt Injection to LLM10 Unbounded Consumption and guides developers and security teams on prioritizing AI application defenses.
Table of Contents
What Is the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLM Applications is a community-built awareness resource that ranks the ten most critical security risks found in applications built on large language models. It is maintained by the OWASP GenAI Security Project, part of the same open-source cybersecurity community behind the original OWASP Top 10 for web applications. The current edition, published on 18 November 2024, uses the designations LLM01:2025 through LLM10:2025 and is commonly called version 2.0 (OWASP GenAI Security Project, 2024).
The resource is written for developers, AI engineers, application security teams, and business leaders who build or oversee any LLM application, from a simple chatbot to a complex, tool-using agent. Its scope covers the whole system around the model: prompts, retrieval pipelines, plugins, memory, and the infrastructure that connects them, not just the model weights themselves.
Its purpose is awareness, not certification. The list gives teams a shared vocabulary for prioritizing OWASP Top 10 for LLM Applications risks inside a broader secure-development program. It does not test, audit, or approve any product, and it is not a legal or regulatory standard. Treat it as a starting checklist for threat modeling, not a finish line.
Why LLM Applications Need Their Own Security Guidance
Traditional application security assumes a fixed set of inputs, deterministic logic, and a clear line between code and data. LLM applications break that assumption in several ways at once, which is why the existing OWASP Top 10 for web applications does not cover them well.
Probabilistic behavior. The same prompt can produce different outputs on different runs, so testing cannot rely on fixed expected values the way unit tests do.
Natural-language control surface. Instructions and untrusted content travel through the same channel, in machine learning systems that were never designed to separate the two.
Retrieval and tool use. RAG pipelines and function calling let a model pull in outside documents and take real actions, expanding the attack surface far past a single API call.
Autonomous agents. Agentic AI systems can plan multi-step tasks and call tools without a human reviewing every action, so one bad decision can cascade.
Untrusted content everywhere. Uploaded files, scraped web pages, and third-party API responses can all carry hidden instructions the model may follow.
Third-party models. Most teams consume a foundation model as a service or a downloaded checkpoint, inheriting supply-chain risk they cannot fully inspect.
High inference cost. Every model call consumes compute, so uncontrolled usage becomes a financial and availability problem, not just a security one.
Because of these differences, the OWASP GenAI Security Project built a separate, purpose-made list. It borrows the Top 10 format for familiarity but reworks the risk categories around how LLM applications actually get attacked in production.
How the OWASP LLM Top 10 Has Evolved
The project began in 2023 as a grassroots effort to catalogue prompt-injection and related risks that the original OWASP Top 10 did not address. That first list was useful but built quickly, and several categories overlapped in practice.
OWASP published a substantially reworked edition on 18 November 2024, branded the 2025 Top 10 (v2.0). The update added Vector and Embedding Weaknesses and split several overlapping 2023 categories, reordered risks based on community voting and real incident data, and rewrote each entry with clearer examples and mitigations (OWASP GenAI Security Project, 2024). Prompt injection kept the top spot in both editions.
The initiative now operates under the broader OWASP GenAI Security Project, which also covers generative AI and agentic AI security more widely. In December 2025, the project separately published the OWASP Top 10 for Agentic Applications (2026), also called the ASI Top 10, which addresses risks specific to autonomous, tool-using agents such as goal hijacking and cascading agent failures. That is a companion document, not a replacement: as of this writing, the OWASP Top 10 for LLM Applications 2025 (v2.0) remains the current, completed edition for LLM application risk, and this article follows it throughout. Teams building autonomous agents should read the two lists together.
The OWASP Top 10 for LLM Applications at a Glance
This table summarizes all ten risks in the current OWASP Top 10 for LLM Applications 2025 list. Each row is covered in full detail in the matching section below, with examples, impact, and layered mitigation.
ID | Risk | Plain-English Meaning | Typical Impact | Priority Controls |
|---|---|---|---|---|
LLM01 | Prompt Injection | Attacker text makes the model ignore its real instructions. | Data leaks, unauthorized actions, unsafe output. | Input segregation, least privilege, human approval for risky actions. |
LLM02 | Sensitive Information Disclosure | Model reveals private, secret, or proprietary data. | Privacy breach, IP loss, compliance exposure. | Data classification, output filtering, retrieval access control. |
LLM03 | Supply Chain | Vulnerable or malicious third-party models, data, or packages. | Backdoors, compromised deployments. | Provenance checks, SBOM/ML-BOM, vetted sources. |
LLM04 | Data and Model Poisoning | Training or fine-tuning data is manipulated. | Biased, backdoored, or unreliable model behavior. | Data vetting, anomaly detection, provenance tracking. |
LLM05 | Improper Output Handling | Model output is trusted and used without validation. | Injection, SSRF, remote code execution downstream. | Output encoding, schema validation, sandboxing. |
LLM06 | Excessive Agency | The system grants the model too much autonomy or permission. | Unauthorized transactions, destructive actions. | Per-tool authorization, human-in-the-loop, scoped permissions. |
LLM07 | System Prompt Leakage | Internal instructions are exposed to users. | Bypassed logic, exposed business rules. | Never store secrets in prompts, deterministic authorization. |
LLM08 | Vector and Embedding Weaknesses | Flaws in RAG retrieval and embedding pipelines. | Data leakage, tenant cross-contamination, poisoned context. | Retrieval-time access control, tenant isolation, document provenance. |
LLM09 | Misinformation | The model states false information convincingly. | Bad decisions, legal exposure, reputational harm. | Grounding, citation checks, human review of high-stakes output. |
LLM10 | Unbounded Consumption | Uncontrolled resource or cost usage. | Denial of wallet, service degradation. | Rate limits, quotas, timeouts, cost budgets. |
LLM01:2025 Prompt Injection
What It Means
Prompt injection happens when an attacker crafts input that causes the model to follow instructions the application never intended. In plain terms, the model cannot always tell the difference between the developer's trusted instructions and text that merely looks like instructions. Technically, this happens because LLMs process system prompts, developer instructions, and untrusted content in one shared context window, with no built-in mechanism to mark one part as more authoritative than another.
How the Risk Appears
Direct prompt injection occurs when a user types adversarial instructions straight into a chat box. Indirect prompt injection is more dangerous in practice: the malicious instructions sit inside a document, web page, email, or file that the application retrieves and feeds to the model automatically, so the end user never has to type anything unusual at all.
Realistic Example
Hypothetical example: a company deploys an AI assistant that summarizes incoming support emails. An attacker sends an email containing hidden text such as an instruction telling the assistant to forward all future messages to an external address. If the assistant treats email body text as trusted instructions rather than untrusted data, it could comply without any human noticing the hidden text.
Potential Impact
Successful prompt injection can expose confidential data, trigger unauthorized actions when the model has tool access, and damage user trust once discovered. The severity scales directly with how much agency and data access the connected application grants the model.
Prevention and Mitigation
Preventive: Treat all retrieved and user-supplied content as untrusted data, never as instructions; enforce strict input and output schemas.
Architectural: Keep system instructions and untrusted content in clearly separated channels where the underlying model API supports it.
Operational: Apply least privilege to any tool or API the model can call, so a successful injection has limited blast radius.
Human approval: Require human confirmation before the model executes high-impact actions such as payments, deletions, or external communications.
Testing and Detection
Run adversarial red-team prompts against every input channel, including files and retrieved documents, not just the chat box. Log model inputs and outputs so unusual instruction-following patterns can be reviewed after the fact.
Who Should Own the Controls
Application security and AI engineering teams own the architecture; product teams must approve which actions require human sign-off.
Quick Checklist
Untrusted content is never concatenated directly into privileged instructions.
Tool access follows least privilege per use case.
High-impact actions require human approval.
Adversarial and indirect-injection tests run before every release.
LLM02:2025 Sensitive Information Disclosure
What It Means
This risk covers any case where an LLM application reveals personal data, credentials, internal business information, or proprietary content that it should not expose, either through model training, its system prompt, or documents it retrieves.
How the Risk Appears
Disclosure can happen when a model memorizes rare training examples and regurgitates them, when a RAG pipeline retrieves a document the current user should not see, or when developers accidentally paste API keys or internal notes into a prompt that a user can later coax the model to repeat.
Realistic Example
A documented case, CVE-2025-68665, involved a serialization-injection flaw in the LangChain framework that allowed extraction of secrets through crafted inputs, illustrating how a framework-level bug can turn into real sensitive-information disclosure in production LLM applications.
Potential Impact
Confidentiality and privacy are the primary concerns, but the legal and regulatory exposure can be just as significant under data-protection laws, alongside reputational damage and loss of competitive advantage if trade secrets leak.
Prevention and Mitigation
Preventive: Classify data before it ever reaches a prompt or a vector store, and exclude regulated data classes from training and fine-tuning where possible.
Architectural: Enforce retrieval-time access control so a query only returns documents the requesting user is authorized to see.
Detective: Scan model output for patterns that match secrets, PII, or classification markers before it reaches the user.
Operational: Rotate and vault any credentials that ever touched a prompt, and never store production secrets in prompt text.
Testing and Detection
Run targeted extraction tests that probe for memorized training data and cross-tenant leakage. Monitor output logs for regex matches on common secret formats and personal-data patterns.
Who Should Own the Controls
Data governance and privacy teams set classification rules; application security and platform teams implement retrieval-time enforcement.
Quick Checklist
Data classification applied before ingestion into prompts or vector stores.
Retrieval enforces per-user or per-tenant authorization.
Output scanning for secrets and PII is active in production.
No production credentials are ever hard-coded into prompt text.
LLM03:2025 Supply Chain
What It Means
LLM applications depend on a long chain of third-party components: pre-trained models, fine-tuning datasets, open-source libraries, plugins, and hosted inference APIs. Supply-chain risk is the danger that any link in that chain is vulnerable, tampered with, or outright malicious.
How the Risk Appears
A downloaded model checkpoint can carry a hidden backdoor. A popular orchestration library can ship a vulnerable dependency. A dataset scraped from the open web can contain adversarial samples planted specifically to be picked up by model trainers.
Realistic Example
CVE-2026-54499 documented a remote-code-execution issue triggered by loading an untrusted Stanza model through unsafe pickle deserialization, a concrete example of how model-loading code itself can become the attack vector, independent of the model's intended behavior.
Potential Impact
Impact ranges from remote code execution and full system compromise to subtler integrity issues, where a poisoned or backdoored component behaves normally until a specific trigger activates malicious behavior.
Prevention and Mitigation
Preventive: Maintain a model and dataset inventory (an AI-BOM) and only load models and packages from vetted, signed sources.
Architectural: Use safe serialization formats instead of formats like pickle that allow arbitrary code execution during loading.
Detective: Scan dependencies continuously for known vulnerabilities using SBOM-based tooling.
Responsive: Maintain a rollback plan for any model or library version that is later found compromised.
Testing and Detection
Verify cryptographic signatures and provenance metadata before deploying any third-party model. Include dependency and model-loading code in every security regression test suite.
Who Should Own the Controls
Platform and DevOps teams manage the inventory and pipelines; AI/ML engineers vet model and dataset sources before adoption.
Quick Checklist
An up-to-date model and dataset inventory exists.
Only signed, provenance-verified models and packages are loaded.
Serialization formats prevent arbitrary code execution.
Dependency scanning runs on every build.
LLM04:2025 Data and Model Poisoning
What It Means
Poisoning is the deliberate manipulation of training, fine-tuning, or embedding data so the resulting model behaves in a way the attacker wants, whether that is a subtle bias, a hidden backdoor triggered by a specific phrase, or generally degraded reliability.
How the Risk Appears
This risk grows wherever a model or its embeddings are trained or updated on data an attacker can influence, including public web scrapes, user-submitted feedback used for fine-tuning, or a shared vector store that accepts documents from multiple untrusted contributors.
Realistic Example
Hypothetical example: a customer support model is periodically fine-tuned on chat transcripts. If an attacker floods the chat channel with conversations designed to teach the model that a specific phrase authorizes account changes, the next fine-tuning cycle could bake that backdoor into the model's behavior.
Potential Impact
Poisoning threatens the integrity and safety of every downstream decision the model makes, and because the effect can be narrow and hard to detect through normal testing, it can persist undetected for a long time.
Prevention and Mitigation
Preventive: Vet and version every training and fine-tuning dataset; track provenance for each data source.
Detective: Run anomaly detection on training data distributions before each fine-tuning cycle.
Architectural: Isolate any user-contributed data used for training from data used for production inference.
Operational: Maintain versioned model artifacts so a poisoned version can be rolled back quickly once identified.
Testing and Detection
Use held-out evaluation datasets that specifically probe for backdoor trigger phrases and biased outputs. Compare model behavior across fine-tuning versions to catch unexpected behavioral drift.
Who Should Own the Controls
AI/ML engineering owns dataset vetting and training pipeline security; security teams support anomaly detection tooling.
Quick Checklist
Every training and fine-tuning dataset has documented provenance.
Anomaly detection runs before data is used for fine-tuning.
Model versions are tracked and rollback-ready.
Held-out tests specifically probe for poisoning triggers.
LLM05:2025 Improper Output Handling
What It Means
Improper output handling is what happens when an application passes an LLM's response straight into a downstream system, such as a database, shell, browser, or another API, without validating or sanitizing it first, exactly as it would validate any other untrusted input.
How the Risk Appears
Because model output looks like ordinary text, it is easy to forget that it can contain SQL fragments, script tags, shell commands, or crafted URLs. If that output reaches a database query, a web page, or a server-side request without checks, classic vulnerabilities resurface with an AI in front of them.
Realistic Example
A documented case, CVE-2023-32786, involved a server-side request forgery issue in the LangChain framework, where model-influenced output could cause the application to make unintended internal network requests.
Potential Impact
Consequences mirror classic web vulnerabilities: injection, server-side request forgery, cross-site scripting, or even remote code execution, depending on what system receives the unsanitized output.
Prevention and Mitigation
Preventive: Treat every LLM output as untrusted input to whatever system receives it next.
Architectural: Use parameterized queries, contextual output encoding, and schema-constrained output formats wherever the model's response drives an action.
Operational: Sandbox any code execution derived from model output; never execute it directly on production systems.
Detective: Log and alert on outputs that fail validation before reaching a downstream system.
Testing and Detection
Run output-validation test suites that feed adversarial completions into every downstream integration point to confirm sanitization holds under attack.
Who Should Own the Controls
Application developers own output handling code; application security teams review it as part of standard secure code review.
Quick Checklist
Model output is never passed to a database, shell, or browser unsanitized.
Schema-constrained output is used wherever structured data is expected.
Any code execution derived from output runs in a sandbox.
Downstream integrations are covered by dedicated output-validation tests.
LLM06:2025 Excessive Agency
What It Means
Excessive agency is what happens when an LLM-based system is granted more functionality, permissions, or autonomy than its actual task requires, so that if the model is manipulated or simply makes a mistake, it can take far more damaging action than necessary.
How the Risk Appears
This risk grows with three factors: excessive functionality, meaning the agent has tools it does not need; excessive permissions, meaning a tool has broader access than the task requires; and excessive autonomy, meaning the agent acts without human review. Ordinary tool use becomes excessive agency only when any of these three exceed what the task genuinely needs.
Realistic Example
Hypothetical example: an internal AI assistant is given a general-purpose database-admin credential to answer read-only reporting questions. If the assistant is later manipulated through prompt injection, that same broad credential could be used to modify or delete records, far beyond the reporting task it was built for.
Potential Impact
Because agency multiplies the effect of every other risk on this list, the potential impact spans financial loss, data integrity damage, and safety concerns whenever the connected tools control real-world systems.
Prevention and Mitigation
Preventive: Grant each tool the minimum scope needed for its specific task, never a general-purpose credential.
Architectural: Require complete mediation, meaning every tool call is checked for authorization every time, not just once at session start.
Human approval: Route high-impact or irreversible actions through a human approval gate before execution.
Operational: Log every tool call with enough context to reconstruct exactly what the agent did and why.
Testing and Detection
Run tool-authorization tests that attempt to use each connected tool outside its intended scope, confirming the system blocks out-of-scope calls.
Who Should Own the Controls
Security architects define permission boundaries; product managers decide which actions require human approval gates.
Quick Checklist
Every tool credential is scoped to its minimum necessary permission.
High-impact actions require human approval before execution.
Tool calls are authorized on every single invocation.
Tool-authorization tests run before every release.
LLM07:2025 System Prompt Leakage
What It Means
System prompt leakage occurs when the internal instructions that shape a model's behavior become visible to end users, whether through direct extraction techniques or accidental disclosure in error messages and debugging output.
How the Risk Appears
Users can often coax a model into revealing its system prompt simply by asking it to, summarizing its instructions, or exploiting formatting quirks. The real risk is not the leak itself but what the leaked prompt reveals or enables.
Realistic Example
Hypothetical example: a system prompt embeds a discount-authorization rule to keep the model's behavior consistent. Once a user extracts that rule, they can reliably word requests to trigger the exact condition needed to unlock the discount, effectively bypassing business logic that lived only in the prompt.
Potential Impact
The direct impact is limited unless the system prompt contains secrets, credentials, or unpublished business rules, in which case leakage can lead to bypassed authorization logic and reputational embarrassment.
Prevention and Mitigation
Preventive: Never place secrets, credentials, or authoritative access-control rules inside a system prompt.
Architectural: Enforce authorization decisions in deterministic backend code, not in prompt text the model merely reads.
Detective: Monitor for prompts that closely mirror internal wording, as a signal that a system prompt has already leaked.
Operational: Treat the system prompt as public-facing content from a design standpoint, even though it is not displayed by default.
Testing and Detection
Run extraction-style tests that attempt to retrieve the system prompt through direct requests, formatting tricks, and multi-turn conversation, and confirm no exploitable business logic is exposed even if extraction succeeds.
Who Should Own the Controls
Application developers and security architects share ownership, since this control sits at the boundary between prompt design and backend authorization.
Quick Checklist
No secrets or credentials live inside any system prompt.
Authorization decisions are enforced in backend code, not prompt text.
Extraction tests run against the current system prompt regularly.
The team assumes the prompt could become public at any time.
LLM08:2025 Vector and Embedding Weaknesses
What It Means
This risk covers flaws in how a RAG pipeline generates, stores, and retrieves embeddings, the numerical representations of text used to find relevant documents. Weaknesses here can leak data across tenants, poison retrieved context, or return manipulated documents that steer the model's output.
How the Risk Appears
Vector databases that lack per-tenant isolation can return one customer's documents to another customer's query. Attackers can also craft documents specifically designed to score highly in similarity search, injecting their content into the model's context regardless of genuine relevance.
Realistic Example
Hypothetical example: a multi-tenant support platform stores all customers' documents in a single shared vector index without tenant filters. A retrieval bug that omits the tenant filter on one query type could surface another customer's confidential documents inside an unrelated customer's chat session.
Potential Impact
Confidentiality is the primary concern through cross-tenant data exposure, alongside integrity risk when poisoned or manipulated documents are retrieved and treated as trustworthy context by the model.
Prevention and Mitigation
Preventive: Enforce tenant isolation at the retrieval layer, not just at the application layer.
Architectural: Apply retrieval-time access control so a query can only return documents the requesting identity is authorized to see.
Detective: Track document provenance and flag documents from unverified or low-trust sources before they enter the index.
Operational: Re-index and re-validate the corpus periodically to catch documents that should no longer be retrievable.
Testing and Detection
Run dedicated tenant-isolation tests and RAG corpus tests that attempt cross-tenant retrieval and adversarial document injection into the vector store.
Who Should Own the Controls
Platform and data engineering teams own the vector database architecture; application security validates isolation boundaries.
Quick Checklist
Tenant isolation is enforced at the retrieval query level.
Document provenance is tracked for everything in the vector store.
Corpus content is periodically re-validated.
Cross-tenant retrieval tests run before every release.
LLM09:2025 Misinformation
What It Means
Misinformation covers cases where an LLM produces false or misleading information that is stated with enough confidence that users reasonably believe it, whether the cause is a general hallucination or a specific failure in a RAG retrieval step.
How the Risk Appears
General hallucination happens when the model generates plausible-sounding but unsupported claims from its own parameters. RAG retrieval errors are a distinct, narrower failure: the pipeline retrieves the wrong document, an outdated document, or misinterprets a correct document, and the model then states the resulting error confidently.
Realistic Example
Hypothetical example: a legal-research assistant retrieves an outdated version of a regulation because the vector index was never refreshed, then confidently summarizes the outdated rule as current guidance, without any indication to the user that the source may be stale.
Potential Impact
Impact depends heavily on the domain: in low-stakes settings misinformation is an inconvenience, but in legal, medical, or financial contexts it can drive genuinely harmful decisions and create legal or regulatory exposure for the deploying organization.
Prevention and Mitigation
Preventive: Ground high-stakes responses in verified, current source documents rather than relying on the model's parametric memory.
Detective: Require citations for factual claims and check that cited sources actually support the stated claim.
Human approval: Route high-stakes outputs, such as legal or medical guidance, through human review before they reach end users.
Operational: Refresh retrieval indexes on a defined schedule so RAG retrieval errors from stale data become less likely.
Testing and Detection
Build evaluation datasets of known-answer questions in the application's domain and measure how often the model's answer disagrees with the verified answer, tracking this metric over time as a regression indicator.
Who Should Own the Controls
Product and subject-matter teams define acceptable accuracy thresholds; AI engineering implements grounding and citation-checking mechanisms.
Quick Checklist
High-stakes answers are grounded in verified, current sources.
Citations are required and spot-checked against source content.
Human review covers legal, medical, or financial outputs.
Retrieval indexes are refreshed on a defined schedule.
LLM10:2025 Unbounded Consumption
What It Means
Unbounded consumption is the risk that an LLM application allows uncontrolled resource use, whether that is compute, API calls, or cost, to the point of financial harm or service degradation. The community shorthand for the financial version of this risk is denial of wallet.
How the Risk Appears
This risk grows wherever request volume, output length, or the number of chained tool calls has no ceiling. Agentic systems are particularly exposed because a single triggered task can spawn a long, looping sequence of expensive model calls with no natural stopping point.
Realistic Example
Hypothetical example: an autonomous research agent is asked to keep refining a report until it is satisfied with the result. Without a hard iteration limit, a poorly specified stopping condition could cause the agent to loop for hours, running up a large inference bill before anyone notices.
Potential Impact
The most direct impact is financial cost, but availability suffers too, since a runaway process can exhaust shared compute quota and degrade service for every other user of the same platform.
Prevention and Mitigation
Preventive: Set hard rate limits, token quotas, and cost budgets per user, per session, and per tenant.
Architectural: Enforce timeouts and queue limits so no single request or agent loop can run indefinitely.
Detective: Monitor usage in real time and alert on anomalous spikes in request volume or cost.
Responsive: Build graceful degradation so the system throttles or pauses rather than failing completely under load.
Testing and Detection
Run cost and resource-abuse tests that deliberately try to trigger long loops, oversized outputs, or high-frequency requests, and confirm the configured limits actually trigger.
Who Should Own the Controls
Platform and DevOps teams implement and monitor rate limits and quotas; security and risk leaders set the acceptable cost thresholds.
Quick Checklist
Rate limits and token quotas are enforced per user and per tenant.
Hard timeouts exist on every model call and agent loop.
Real-time cost and usage monitoring is active.
Cost-abuse tests run before every release involving agentic workflows.
How OWASP LLM Risks Combine Into Attack Chains
Real incidents rarely involve a single risk in isolation; they usually chain several together. Understanding these chains helps defenders see why layered controls matter more than any single mitigation.
Consider a defensive, non-weaponized walkthrough: an attacker embeds hidden instructions inside a public web page that a company's research assistant is likely to retrieve, an LLM01 indirect prompt injection. If the assistant has been granted broad tool access beyond what its task requires, LLM06 excessive agency, the injected instructions could direct it to call an internal API it should not use. If that API's response is then passed to another system without validation, LLM05 improper output handling, the chain can end with unauthorized data exposure, LLM02 sensitive information disclosure, all triggered by a single poisoned web page.
Similarly, weaknesses in a vector database's tenant isolation, LLM08, can combine with insufficient output review to turn a routine RAG query into a cross-customer data leak. No single OWASP LLM Top 10 control fully closes a chain like this; defense in depth, where several independent layers each reduce likelihood or impact, is what actually breaks the chain.
Secure Architecture and Threat Modeling for LLM Applications
Threat modeling an LLM application starts with mapping every component and the trust boundaries between them. System prompts, retrieved documents, uploaded files, tool results, and third-party API responses should all be treated as crossing a trust boundary the moment they reach the model.
User interfaces where end users submit prompts, files, or other input.
Application backend that assembles prompts, applies business logic, and enforces authorization.
System and developer instructions, which must never be treated as a reliable authorization boundary on their own.
Model APIs, whether hosted by a third party or self-managed.
RAG pipelines, including document ingestion, embedding generation, and the vector database itself.
Tool and function calls, plus the agent orchestration layer that sequences them.
Memory systems that persist information across sessions.
Identity and access management, secrets management, and monitoring and audit logs.
Human approval gates for high-impact actions.
External APIs, plugins, and the broader model and dataset supply chain.
A simple data-flow example: a user question enters the application backend, which retrieves relevant documents from the vector database, assembles a prompt combining the system instructions with the retrieved content and the user's question, sends that prompt to the model API, and passes the model's response through output validation before it reaches a tool call or the end user. Every arrow in that flow is a trust boundary that deserves its own control.
Implementing the OWASP LLM Top 10 Across the Development Lifecycle
The OWASP Top 10 for LLM Applications works best when it is woven into every phase of delivery, not bolted on at the end.
Discovery and requirements: identify what data the application will touch and what actions it will be allowed to take.
Architecture and threat modeling: map trust boundaries and assign a specific OWASP risk category to each one.
Vendor and model selection: vet foundation model providers and any third-party components against supply-chain criteria.
Data collection and preparation: classify data and vet sources before they reach training, fine-tuning, or a vector store.
Development: apply least privilege to every tool, and validate every output before it reaches a downstream system.
Pre-production testing: run adversarial, red-team, and tenant-isolation tests against a realistic staging environment.
Deployment: enable rate limits, quotas, and monitoring before the first real user request.
Runtime monitoring: watch for anomalous tool use, cost spikes, and output-validation failures continuously.
Incident response: have a defined playbook for prompt-injection incidents, data leaks, and cost-abuse events.
Periodic reassessment: revisit the threat model whenever the application gains new tools, data sources, or autonomy.
Testing LLM Applications Against the Top 10
Effective testing combines several distinct techniques, because no single method catches every risk category on this list.
Abuse-case development: write out how each risk category could realistically be triggered in this specific application before writing test cases.
Adversarial testing and red teaming: have testers actively try to break prompt boundaries, tool restrictions, and output validation.
Direct and indirect prompt-injection testing: cover both typed attacks and hidden instructions embedded in retrieved content.
RAG corpus testing: verify retrieval returns only authorized, relevant, and current documents.
Tenant-isolation and tool-authorization testing: confirm one user's session cannot reach another tenant's data or an out-of-scope tool.
Output validation testing: feed adversarial completions into every downstream integration point.
Cost and resource-abuse testing: deliberately try to trigger runaway loops or oversized requests.
Model and dependency provenance checks: verify signatures and sources before deployment.
Regression test suites and logging: keep every test reproducible with full logging of inputs, outputs, and tool calls.
Automated LLM-as-a-judge evaluations are useful for scale, but they have limits: a judge model can share the same blind spots as the model being tested, and it cannot reliably catch novel attack patterns it has never seen. Critical findings, especially anything touching security boundaries or high-stakes decisions, still require deterministic checks or human validation before a team can call an application secure.
Practical Security Checklist by Role
Different roles own different pieces of OWASP Top 10 for LLM Applications coverage. This concise breakdown helps teams divide the work without leaving gaps.
Developers: validate all output before it reaches a downstream system; never hard-code secrets into prompts.
AI/ML engineers: vet training data and third-party models; track dataset and model provenance.
Application security teams: run adversarial and tenant-isolation tests; review tool authorization boundaries.
Platform and DevOps teams: enforce rate limits, quotas, and monitoring; maintain the model and dependency inventory.
Product managers: decide which actions require human approval gates; set acceptable accuracy thresholds for the domain.
Security and risk leaders: align LLM risk management with existing governance frameworks and set incident response ownership.
Common Misconceptions About the OWASP LLM Top 10
"A strong system prompt prevents prompt injection."
A system prompt is a suggestion the model usually follows, not an enforced security boundary. Any content the model reads can potentially override or confuse those instructions, so real authorization must live in deterministic backend code, not prompt wording.
"RAG eliminates hallucinations."
Retrieval reduces certain kinds of hallucination by grounding answers in real documents, but it introduces its own failure mode: retrieval errors, where the wrong or outdated document is retrieved and then confidently misreported.
"The model provider secures the whole application."
A foundation model provider secures the model itself, not the prompts, tools, data pipelines, or business logic a team builds around it. Application-level security remains the deploying organization's responsibility.
"Private models cannot leak information."
A self-hosted or private model still trains on data, still retrieves documents, and still connects to tools. Every OWASP LLM Top 10 risk category can apply to a private deployment exactly as it can to a public API-based one.
"An AI safety policy is the same as application security."
Safety alignment shapes what a model is willing to say; application security shapes what the surrounding system is able to do. A well-aligned model behind a poorly secured application is still an insecure application.
"Passing a one-time red-team exercise proves the system is secure."
Models, prompts, and connected tools change constantly. A single red-team snapshot only reflects the system as it existed on that day; continuous testing is required as the application evolves.
"The OWASP list is a certification or compliance standard."
The OWASP Top 10 for LLM Applications is a voluntary, community-authored awareness resource. It has no legal status by itself and does not certify or guarantee the security of any product.
"Blocking a few known prompt phrases solves prompt injection."
Keyword or regex-based filters can be trivially rephrased around. Prompt injection is a structural problem in how instructions and data share a channel, and it requires architectural controls, not a denylist.
How the OWASP LLM Top 10 Relates to Other Frameworks
The OWASP Top 10 for LLM Applications works best alongside other established frameworks, not instead of them.
NIST AI Risk Management Framework: provides a broader governance structure, Govern, Map, Measure, Manage, that OWASP's specific risk categories can slot into.
NIST Generative AI Profile: adds generative-AI-specific guidance that complements OWASP's technical risk detail with governance actions.
MITRE ATLAS: catalogs real-world adversarial tactics and techniques against AI systems, useful for red-team scenario design alongside the OWASP categories.
OWASP ASVS: the Application Security Verification Standard still applies to the conventional web and API layers of an LLM application.
OWASP API Security Top 10: relevant wherever an LLM application exposes or calls APIs, which is nearly always.
OWASP CycloneDX and AI-BOM efforts: support the model and dataset inventory work that LLM03 supply-chain mitigation depends on.
Organizations should map OWASP LLM Top 10 categories onto their existing secure-development and risk-management processes rather than running a separate, disconnected AI security program.
FAQ
What is the latest OWASP Top 10 for LLM Applications?
The latest completed edition is the OWASP Top 10 for LLM Applications 2025, version 2.0, published on 18 November 2024 by the OWASP GenAI Security Project. It runs from LLM01:2025 Prompt Injection through LLM10:2025 Unbounded Consumption and remains current as of this writing.
Is the OWASP LLM Top 10 a compliance standard?
No. It is a voluntary, community-authored awareness resource with no legal or regulatory status by itself. Organizations can use it to inform compliance programs, but passing an internal review against the list does not itself satisfy any law or certification.
How is the OWASP LLM Top 10 different from the regular OWASP Top 10?
The original OWASP Top 10 covers classic web application vulnerabilities like injection and broken access control. The LLM Top 10 addresses risks unique to AI systems, such as prompt injection and vector database weaknesses, that arise from probabilistic, natural-language-driven behavior.
What is the most important LLM security risk?
Prompt injection, LLM01:2025, has held the top spot in both the 2023 and 2025 editions because it is structurally difficult to fully prevent and can enable many of the other nine risks once an attacker succeeds.
Can prompt injection be completely prevented?
No current technique eliminates prompt injection entirely, because instructions and data share the same channel. Layered controls, such as least privilege, human approval for risky actions, and strict output validation, reduce likelihood and limit impact rather than guaranteeing prevention.
Does RAG prevent hallucinations?
RAG reduces some hallucinations by grounding answers in retrieved documents, but it introduces retrieval errors as a new failure mode. A RAG system can still state false information confidently if it retrieves the wrong or outdated document.
What is excessive agency in an AI agent?
Excessive agency means an agent has more functionality, permissions, or autonomy than its task requires. It differs from ordinary tool use because the extra scope creates disproportionate risk if the agent is manipulated or makes an error.
Is exposing a system prompt always a security breach?
Not automatically. If the system prompt contains no secrets or exploitable business logic, leakage is a minor issue. It becomes serious only when the prompt reveals credentials, internal rules, or information that helps an attacker bypass controls.
How often should an LLM application be security tested?
Testing should happen before every meaningful release, whenever new tools or data sources are added, and on a recurring schedule even without changes, since models and connected services evolve independently of the application's own code.
Who is responsible for securing an LLM application?
Responsibility is shared: developers and AI engineers build secure code and vet data; security teams test and monitor; product and leadership define acceptable risk. No single role or vendor secures the entire system alone.
Does using a private or self-hosted model eliminate these risks?
No. A private model still faces prompt injection, data poisoning, supply-chain risk, and every other OWASP LLM Top 10 category. Hosting a model privately changes who controls the infrastructure, not whether these risks exist.
How should a small organization begin implementing the list?
Start with a lightweight threat model of the application's actual data and tool access, apply least privilege to every tool connection, validate all model output before use, and add rate limits and monitoring before scaling usage.
Key Takeaways
The OWASP Top 10 for LLM Applications 2025 (v2.0) is the current, community-authored baseline for AI application security risk.
Defense in depth matters more than any single control, since real incidents chain multiple risks together.
Trust boundaries exist wherever untrusted content, files, or tool results reach the model, and each one needs explicit controls.
Least privilege applies to every tool and API connection, not just to human user accounts.
Authorization must be enforced in deterministic backend code, never inside a system prompt.
Secure RAG requires retrieval-time access control and tenant isolation, not just application-layer checks.
Safe tool use depends on complete mediation, checking authorization on every call, not only at session start.
Continuous testing, not a one-time red-team exercise, is required as models and connected tools change.
Monitoring and incident response for cost, data leakage, and tool misuse are as essential as preventive controls.
Securing an LLM application is a shared responsibility across engineering, security, product, and leadership, and the Top 10 is a starting checklist, not a complete security program.
Actionable Next Steps
Inventory every LLM application in use, along with its data sources, connected tools, and model providers.
Threat model each application against all ten OWASP LLM Top 10 categories, mapping trust boundaries explicitly.
Redesign architecture so system prompts never carry secrets and authorization always lives in backend code.
Apply least privilege to every tool credential and API connection the model can invoke.
Classify data feeding into prompts, fine-tuning, and vector stores before it is ingested.
Harden RAG pipelines with retrieval-time access control and tenant isolation.
Add human approval gates for any high-impact or irreversible action a model-driven system can take.
Build a test suite covering prompt injection, tenant isolation, output validation, and cost abuse.
Deploy runtime monitoring for anomalous tool use, cost spikes, and output-validation failures.
Write an incident response playbook specific to prompt-injection, data-leak, and cost-abuse scenarios.
Assign clear ownership across developers, AI engineers, security, and product for each risk category.
Reassess on a fixed schedule and whenever the application gains new tools, data sources, or autonomy.
Glossary
Agent: a system that uses an LLM to plan and execute multi-step tasks, often by calling external tools.
AI-BOM: an AI bill of materials, an inventory of the models, datasets, and components used to build an AI system.
Alignment: the degree to which a model's behavior matches its intended goals and safety guidelines.
Context window: the amount of text a model can process at once, including instructions, retrieved content, and conversation history.
Denial of wallet: an attack or failure that runs up excessive cost through uncontrolled resource consumption.
Embedding: a numerical representation of text used to measure similarity between pieces of content.
Foundation model: a large, general-purpose model trained on broad data, later adapted for specific applications.
Function calling: a mechanism that lets a model request that the application execute a specific action or tool.
Guardrail: a control designed to keep model behavior within acceptable bounds, distinct from a deterministic security enforcement mechanism.
Hallucination: confident model output that is factually incorrect or unsupported by real evidence.
Human in the loop: a design pattern requiring human review or approval before a system takes a specific action.
Inference: the process of running a trained model to generate a response to a given input.
Jailbreak: a technique used to make a model bypass its safety training or intended behavioral restrictions.
Large language model (LLM): a machine learning model trained on large volumes of text to generate and understand natural language.
Least privilege: the principle of granting only the minimum access needed to perform a specific task.
LLM application: the full system built around a model, including prompts, data pipelines, and connected tools.
ML-BOM: a machine learning bill of materials, tracking the components specific to a model's training and deployment.
Model poisoning: deliberate manipulation of training or fine-tuning data to alter a model's behavior.
Prompt injection: an attack that causes a model to follow unintended instructions embedded in input or retrieved content.
RAG (retrieval-augmented generation): a technique that retrieves relevant documents and supplies them to a model as context before it generates a response.
Red teaming: structured adversarial testing intended to find security or safety weaknesses before attackers do.
Retrieval: the process of finding and returning the most relevant documents for a given query.
SBOM: a software bill of materials, an inventory of the components used to build a piece of software.
System prompt: the initial instructions given to a model to define its role, behavior, and constraints for a session.
Token: a unit of text, roughly a word or part of a word, that a model processes and generates.
Tool: an external function, API, or service that an LLM application can invoke on the model's behalf.
Trust boundary: a point where data or control passes between components with different levels of trust.
Vector database: a data store optimized for searching content by embedding similarity rather than exact keyword match.
Sources & References
OWASP GenAI Security Project. "OWASP Top 10 for LLM Applications 2025 (v2.0)." Published 18 November 2024. https://genai.owasp.org/llm-top-10/
OWASP GenAI Security Project. "OWASP Reveals Updated 2025 Top 10 Risks for LLMs." 19 November 2024. https://genai.owasp.org/2024/11/17/owasp-reveals-2025-top-10-risks-for-llms-new-sponsorship-program/
OWASP GenAI Security Project. "Top 10 for LLM and GenAI Initiative." Accessed 2026. https://genai.owasp.org/initiatives/top-10-for-llm-and-genai/
OWASP Foundation. "OWASP Top 10 for Large Language Model Applications." Accessed 2026. https://owasp.org/www-project-top-10-for-large-language-model-applications/
OWASP Foundation. "OWASP Top 10 for LLM Applications v2.0 (PDF)." Published 2024. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
OWASP GenAI Security Project. "OWASP Top 10 for Agentic Applications (2026)." Published December 2025. https://genai.owasp.org/
National Institute of Standards and Technology. "AI Risk Management Framework (AI RMF 1.0)." Published January 2023. https://www.nist.gov/itl/ai-risk-management-framework
National Institute of Standards and Technology. "NIST AI 600-1: Generative AI Profile." Published July 2024. https://www.nist.gov/itl/ai-risk-management-framework
MITRE. "MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems." Accessed 2026. https://atlas.mitre.org/
OWASP Foundation. "OWASP Application Security Verification Standard (ASVS)." Accessed 2026. https://owasp.org/www-project-application-security-verification-standard/
OWASP Foundation. "OWASP API Security Top 10." Accessed 2026. https://owasp.org/www-project-api-security/
OWASP Foundation. "OWASP CycloneDX." Accessed 2026. https://cyclonedx.org/
Kodem Security. "OWASP Top 10 for LLM Applications (2025)." Accessed 2026. https://www.kodemsecurity.com/resources/owasp-top-10-for-llm-applications
Security Boulevard / Aembit. "The OWASP Top 10 for LLM Applications (2025): Explained Simply." Published 21 March 2026. https://securityboulevard.com/2026/03/the-owasp-top-10-for-llm-applications-2025-explained-simply/
MEXC News. "Why CISOs care: securing the agentic AI attack surface." Published 2026. https://www.mexc.com/news/509354