Large language models can summarize documents, answer questions, write code, search knowledge bases, and trigger actions through connected tools. Those capabilities also create new security problems. Traditional application controls still matter, but they do not cover every way an LLM application can be manipulated.
The OWASP LLM Top 10 provides a practical security framework for identifying major risks in LLM and generative AI applications. The 2025 edition covers ten risks ranging from prompt injection and sensitive information disclosure to supply-chain issues, excessive agency, vector weaknesses, misinformation, and unbounded consumption. OWASP Top 10 for LLM Applications 2025
This guide explains each risk, shows how prompt injection works, and provides practical steps for building more secure LLM applications.
Key Takeaways
- The OWASP LLM Top 10 2025 identifies ten major security risks affecting LLM and generative AI applications.
- Prompt injection remains a central risk because untrusted content can influence model behavior.
- RAG does not automatically make an application secure. Retrieved documents can become an attack path.
- LLM output should be treated as untrusted data before another system executes or displays it.
- Agents need tightly scoped permissions, tool restrictions, and human approval for sensitive actions.
- Security teams should combine OWASP guidance with threat modeling, testing, monitoring, access control, and incident response.
What Is the OWASP LLM Top 10?
The OWASP LLM Top 10 is a security framework from the OWASP GenAI Security Project. It focuses specifically on risks created by applications that use large language models and generative AI.
The 2025 list contains ten categories: Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption. OWASP LLM Top 10 risk list
The framework is useful during design, development, testing, deployment, and ongoing operation. It gives engineering and security teams a common vocabulary for discussing LLM vulnerabilities.
It also helps teams move beyond the assumption that an LLM is simply another API. The model can interpret natural-language instructions, consume external information, generate new content, and interact with other systems. Each of those capabilities introduces trust boundaries that need protection.
For a broader view of how LLMs fit into enterprise AI systems, see our guide to applied AI for enterprises.
Why the OWASP LLM Top 10 Matters
Traditional application security often focuses on vulnerabilities such as SQL injection, cross-site scripting, broken access control, and insecure APIs. Those remain important for AI applications, but LLMs introduce another layer.
An LLM does not reliably distinguish between an instruction and every piece of data placed into its context. A webpage, uploaded document, email, or database record can contain text that influences model behavior.
This changes the security model. An application may be technically correct at the API level while still allowing malicious content to influence an LLM’s decisions.
The same issue becomes more serious when an LLM can call tools. A manipulated response is one problem. A manipulated response that causes an agent to send an email, access a database, modify a file, or invoke an external API can have a much larger impact.
That is why llm application security needs controls around both the model and the systems connected to it.
OWASP LLM Top 10 2025: What Changed?
The 2025 edition reorganized and updated the risk categories to reflect the changing LLM application landscape. The list explicitly covers Vector and Embedding Weaknesses, reflecting the growing use of retrieval-augmented generation and vector databases. It also uses updated categories such as Data and Model Poisoning and Improper Output Handling. OWASP 2025 LLM risk and mitigation guidance
This matters when creating a security program. Teams should use the current 2025 categories for new assessments while understanding older documentation that references previous versions.
OWASP LLM Top 10 Vulnerabilities Explained
The ten categories cover different points in the lifecycle of an AI application. Some attack the model’s behavior. Others target data, dependencies, permissions, retrieval systems, or operational resources.
LLM01: Prompt Injection
Prompt injection occurs when input changes an LLM’s behavior in ways the application did not intend. The attack can be direct, where the user supplies the malicious instruction, or indirect, where the instruction comes from external content such as a webpage or document.
For example, a customer-support assistant might normally retrieve an account record and summarize it. A malicious user could attempt to override the assistant’s intended task and make it reveal information from another source.
Indirect injection is more difficult to reason about. Imagine a RAG assistant that summarizes uploaded documents. A malicious document could contain hidden instructions telling the model to ignore the user’s request or expose information from its context. When the document is retrieved, those instructions become part of the model’s input.
Potential consequences include sensitive-data disclosure, unauthorized tool use, manipulated decisions, and exposure of system information.
LLM02: Sensitive Information Disclosure
LLMs can expose information that should remain private. This may include personal information, confidential business data, internal instructions, credentials, proprietary code, or information retrieved from restricted sources.
The risk does not always come from model training. Application design can create disclosure paths by placing sensitive data in prompts, retrieval contexts, logs, tool responses, or conversation history.
Strong access controls should exist before sensitive information reaches the model. An LLM should not receive unrestricted data simply because it might be useful for answering a question.
LLM03: Supply Chain
LLM applications depend on more than the model itself. They may use open-source models, datasets, embedding models, Python packages, plugins, APIs, containers, vector databases, and third-party services.
A compromised dependency can affect the entire application. Model files and datasets also require provenance checks because security problems can enter before the application reaches production.
A sensible supply-chain strategy includes dependency scanning, version control, trusted sources, integrity verification, and regular review of third-party components.
LLM04: Data and Model Poisoning
Data and model poisoning occurs when malicious or unreliable data influences pre-training, fine-tuning, embedding, or other parts of the AI pipeline.
An attacker could attempt to insert manipulated examples into a dataset or knowledge base. In a RAG system, poisoning can happen after the base model has already been trained because retrieved documents can influence responses at runtime.
This makes data governance part of ai security. Teams should validate sources, control who can modify knowledge bases, track provenance, and monitor unexpected changes in model or retrieval behavior.
LLM05: Improper Output Handling
LLM output should not automatically be considered safe simply because it was generated by a trusted model.
A model may produce text that is later inserted into HTML, passed to a database, interpreted by code, or used as an API parameter. If the receiving system trusts that output without proper validation, the application can develop a downstream vulnerability.
The solution is to enforce validation at the system boundary. Treat model output as untrusted input and apply the appropriate security controls before another component processes it.
LLM06: Excessive Agency
An LLM becomes more dangerous when it receives broad permissions and can act independently.
An agent with access to email, cloud storage, internal APIs, databases, and code execution has a much larger attack surface than a chatbot that only returns text.
Use least privilege. Give each tool only the permissions it needs. Restrict which tools can be called, validate important parameters, and require human confirmation for high-impact actions.
LLM07: System Prompt Leakage
System prompts often contain application instructions, behavioral rules, workflow details, or information about available capabilities.
An attacker may try to make the model reveal those instructions. Although hiding a system prompt should not be treated as the application’s primary security boundary, leakage can still reveal useful information about the system.
Sensitive secrets should never be placed in prompts. Authorization rules and security decisions should live in deterministic application code rather than depending solely on hidden instructions.
LLM08: Vector and Embedding Weaknesses
Vector and embedding weaknesses are particularly relevant to RAG systems. Problems can occur during embedding generation, storage, retrieval, access control, or data management.
Poor isolation can expose information between users or tenants. Malicious content can also enter a knowledge base and influence later responses.
Good rag security therefore requires more than choosing a secure vector database. The application must control which documents a user can retrieve and treat retrieved content as untrusted.
LLM09: Misinformation
LLMs can produce confident but inaccurate information. This becomes a security risk when users or downstream systems treat generated content as authoritative.
The impact depends on the application. An incorrect answer in a casual chatbot may be inconvenient. An incorrect recommendation in finance, healthcare, legal workflows, or security operations can have much greater consequences.
Mitigation can include source grounding, retrieval, validation, confidence-aware workflows, human review, and monitoring for recurring failure patterns.
LLM10: Unbounded Consumption
LLM calls consume computational resources and can create significant costs. Poorly controlled requests may cause excessive token usage, repeated processing, long-running workflows, or resource exhaustion.
Attackers can exploit expensive operations intentionally, but ordinary application bugs can create similar problems.
Set rate limits, token budgets, request-size limits, timeouts, concurrency controls, and usage monitoring. For agents, also limit the number and cost of tool calls within a single task.
OWASP LLM Top 10 Prompt Injection Guidance
Prompt injection deserves special attention because it targets the way an LLM interprets instructions and context. RAG and fine-tuning do not automatically eliminate prompt injection vulnerabilities.
There is no single filter that reliably solves the problem. The strongest approach reduces the impact of a successful injection by separating trust boundaries and restricting what the model can do.
Direct vs. Indirect Prompt Injection
A direct prompt injection comes from the user. The attacker deliberately writes instructions intended to change the model’s behavior.
An indirect prompt injection enters through external content. The attacker might place instructions inside a webpage, PDF, email, image, repository, or database record that the application later sends to the model.
The distinction matters because filtering user prompts does not address every indirect attack. Any external content that enters the model’s context should be treated as potentially untrusted.
Prompt Injection Defense Strategies
Effective prompt injection prevention starts with reducing what an injected instruction can accomplish.
Use clear trust boundaries between user instructions, retrieved content, tool results, and application-controlled instructions. Validate outputs before passing them to another system. Apply least privilege to every tool.
System prompts can help define expected behavior, but they should not be the only security mechanism. Use constrained model behavior, defined output formats, deterministic validation, penetration testing, and breach simulations.
For sensitive actions, add an approval step outside the model. The model can recommend an action, while application code decides whether that action is authorized.
For a deeper enterprise-focused treatment of this topic, see our guide to prompt injection prevention and enterprise LLM security.
Prompt Injection Testing
Testing should include both obvious and subtle adversarial inputs.
Create test cases that attempt to override instructions, extract private context, manipulate retrieved documents, trigger unauthorized tools, and bypass output restrictions. Include external documents containing hidden or misleading instructions.
Test multimodal applications as well. Malicious instructions can be embedded in images or other modalities and interpreted alongside ordinary text.
Repeat these tests whenever prompts, models, tools, retrieval sources, or application permissions change.
OWASP LLM Top 10 vs. Traditional Application Security
LLM applications still require standard web and API security. The difference is that the model introduces a new interpretation layer between input and action.
A secure AI application therefore needs both conventional controls and controls designed for LLM behavior.
For example, an API gateway can authenticate a request correctly, yet the LLM behind that API might still be manipulated into making an inappropriate tool call. Authentication solves identity. It does not automatically solve model behavior.
How to Secure an LLM Application Against the OWASP LLM Top 10
A practical security architecture should use multiple layers. Do not place the entire security burden on the model.
Secure the Input and Prompt Layer
Separate trusted instructions from untrusted content. Clearly define what the model is allowed to do and what information it should use.
Validate input size and format. Normalize content where appropriate. For high-risk applications, inspect uploads and external sources before placing them into the model context.
Keep authorization decisions in application code. The model can interpret a request, but it should not independently decide whether a user has permission to access a protected resource.
Secure Models, Data, and Dependencies
Track where models, datasets, embeddings, packages, and plugins come from. Keep an inventory of components and update them through controlled processes.
Protect datasets from unauthorized modification. Record provenance and maintain version history so suspicious changes can be investigated.
For fine-tuning pipelines, validate training data before use. For RAG systems, validate knowledge-base content before indexing it.
Secure RAG and Vector Databases
RAG systems should enforce permissions during retrieval, not after the model generates an answer.
If two users have different access rights, the retrieval layer must ensure that restricted documents cannot enter the wrong user’s context.
Partition sensitive collections where appropriate. Validate new documents, inspect ingestion pipelines, log retrieval events, and monitor unusual access patterns.
Secure LLM Tools and Agents
Create an explicit allowlist of tools the model can use. Give each tool the smallest permission set necessary.
Validate arguments before execution. Limit the number of calls per task. Add confirmation for actions such as sending messages, changing records, deleting files, or transferring funds.
This approach limits the blast radius if prompt injection succeeds.
Monitor and Test Continuously
Security does not end at deployment. Monitor prompts, retrieval activity, tool calls, failures, resource consumption, and suspicious patterns while respecting privacy requirements.
Use red-team exercises and automated adversarial tests to identify new ai application vulnerabilities.
Maintain an incident-response process for model manipulation, data leakage, compromised dependencies, and unexpected agent actions.
For production teams, observability is especially important. See our guide to LLM observability in production for a broader look at monitoring LLM-powered systems.
Organizations can also complement OWASP-specific controls with the NIST Generative AI Profile, which provides a broader risk-management framework for generative AI across the AI lifecycle.
Common Mistakes When Implementing OWASP LLM Top 10 Security
Teams often make the same architectural mistakes when they treat an LLM as a trusted component instead of an untrusted decision-making layer.
Mistake: Treating Prompt Injection Like Traditional Injection
SQL injection often has a well-defined parser boundary where prepared statements can separate data from SQL instructions.
Natural-language prompts do not provide the same clean separation. An LLM interprets instructions and data together, so simple keyword blocking cannot provide complete protection.
Use layered controls instead: context separation, least privilege, output validation, restricted tools, and continuous adversarial testing.
Mistake: Giving LLMs Excessive Permissions
An agent does not need administrator access simply because it can technically use an administrative API.
Broad permissions turn a model-level manipulation into an application-level compromise. Scope credentials by task and require explicit approval for sensitive operations.
Mistake: Trusting Retrieved Content
Retrieved content is data, not automatically an instruction.
A PDF, website, email, or database record may contain malicious text designed to influence the model. Treat external content as untrusted and enforce access control before retrieval.
OWASP LLM Top 10 Decision Matrix
Security teams can prioritize controls based on both likelihood and impact.
The matrix should not replace application-specific risk assessment. A healthcare assistant, coding agent, internal enterprise chatbot, and public customer-support bot can have very different threat profiles.
Use llm threat modeling to map data flows, trust boundaries, users, tools, external sources, and high-impact actions before assigning priorities.
Real-World Example: Securing a RAG-Based AI Assistant
Consider an internal company assistant that answers employee questions using policies, project documents, and internal knowledge bases.
The assistant accepts a question, retrieves relevant documents, sends the question and retrieved content to an LLM, and returns an answer.
Attack Scenario
An attacker uploads a document containing legitimate-looking business information plus hidden instructions. The document passes through ingestion and becomes searchable.
Later, an employee asks a normal question. The malicious document is retrieved and placed into the LLM’s context. Its hidden instructions attempt to redirect the model or expose information from another source.
This is an example of an indirect prompt injection path. Malicious external content can become an attack vector when it enters an LLM’s context.
Security Controls
The application should validate uploaded documents before indexing them. Access controls should be enforced during retrieval so users only receive documents they are authorized to access.
Retrieved content should remain clearly separated from application instructions. The LLM should not receive unrestricted access to internal systems.
If the assistant can call tools, each tool should have narrowly scoped permissions. Sensitive actions should require deterministic validation or human approval.
Expected Secure Workflow
A safer workflow looks like this:
User request → authentication → authorization → safe retrieval → context construction → LLM response → output validation → authorized action
The application, not the model, should enforce the security boundaries.
This design does not assume that prompt injection can always be prevented. Instead, it limits what happens when an attacker succeeds.
How to Build an OWASP LLM Top 10 Security Checklist
A practical llm security checklist should cover development, testing, and production operations.
Development Checklist
- Define trust boundaries between users, models, retrieved content, and tools.
- Apply authentication and authorization before retrieving sensitive data.
- Keep secrets and credentials outside model prompts.
- Validate model inputs and outputs.
- Track model, dataset, dependency, and plugin provenance.
- Apply least privilege to tools and service accounts.
- Validate documents before adding them to RAG indexes.
- Set request, token, and execution limits.
Testing Checklist
- Test direct prompt injection.
- Test indirect prompt injection through documents and websites.
- Test attempts to extract sensitive context.
- Test unauthorized tool calls.
- Test malicious or poisoned retrieval content.
- Test malformed and unexpected model output.
- Test resource-exhaustion scenarios.
- Test access controls across users and tenants.
- Run adversarial and red-team exercises after major changes.
Production Checklist
- Monitor unusual prompts and tool activity.
- Log retrieval and authorization events.
- Track token and infrastructure consumption.
- Enforce rate limits and quotas.
- Review model and dependency updates.
- Monitor knowledge-base changes.
- Maintain incident-response procedures.
- Reassess the threat model as new capabilities are added.
A mature program treats llm security best practices as an ongoing engineering process rather than a one-time compliance exercise.
Frequently Asked Questions About the OWASP LLM Top 10
What Is the OWASP LLM Top 10?
The OWASP LLM Top 10 is a security framework that identifies major risks affecting LLM and generative AI applications. The 2025 edition contains ten categories covering threats such as prompt injection, sensitive information disclosure, supply chain risks, excessive agency, vector weaknesses, misinformation, and unbounded consumption. OWASP Top 10 for LLM Applications 2025
What Is the OWASP LLM Top 10 Prompt Injection Risk?
The OWASP LLM Top 10 prompt injection risk refers to attacks that manipulate an LLM through malicious instructions. These instructions can come directly from users or indirectly through documents, webpages, emails, or other content processed by the model.
What Is the OWASP LLM Top 10 2025 Edition?
The OWASP LLM Top 10 2025 edition is the updated version of the framework covering major security risks in modern LLM applications. It places strong emphasis on risks involving RAG, vector and embedding systems, agentic capabilities, supply chains, and resource consumption.
What Are the Main OWASP LLM Top 10 Vulnerabilities?
The ten categories are prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. Together, they cover risks across the model, data, application, retrieval, tool, and infrastructure layers.
How Can Organizations Prevent Prompt Injection Attacks?
Organizations should use layered defenses rather than relying only on prompt wording. Useful controls include separating trusted instructions from untrusted content, restricting model permissions, validating tool calls and outputs, enforcing authorization outside the LLM, monitoring suspicious behavior, and regularly performing adversarial testing.
Is the OWASP LLM Top 10 Enough to Secure an AI Application?
No. The OWASP framework is an important foundation, but secure AI applications also require authentication, authorization, secure software development, infrastructure security, privacy controls, threat modeling, monitoring, incident response, and ongoing testing. Organizations should treat the framework as part of a broader LLM application security program.
Final Perspective
The OWASP LLM Top 10 gives engineering teams a practical way to understand the security problems created by generative AI.
The most important lesson is that LLM security is not limited to protecting the model.
A secure AI application must protect the complete chain:
Users → prompts → models → data → retrieval → tools → APIs → infrastructure
Prompt injection may be the most visible risk, but it is only one part of the picture. Sensitive data, compromised dependencies, poisoned content, unsafe outputs, excessive agent permissions, vector databases, misinformation, and uncontrolled resource consumption can all affect a production system.
The strongest approach is therefore layered.
Use trusted data sources. Apply least privilege. Keep authorization outside the model. Validate generated outputs. Secure retrieval systems. Monitor tool activity. Test adversarial scenarios. Control resource usage. Review changes continuously.
When these controls work together, the OWASP LLM Top 10 becomes more than a list of vulnerabilities. It becomes a practical framework for designing, testing, and operating safer AI applications.
About the Author
