OWASP helps make emerging security risks understandable and actionable. Through community-driven research and practical standards, it helps organizations anticipate how attackers adapt as software architectures change. From early web applications to modern cloud-native systems, OWASP frameworks translate technical risk into shared language for builders, defenders, and decision-makers.

Large Language Models (LLMs) introduce a class of risk that traditional application security guidance does not fully address. Unlike deterministic software, LLMs interpret language, infer intent, and generate responses that influence downstream systems. They blur the boundary between user input and application logic. This behavior creates exposure that does not fit neatly into existing web security categories.

That exposure matters because generative AI now operates inside critical workflows. Organizations rely on LLMs to generate and review code, support customer interactions, assist fraud analysis, moderate content, and retrieve internal knowledge. These models often sit close to sensitive data and privileged actions. When LLM behavior goes wrong, the impact extends beyond incorrect output into real operational consequences.

The threat landscape has evolved alongside this shift. Attack techniques once focused on exploiting web inputs, endpoints, and configuration errors now target language interfaces, contextual manipulation, and model behavior. As attackers adapt from breaking code to shaping outcomes, security frameworks must evolve to reflect how LLM-enabled applications actually function in production.

To address these shifts, OWASP introduced the Top 10 for Large Language Model Applications to help teams identify and prioritize the most significant risks that emerge when LLMs move from experimentation into production systems.

What is the OWASP Top 10 for LLM Applications?

The OWASP LLM Top 10 is a framework that defines the highest-impact risks in applications that rely on LLMs. The list focuses on how an LLM interacts with input, context, tools, plugins, data sources, and external systems. It covers both direct manipulation of the model and broader architectural weaknesses.

The framework exists because responsibility for LLM risk no longer sits with a single team. Model behavior affects how applications reason, act, and respond across environments. ML engineers shape training and inference. Product teams decide where models sit in workflows. DevSecOps teams manage deployment, access, and runtime controls. Compliance and governance leaders must answer for the decisions these systems influence. The OWASP LLM Top 10 provides a shared structure for these groups to evaluate risk using the same language and assumptions.

The framework acts as a parallel to the original OWASP Top 10 for web applications, but the categories differ. Web application risks focus on injection flaws, authentication issues, access control gaps, and deserialization weaknesses. LLM risks focus on model behavior, training influence, context exposure, tool invocation, and autonomous actions.

By explicitly defining these risks, OWASP helps organizations treat LLMs as active components within the software supply chain rather than passive utilities. This perspective supports clearer threat modeling, more effective security controls, and stronger alignment between engineering decisions and emerging AI governance requirements.

OWASP LLM Top 10 v1.1 — Detailed Breakdown

The following sections explain each risk category and show how the threat creates pressure on real systems. Every H3 uses the OWASP-defined name so your teams can map this content to internal controls and risk registers.

LLM01: Prompt Injection

Prompt injection uses crafted input to influence or override an LLM’s intended behavior. The attacker pushes the model into an alternate instruction path, sometimes with very simple wording. The issue arises because LLMs treat user language as part of the instruction set.

Threats
A successful prompt injection attack can cause the model to reveal sensitive context, exfiltrate data, issue harmful actions through tools, or mislead users. If the LLM connects to plugins or downstream APIs, the attacker may reach deeper systems.

Mitigations
Teams use input sanitization, strict context control, and bounded execution paths to lower exposure. Isolation layers that separate instruction logic from user content also reduce risk. Some stakeholders also add rule-based filters before the LLM receives a prompt.

LLM02: Insecure Output Handling

Insecure output handling arises when applications accept LLM responses as correct and safe without verification. This risk commonly appears when systems pass model output directly into commands, scripts, database queries, forms, or automated workflows. In these designs, the model effectively becomes a decision-making layer without enforcement controls.

Threats
Insecure outputs may trigger shell commands, break workflows, introduce logic errors, or corrupt structured data. Attackers often feed inputs that force an LLM to generate dangerous output that the system interprets as trusted logic.

Mitigations
Output validation, type enforcement, and human-in-the-loop review stop unsafe responses from reaching Defensive controls must treat LLM output as untrusted input. Output validation, strict type enforcement, and schema checks prevent unsafe responses from reaching downstream components. Human review gates remain necessary for high-impact actions. Prompt constraints and output schemas further reduce the risk by limiting how responses form and where they can propagate.

LLM03: Training Data Poisoning

