Understanding the OWASP LLM Top 10: What Matters Most

OWASP published the LLM Top 10 in 2023, updated it in 2025, and it’s become the standard reference for LLM application security. Like the original OWASP Top 10, it’s most useful as a framework for having conversations about risk coverage and most misleading when treated as a deployment checklist.

This is the practitioner’s interpretation: what each item means operationally, what evidence for exploitation exists, and what to prioritize.

LLM01: Prompt Injection

Operational relevance: High. Documented exploitation in production. The item covers both direct injection (malicious user input) and indirect injection (malicious content in retrieved documents or tool outputs).

What to do: Input validation and injection detection (Lakera, Rebuff, or NeMo Guardrails). Separate validation for retrieval pipeline inputs. Context-aware output filtering.

The nuance: Prompt injection covers a spectrum from “causes unexpected but benign behavior” to “enables data exfiltration or fraud.” Prioritize based on the harm potential in your specific application context, not just the existence of the vulnerability class.

LLM02: Insecure Output Handling

Operational relevance: Medium-High. LLM output is code (for code assistants), HTML (for web apps), SQL (for database interfaces), or natural language (for user-facing chat). Each output type has its own injection risk when passed to downstream systems without sanitization.

What to do: Treat LLM output as untrusted input when passed to any other system. SQL sanitization, HTML encoding, code sandboxing. Guardrails AI’s output validators are the systematic approach.

LLM03: Training Data Poisoning

Operational relevance: Medium. Demonstrated in research; confirmed operational cases are limited to open-weight model scenarios. For most teams using commercial API providers, training data is controlled by the provider.

What to do: If you’re fine-tuning, audit your fine-tuning dataset provenance. If you’re using federated learning, apply Byzantine-robust aggregation. For commercial API users, the risk is minimal.

LLM04: Model Denial of Service

Operational relevance: Medium. Long-context inputs, recursive prompts, and context-flooding attacks can consume significant API compute, driving up costs and degrading availability.

What to do: Input length limits, rate limiting per user, context window budget enforcement. Monitor for anomalous token consumption per session.

LLM05: Supply Chain Vulnerabilities

Operational relevance: High (and increasing). Model weight integrity, dependency integrity, fine-tuning dataset provenance. The 2025 incidents demonstrated this is operational, not theoretical.

What to do: Pin and hash all ML dependencies. Verify model checksums from trusted sources. Audit fine-tuning datasets. Monitor for unexpected network egress from training jobs.

LLM06: Sensitive Information Disclosure ↗

Operational relevance: High. Models memorize training data and can reproduce it under the right conditions. If your fine-tuning data includes PII, proprietary information, or other sensitive data, this is a real risk.

What to do: PII detection on fine-tuning datasets before training. Output scanning for PII (Guardrails AI DetectPII, AWS Comprehend). Audit what data went into fine-tuning and what could be extracted.

LLM07: Insecure Plugin Design

Operational relevance: Medium (growing). As LLM agents with tool access become more common, the security of the tools the LLM can invoke becomes critical. An LLM with access to email, file systems, and external APIs is a powerful attack amplifier.

What to do: Minimal privilege for LLM tool access. Confirmation steps for consequential actions. Audit what tools your LLM agents have access to.

LLM08: Excessive Agency

Operational relevance: Medium (growing). Agentic LLMs that can take real-world actions (send emails, make API calls, modify files) amplify the impact of any other vulnerability. A prompt injection in an agentic system can cause real-world harm.

What to do: Human-in-the-loop for consequential actions. Rate limits on tool invocations. Principle of least privilege. This is the risk that scales with the capability of your LLM deployment.

LLM09: Overreliance

Operational relevance: High (often underweighted). Users who trust LLM outputs without verification introduce risk — from hallucinated facts, from outdated information, from confident wrong answers.

What to do: UX that communicates uncertainty. Citations for factual claims. Calibration of where the model is reliably accurate vs. where it hallucates. This is as much product design as security.

LLM10: Model Theft

Operational relevance: Low-Medium. Extraction attacks that reconstruct significant portions of a model’s capability through API queries are documented in research. Practical operational exploitation requires large query volumes.

What to do: Rate limiting, query monitoring for extraction patterns, API authentication. Lower priority than injection, supply chain, or information disclosure for most applications.

Prioritization for a typical deployment

For a typical production LLM application (not doing fine-tuning, using a commercial API):

1. Prompt Injection (LLM01): Immediate. Documented operational risk.
2. Sensitive Information Disclosure (LLM06): Immediate if any PII or proprietary data in system prompts or retrieval context.
3. Insecure Output Handling (LLM02): Depends on downstream use of outputs.
4. Supply Chain (LLM05): Medium priority; higher if using open-weight models.
5. Excessive Agency (LLM08): High priority if building agents.

The full OWASP guide is at the linked primary source. For tool coverage of each risk category: bestaisecuritytools.com ↗.

For more context, AI incident tracker ↗ covers related topics in depth.