Safeguard
AI Security

OWASP Top 10 for LLM Applications, Explained

A practitioner's walkthrough of the OWASP Top 10 for LLM Applications: what each risk looks like in a real system, which ones bite first, and the mitigations that hold up.

Safeguard Research Team
Research
6 min read

The OWASP Top 10 LLM list is the standard catalog of security risks specific to applications built on large language models, covering prompt injection, insecure output handling, supply chain exposure, excessive agency, and six other failure modes that traditional AppSec checklists miss. If you ship anything with an LLM in the request path, this list is the baseline threat model. The current version was published as the 2025 edition, and it reflects real incidents rather than speculation.

This post walks each entry with a concrete example and the mitigation that actually works, not the aspirational one.

What Is the OWASP Top 10 LLM List and Who Maintains It?

OWASP, the foundation behind the classic web application Top 10, runs a genAI security project that publishes this list. People search for it as the owasp ai top 10 or owasp top 10 ai, and those names all refer to the same document: the OWASP Top 10 for LLM Applications. It ranks the ten most consequential risk categories using contributions from several hundred practitioners, and it is versioned, so expect entries to shift as attack techniques mature.

The important framing: these are application risks, not model risks. Most entries live in the glue code around the model: what you feed it, what you let it do, and what you do with its output.

What Are the Ten Risks?

LLM01: Prompt Injection

Attacker-controlled text changes the model's behavior. Direct injection comes through the user's own input; indirect injection hides instructions in content the model reads, such as a web page, an email, or a document in your RAG corpus. This is the defining vulnerability of the category because instructions and data share one channel, so no filter fixes it completely. Treat every model output influenced by untrusted content as untrusted itself, and enforce permissions outside the model.

LLM02: Sensitive Information Disclosure

The model reveals data it should not: PII from training or fine-tuning data, secrets pasted into context, or other users' data leaking through shared conversation memory. Mitigation is data hygiene before the model, scoped retrieval per user, and output filtering after.

LLM03: Supply Chain

Models, adapters, datasets, and embedding pipelines are dependencies with their own compromise paths: poisoned model weights on public hubs, malicious packages in the Python toolchain, backdoored fine-tunes. The controls mirror classic software composition analysis: inventory what you pull, verify provenance, and pin versions.

LLM04: Data and Model Poisoning

Manipulating training or fine-tuning data to implant biased outputs or trigger phrases. For most teams the practical exposure is fine-tuning on user-submitted or scraped data without review.

LLM05: Improper Output Handling

Downstream code trusts model output blindly: rendering it as HTML (stored XSS), executing it as SQL, or passing it to a shell. The fix is the oldest rule in AppSec applied to a new source: model output is untrusted input. Encode, parameterize, and sandbox accordingly.

LLM06: Excessive Agency

The model has more tools, permissions, or autonomy than the task needs, so one successful injection turns into real actions: sending mail, writing to databases, calling internal APIs. Scope tool access per use case, require human approval for irreversible actions, and give the agent its own least-privilege identity rather than the invoking user's full permissions.

LLM07: System Prompt Leakage

Attackers extract the system prompt and, with it, whatever secrets or logic you embedded there. Assume the system prompt is readable. Keep credentials, tenant identifiers, and security-relevant rules out of it, and enforce those rules server-side.

LLM08: Vector and Embedding Weaknesses

RAG-specific risks: poisoned documents in the corpus become indirect injection payloads, and weak access controls on the vector store leak one tenant's documents into another's retrievals. Per-tenant isolation and provenance tracking on ingested content are the controls.

LLM09: Misinformation

The model asserts falsehoods with confidence and your product amplifies them. The now-classic legal example: fabricated case citations submitted in court filings. Where outputs carry consequences, require citations to retrieved sources and human review.

LLM10: Unbounded Consumption

No limits on tokens, requests, or agent loops. The results are denial-of-service and surprise invoices, and with agentic systems, a single runaway loop can burn a day's budget in minutes. Rate limits, token ceilings, loop caps, and cost alerts are unglamorous and mandatory.

Which OWASP Top 10 LLM Risks Should You Fix First?

Ranked by observed damage in deployed systems, not list order:

  1. Improper output handling (LLM05), because it converts a model quirk into a classic exploit, and it is the cheapest to fix: treat output as untrusted, always.
  2. Excessive agency (LLM06), because agent frameworks default to generous tool access, and this is what turns prompt injection from embarrassing into expensive.
  3. Prompt injection (LLM01), accepted as partially unsolvable and contained through the two items above.
  4. Supply chain (LLM03), because model and dataset provenance is still weakly verified in most pipelines.

The remaining six matter, but these four are where incidents actually happen in systems we have reviewed.

How Do You Test Against the List?

Three layers, in increasing order of effort:

  • Static and dependency scanning of the application around the model: output-handling paths, tool implementations, and the AI toolchain's packages. Standard SAST and DAST applies because most LLM application bugs are ordinary code bugs in new places.
  • Adversarial prompt testing: a maintained corpus of injection and extraction payloads run against staging on every release, the LLM equivalent of a regression suite.
  • Scoped red-teaming for high-agency systems, exercising tool chains end to end: can a poisoned document make the agent exfiltrate data through a tool call?

Safeguard's research team tracks how these risks intersect with the software supply chain; more of our analysis lives on the blog.

FAQ

What is the OWASP Top 10 for LLM applications?

It is OWASP's ranked list of the ten most significant security risks for applications built on large language models: 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.

Is the OWASP AI Top 10 different from the LLM Top 10?

In casual usage they refer to the same document. OWASP's genAI security project publishes the Top 10 for LLM Applications; "owasp ai top 10" is simply the common search phrasing. OWASP also publishes broader AI security guidance beyond the Top 10 itself.

Can prompt injection be fully prevented?

No. Because LLMs process instructions and data in the same channel, filtering alone cannot eliminate injection. The workable strategy is containment: least-privilege tool access, treating model output as untrusted, and human approval on consequential actions.

Does the classic OWASP Top 10 still apply to LLM apps?

Yes. LLM applications are still web applications, so injection, broken access control, and the rest of the classic list apply in full. The LLM Top 10 adds model-specific risks on top; it does not replace the original.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.