Training data poisoning occurs when an attacker inserts harmful or misleading data into a training corpus or fine-tuning dataset. The model learns patterns from corrupted examples, which influences its output in targeted ways.

Threats
Poisoning may cause biased responses, harmful recommendations, inconsistent behavior, or intentional failure on specific triggers. The impact reaches policy compliance, user trust, and downstream systems that rely on model output.

Mitigations
Teams use data provenance records, strict sourcing rules, audit trails, validation datasets, and continuous evaluation checkpoints. These measures confirm that training data aligns with expected standards before the model reaches production.

LLM04: Model Denial of Service

Model denial of service exploits the resource requirements of LLMs. Attackers send queries that force high memory or compute usage. They may also exploit recursive patterns that push the model into long reasoning loops.

Threats
Model denial of service attacks turn the LLM’s own compute demands into a weapon. By issuing resource-intensive prompts, attackers force the model to consume excessive tokens, memory, and processing time. As demand spikes, response latency rises across legitimate sessions. In cloud environments, this pressure also drives unexpected cost growth, which can become a secondary business impact. During peak usage periods, sustained abuse can render the model unavailable when it matters most.

Mitigations
Effective defenses start with clear limits on how much work the model can perform per request. Token caps prevent individual prompts from consuming disproportionate compute resources. User-level rate controls spread demand across sessions and block sustained abuse from a single source. Adaptive throttling and response timeouts protect availability during traffic surges. Many teams also place lightweight filters in front of the model to identify abnormal usage patterns before they translate into real cost or performance impact.

LLM05: Supply Chain Vulnerabilities

LLM systems depend on complex supply chains, such as open-source libraries, model weights, datasets, third-party APIs, and integration packages. A compromise in any component can influence the entire system.

Threats
Attackers may insert backdoors into model files, tamper with datasets, or exploit vulnerabilities in plugin frameworks. These issues can cause data leaks or system compromise.

Mitigations
Reducing supply chain risk starts with visibility and verification across every component that touches the model. Software bills of materials establish a clear inventory of dependencies, which allows teams to track exposure as vulnerabilities emerge. Model verification and trusted registries ensure that weights, datasets, and integration packages come from known sources. Ongoing integrity checks confirm that deployed components remain consistent with approved baselines, which helps teams detect tampering before it affects production systems.

LLM06: Sensitive Information Disclosure

Sensitive information disclosure appears when an LLM reveals secrets from its training data or from contextual inputs supplied by the application. The risk increases when the model receives confidential material during retrieval or fine-tuning. 

Threats
Disclosure can expose personal information, proprietary research, internal documents, or regulated data. These leaks can trigger privacy violations, compliance failures, and long-term data exposure.

Mitigations
Controls must limit what data reaches the model and what the model can return. Context minimization reduces exposure at ingestion. Retrieval filters and access controls restrict sensitive sources. Output redaction layers prevent accidental disclosure. Teams should restrict prompt inputs to necessary data only and avoid placing confidential material into model context by default.

LLM07: Insecure Plugin Design

Insecure plugin design appears when tools connected to an LLM accept unvalidated input or operate without clear permission boundaries. The model may issue tool commands that exceed its intended authority.

Threats
Poorly secured plugins can enable remote code execution, unauthorized data access, or direct system compromise. Adversaries exploit this risk by crafting prompts that coerce the model into invoking tools with harmful parameters or elevated privileges.

Mitigations
Defensive design requires strong isolation between the model and connected tools. Plugin sandboxing, permission segmentation, and strict input validation reduce exposure. Output filtering and action confirmation gates help prevent unintended execution. High-impact actions should require explicit approval outside the model’s control.

LLM08: Excessive Agency

Excessive agency refers to systems that give LLMs too much autonomy. When a model gains authority to take action without oversight, it may influence critical operations in unpredictable ways.

Threats
Unbounded autonomy may cause deletion of data, flawed triage decisions, incorrect task execution, or harmful workflow changes. Misaligned incentives in chain-of-thought logic can drive unintended outcomes.

Mitigations
Organizations should define and enforce clear operational boundaries. Scope limits, approval workflows, and separation of duties constrain what a model can influence. Comprehensive logging and monitoring support accountability. Supervised execution environments further reduce risk by keeping humans in control of critical actions.

LLM09: Overreliance

Overreliance occurs when users assume LLM output is always correct or safe. The issue often appears in internal tools where staff treat the model as authoritative.

Threats
Uncritical trust can lead to flawed decisions, policy violations, or operational errors. Although overreliance is not an attack by itself, it amplifies the impact of prompt manipulation, misleading context, or model error.

