OWASP LLM Top 10: Key Takeaways
- The OWASP Top 10 for LLM Applications is an OWASP GenAI Security Project awareness framework that explains ten major security risks in LLM-powered applications and provides guidance for recognizing and mitigating them. The official 2023 edition covers prompt injection, insecure output handling, training data poisoning, model denial of service, supply-chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft.
- For prompt injection: separate instructions from data, constrain context, validate actions, and require approval for sensitive operations.
- For sensitive information disclosure: enforce data classification and access controls, redact sensitive data, and filter outputs.
- For supply-chain and poisoning risks: verify model, package, dataset, and vector-store provenance; version and monitor artifacts.
- For improper output handling: treat model output as untrusted input, validate and sanitize it, and sandbox execution.
The OWASP Top 10 for LLM Applications is an OWASP GenAI Security Project awareness framework that explains ten major security risks in LLM-powered applications and provides guidance for recognizing and mitigating them.
The 2023 OWASP edition covers applications using retrieval-augmented generation (RAG), vector stores, tools, plugins, integrations, memory, or agents. It is an awareness and security framework—not a model-performance ranking, a security guarantee, or a universal compliance standard.
What Is the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLM Applications helps developers, architects, and security teams identify common risks in applications built with large language models. It focuses on the application surrounding the model, including its prompts, data sources, retrieval layer, tools, downstream systems, and permissions.
The list is a practical risk-management aid, not proof that an application is secure. Teams still need architecture-specific authorization, testing, monitoring, logging, and governance.
Edition and Terminology Note
Official 2023 edition
The official 2023 OWASP Top 10 for LLM Applications uses the identifiers LLM01 through LLM10 consistently. Its categories are Prompt Injection, Insecure Output Handling, Training Data Poisoning, Model Denial of Service, Supply Chain Vulnerabilities, Sensitive Information Disclosure, Insecure Plugin Design, Excessive Agency, Overreliance, and Model Theft.
Why the edition matters
Third-party explanations may refer to later editions or claimed 2026 changes. The official 2023 categories provide the reference point, while later revision details may differ. Labels can also vary between editions, so later-style categories such as system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption are separate from the 2023 categories and should be treated accordingly.
The Ten OWASP LLM Application Risks
The 2023 sequence presents structured risk areas for reviewing an LLM application rather than a universal ranking of every AI security risk.
| Identifier and label | What it means | Example | Primary mitigations |
|---|---|---|---|
| LLM01: Prompt Injection | Direct or indirect input manipulates the model’s intended instructions or behavior. External webpages, documents, emails, or API responses may enter the model’s context. | Untrusted content retrieved by a RAG system influences how the application interprets instructions or performs a task. | Separate instructions from data, constrain context, validate proposed actions, limit permissions, and require approval for sensitive operations. |
| LLM02: Insecure Output Handling | Generated text or code is passed to a downstream system without sufficient validation, filtering, sanitization, or containment. | Model output reaches an API, database, browser, interpreter, or workflow without being checked for safe and appropriate use. | Treat model output as untrusted input. Validate its format and content, sanitize it, filter unsafe results, sandbox processing, and contain downstream actions. |
| LLM03: Training Data Poisoning | Training, fine-tuning, retrieval, embedding, or related data is tampered with in ways that introduce unwanted or malicious behavior. | Poisoned content enters an indexed knowledge base and affects later retrievals or generated answers. | Check data and model provenance, control who can modify training and retrieval sources, version artifacts, validate changes, and monitor behavior after updates. |
| LLM04: Model Denial of Service | Resource-intensive inputs or repeated model requests consume disproportionate compute, capacity, or budget and affect availability. | A service accepts uncontrolled request volume or unusually expensive workflows, causing capacity or cost problems. | Authenticate endpoints, apply rate limits and token or usage quotas, set workload boundaries, monitor consumption, log unusual activity, and alert on abnormal costs or volume. |
| LLM05: Supply Chain Vulnerabilities | Risk enters through models, datasets, adapters, repositories, tools, conversion pipelines, or other third-party artifacts. | An application incorporates a model, package, dataset, or tool whose provenance and integrity have not been adequately assessed. | Verify artifact provenance, assess dependencies, maintain version records, use trusted sources, and monitor models, packages, datasets, and tools over time. |
| LLM06: Sensitive Information Disclosure | The application exposes private, confidential, proprietary, or otherwise sensitive information through responses or connected components. | A response, prompt, log, embedding, or tool argument reveals information the requesting user is not authorized to access. | Classify sensitive data, enforce authorization and entitlement checks, redact or mask protected information, filter outputs, and monitor access and responses. |
| LLM07: Insecure Plugin Design | Plugins, tools, or integrations accept model-generated instructions without sufficient validation, authorization, or narrowly defined functionality. | An assistant sends an unsafe or unauthorized argument to a plugin because the integration does not adequately check the request. | Validate plugin inputs, enforce authorization outside the model, narrowly scope functions and permissions, use allowlists where appropriate, and require confirmation for high-impact operations. |
| LLM08: Excessive Agency | The model or agent has more permissions, autonomy, functionality, or tool and API access than its task requires. | An assistant can make high-impact changes through an integration without sufficiently narrow permissions or confirmation. | Apply least privilege, narrowly scope tools and tokens, enforce authorization outside the model, limit action scope, and require confirmation for high-impact operations. |
| LLM09: Overreliance | Inaccurate or credible-looking model output is trusted without sufficient validation, creating business, operational, legal, or reputational risk. | A decision-maker relies on an incorrect generated answer because it sounds confident and was not checked against trusted information. | Ground responses in trusted sources, test accuracy for important tasks, make review requirements clear, monitor quality, and maintain human oversight where errors have meaningful consequences. |
| LLM10: Model Theft | An attacker or unauthorized party obtains, copies, or reconstructs a model or its valuable capabilities through the application or its interfaces. | An exposed model endpoint or insufficiently protected application interface allows unauthorized access to the model or its capabilities. | Authenticate and authorize model access, protect endpoints and artifacts, limit and monitor usage, apply rate limits and quotas, and investigate unusual access patterns. |
Practical Mitigation Priorities
Protect instructions, data, and outputs
Keep trusted instructions distinct from untrusted content and limit what enters the model context. Validate actions before execution, and treat every model response as untrusted until it has been checked for its intended destination and use.
Output validation, filtering, sanitization, sandboxing, and containment are especially important when generated content can reach an API, database, browser, interpreter, or other downstream system.
Control permissions and retrieval
Use least privilege for models, agents, tools, APIs, tokens, and service accounts. Authorization should be enforced by the surrounding application rather than delegated to the model. Sensitive or high-impact actions should have narrow scopes and, where appropriate, human confirmation. For a focused explanation of this access-control approach, see Role-Based Access Control for AI Agents.
For RAG and vector systems, enforce retrieval permissions before content enters the model context. Maintain tenant isolation, validate indexed material, and apply user- and metadata-level access controls to vector stores, semantic caches, and persistent memory.
Monitor usage and artifacts
Verify the provenance of models, packages, datasets, adapters, tools, and vector-store content. Version important artifacts and monitor changes and behavior after updates.
Authentication, rate limits, quotas, monitoring, and logging help control model denial-of-service risks and provide visibility into unusual activity. These measures reduce risk, but no individual control—and no use of the OWASP list—guarantees security. For a focused guide to this practice, see AI security monitoring.
How to Assess an LLM Application
A practical, authorized review should follow the application’s architecture rather than test the model in isolation:.
- Map trust boundaries: document user inputs, system instructions, retrieved content, memory, tools, APIs, and downstream output destinations.
- Review retrieval controls: check whether user and tenant permissions are enforced before documents, embeddings, or memory enter model context.
- Inventory tools and permissions: identify every tool, token, integration, and high-impact action available to the model or agent.
- Check input and output handling: verify that untrusted content is constrained and that generated output is validated, sanitized, sandboxed, or approved before downstream use.
- Measure resource boundaries: review authentication, request limits, token quotas, workflow limits, logging, and monitoring for expensive or repeated operations.
Testing should be performed with clear authorization and should avoid using real secrets or causing harmful downstream actions. The goal is to verify boundaries and controls, not to demonstrate exploit techniques.
OWASP LLM Applications vs. Agentic Applications
The OWASP Top 10 for LLM Applications is distinct from the separate OWASP Top 10 for Agentic Applications. The LLM application list addresses risks around applications built with large language models. The agentic framework is relevant when systems use autonomous workflows, persistent memory, tools, integrations, or broader action-taking capabilities.
Agentic designs can increase permissions, dependencies, and potential blast radius. Standing credentials, multiple tool calls, persistent memory, and autonomous workflows can compound the impact of prompt injection, disclosure, excessive agency, poisoning, and improper output handling.
An application that includes an agent should therefore assess the LLM application risks and also consider the separate agentic-application guidance where it applies. The two frameworks are not identical or automatically interchangeable.
Questions for Architecture-Specific Assessment
- Does the application use RAG, vector stores, semantic caches, or persistent memory?
- Are retrieval permissions and tenant boundaries enforced before content enters the model context?
- Can the model call tools, APIs, or integrations, and are those permissions narrowly scoped?
- Does the system process sensitive data, confidential prompts, logs, embeddings, or tool arguments?
- Where are outputs sent, and what validation, sanitization, approval, monitoring, authentication, rate limits, and quotas apply?
The most useful review starts with the application’s actual architecture and keeps its OWASP edition terminology consistent. RAG, tools, agents, multi-tenancy, memory, and sensitive data each change which controls deserve the closest attention.