Mitigations
Effective safeguards focus on user awareness and system design. Transparency cues signal uncertainty. Fallback logic and expert review processes provide correction paths. Clear guidance helps users understand when verification is required and where model output should not drive decisions alone.

LLM10: Model Theft

Model theft involves unauthorized access to proprietary model weights or inference capabilities. Attackers target exposed endpoints, weak authentication, or poorly protected hosting environments to extract model behavior or underlying parameters.

Threats
Loss of model weights exposes intellectual property, internal logic, and optimization strategies. It may also force expensive redeployment or retraining.

Mitigations
Strong access controls form the foundation of protection. Encryption safeguards model assets at rest and in transit. Inference rate monitoring detects extraction attempts. Watermarking and secure hosting environments add additional layers of defense against unauthorized access.

Practical Implementation of the OWASP LLM Checklist

The OWASP LLM checklist turns abstract risk into operational discipline. It gives teams a way to test assumptions about how models behave starting from the initial deployment and throughout the development lifecycle. Security accountability must extend across data sourcing, model tuning, integration design, and runtime controls, not stop at deployment.

Implementation starts with visibility. Teams need to understand where model behavior influences business logic, decision paths, and downstream systems. Risk mapping creates that clarity. It shows which interactions matter, which actions carry impact, and where controls must exist before LLMs operate at scale.

From there, the checklist fits naturally into existing delivery practices. DevSecOps teams can fold LLM-specific controls into CI/CD pipelines so changes move forward within defined boundaries. Governance and risk teams can tie OWASP categories to risk registers and compliance requirements, which keeps oversight connected to how systems actually function.

The result is consistency. LLM security stops feeling experimental and starts aligning with established software security practices. Teams gain a repeatable way to assess risk, enforce guardrails, and explain decisions with confidence.

LLM Security Best Practices Beyond the Top 10

The OWASP Top 10 captures the most common failure patterns, but durable LLM security depends on controls that operate every day in production. These practices focus on how models accept input, take action, and evolve over time.

Validate inputs and outputs at every boundary

LLMs accept unstructured input and return language that downstream systems may treat as logic or instruction. Teams should treat both prompts and responses as untrusted. Input validation reduces manipulation before inference. Output validation prevents unsafe responses from reaching tools, workflows, or users. Schema enforcement, allowlists, and action brokers help ensure that language alone cannot drive execution.

Control plugins and agents with explicit authority

Plugins and agents expand what an LLM can do, which also expands the blast radius of failure. Each tool connection needs a defined scope and enforced permission boundaries. Models should not issue high-impact actions without approval gates. Clear separation between reasoning and execution limits how far a model can act when prompted under adversarial conditions.

Audit and monitor for abuse and drift

Visibility sustains trust. Teams need logs that capture prompts, outputs, tool calls, and decision paths. Monitoring helps identify misuse, abuse patterns, and shifts in behavior over time. Without this insight, organizations lose the ability to explain outcomes or respond quickly when something goes wrong.

Maintain fine-tuning and deployment hygiene

LLM pipelines deserve the same rigor as application delivery pipelines. Training data, fine-tuning processes, and model updates require version control, provenance tracking, and access restrictions. Controlled deployment and rollback procedures reduce the risk that changes introduce unseen exposure.

The Future of OWASP and LLM Security Governance

OWASP will continue refining its guidance as AI systems grow more capable. LLM risk patterns evolve as new features, plugins, reasoning processes, and agent frameworks reach production. Stronger alignment with governance standards such as the NIST AI Risk Management Framework and ISO 42001 will support consistent evaluation. These frameworks help organizations maintain transparency, reinforce operational controls, and support compliance requirements.

The next wave of AI regulation will likely expect organizations to show structured guardrails for LLM systems. OWASP’s taxonomy allows teams to describe risk in clear terms that align with policy expectations.

Conclusion

The OWASP LLM Top 10 gives security teams a clear path to evaluate LLM exposure. It also supports stronger alignment between engineering, governance, and compliance groups. Organizations that assess each category, implement guardrails, and review their systems on an ongoing basis will strengthen the resilience of their AI environments. The goal is not to block innovation. The goal is to structure it in a way that protects data, systems, and user trust.

As LLM adoption accelerates, these controls help organizations operate with confidence and clarity. The threat landscape will shift, but a strong framework gives teams the foundation they need to respond with accuracy.