OWASP Top 10 for LLM Applications Explained: A Practical Guide for Developers
In short
- The OWASP Top 10 for LLM Applications is the most widely used checklist of security risks for apps built on large language models. The 2026 edition was published in August 2026.
- Prompt injection is still number one. The biggest change: Excessive Agency jumped to number three, because AI agents now take real actions.
- Most fixes are ordinary security engineering: least privilege, treating model output as untrusted, limits, and human approval for risky actions.
If you're adding a chatbot, an AI assistant or an agent to your product, you're also adding a new kind of attack surface. The model reads text from users, documents, websites and tools, and any of that text can try to steer it. This guide explains the 2026 OWASP Top 10 for LLM Applications in plain language and gives you concrete steps for each risk, so you can ship AI features without shipping new vulnerabilities.
What the OWASP Top 10 for LLM Applications is
OWASP, the open community behind the classic web application Top 10, runs the GenAI Security Project. Its Top 10 for LLM Applications ranks the most important security risks specific to software that uses large language models. It's free, vendor-neutral and updated as attacks evolve. The 2026 edition was published in August 2026 and announced at the start of September, with expanded mappings to NIST, MITRE ATLAS, CWE and OWASP's separate Top 10 for Agentic Applications.
Here is the 2026 list and how each entry moved compared with 2025:
| # | Risk | Change from 2025 |
|---|---|---|
| LLM01 | Prompt Injection | Still #1 |
| LLM02 | Sensitive Information Disclosure | Still #2 |
| LLM03 | Excessive Agency | Up from #6 |
| LLM04 | Supply Chain | Down from #3 |
| LLM05 | Data and Model Poisoning | Down from #4 |
| LLM06 | Unbounded Consumption | Up from #10 |
| LLM07 | Misinformation | Up from #9 |
| LLM08 | Hidden Context Exposure | Replaces System Prompt Leakage, with a wider scope |
| LLM09 | Vector and Embedding Weaknesses | Down from #8 |
| LLM10 | Improper Output Handling | Down from #5 |
The direction of travel is clear: as models gain tools, memory and autonomy, the risks that matter most are the ones where an AI can do something harmful, not just say something wrong.
The ten risks and what to do about them
LLM01: Prompt Injection
An attacker gets instructions into the model's input so it ignores your rules. It can be direct ("ignore previous instructions…") or indirect: hidden text in a web page, email, PDF, image or tool response that your app feeds to the model. The 2026 edition explicitly covers images, audio, video and agent memory too.
- Assume injection will sometimes succeed, and design so that a fooled model can't do much damage.
- Keep untrusted content clearly separated from instructions, and give the model only the tools and data the current user is allowed to use.
- Require human approval for consequential actions, and red team your prompts regularly.
LLM02: Sensitive Information Disclosure
The model reveals data it shouldn't: other customers' records, internal documents, credentials, or personal data that ended up in training data, logs or retrieved context.
- Don't put data in the model's reach that the current user isn't allowed to see. Enforce access control before retrieval, not in the prompt.
- Minimize personal data in prompts and logs, and mask or filter sensitive patterns in outputs.
LLM03: Excessive Agency
The model has more functions, permissions or autonomy than it needs, so a manipulated or mistaken model can delete data, send emails, move money or change settings. This is the biggest climber in 2026.
- Give each tool the narrowest scope possible, and run tool calls with the user's permissions, not a powerful service account.
- Check permissions at the moment a tool is called, not only at setup.
- Add approval steps and circuit breakers for high-impact actions.
LLM04: Supply Chain
Risks from third-party models, datasets, fine-tuning adapters, plugins and libraries: tampered weights, malicious code in model files, unclear licenses.
- Use models and datasets from trusted sources, pin versions, and keep an inventory of every model and component you depend on.
- Remember that a signature proves where a model came from, not that it is safe. Test models before deploying them.
LLM05: Data and Model Poisoning
Attackers corrupt training, fine-tuning or retrieval data to plant backdoors, biases or false facts that persist.
- Track where your data comes from, validate it before use, and version your datasets.
- Test for unexpected behavior triggered by specific phrases or inputs.
LLM06: Unbounded Consumption
Uncontrolled usage drives up costs ("denial of wallet"), slows or crashes your service, or lets someone copy your model's behavior through mass queries. Agents that loop or call tools recursively make this worse.
- Set token-aware rate limits, per-user quotas and spending caps.
- Limit the number of steps and recursive calls in agent workflows, and alert on unusual usage.
LLM07: Misinformation
Confident but false or unsupported output, including hallucinated facts, code packages or citations, that people or systems then act on.
- Ground answers in trusted sources and show those sources to users.
- Verify claims before acting on them automatically, and put human review in front of high-stakes decisions.
LLM08: Hidden Context Exposure
This replaces "System Prompt Leakage". Anything in the model's context can potentially be extracted: system prompts, tool schemas, retrieved documents, agent memory and tool responses.
- Assume users can discover everything in the context. Never put secrets, API keys or internal-only rules there.
- Enforce authorization in your code, not in prompt instructions.
LLM09: Vector and Embedding Weaknesses
Problems specific to retrieval-augmented generation (RAG): one tenant's data showing up in another tenant's answers, poisoned documents in the index, or sensitive text reconstructed from embeddings.
- Apply access controls and tenant separation inside your vector store, filtering by user before search.
- Validate and track the documents you index, and treat retrieved text as untrusted input.
LLM10: Improper Output Handling
Model output is passed to a browser, database, shell or another system without validation, leading to cross-site scripting, SQL injection or command execution.
- Treat every model output as untrusted user input: validate it, encode it for its destination, and use parameterized queries.
- Ask the model for structured output (for example JSON with a fixed schema) and reject anything that doesn't match.
What it looks like in code
Many of these controls are a few lines of ordinary code. This simplified Python example shows three of them: an allowlist of tools (LLM03), authorization as the real user (LLM02 and LLM03), and escaping model output before showing it in a web page (LLM10).
import html
import json
# Only low-risk tools. Refunds and deletions are not available to the model.
ALLOWED_TOOLS = {"search_docs", "get_order_status"}
def run_tool_call(model_output: str, user, tools):
"""tools maps tool names to functions that check the user's own permissions."""
call = json.loads(model_output) # we asked the model for JSON only
name = call.get("tool")
if name not in ALLOWED_TOOLS:
raise PermissionError(f"tool not allowed: {name!r}")
args = call.get("args", {})
if not isinstance(args, dict):
raise ValueError("args must be an object")
# Run as the signed-in user, never as an all-powerful service account
return tools[name](user=user, **args)
def render_answer(text: str) -> str:
# Never insert model output into a page as raw HTML
return html.escape(text)A pre-launch checklist
Before you ship an LLM feature, check that you can answer "yes" to each of these:
- We have a list of every place our app sends untrusted text (user input, documents, web pages, tool results) to a model.
- The model can only reach data the current user is allowed to see.
- Each tool has the minimum permissions it needs, and runs as the user.
- High-impact actions need human confirmation.
- No secrets or authorization rules live in prompts.
- Model output is validated and encoded before it reaches a browser, database or shell.
- We have rate limits, quotas, spending caps and step limits for agents.
- We know which models, datasets and libraries we use, and where they came from.
- Answers that matter are grounded in sources, and risky decisions get a human review.
- We log prompts and tool calls safely (without unnecessary personal data) and test with adversarial prompts before each release.
Where to start this week
Don't try to fix all ten at once. Start by mapping your AI features: what data each one can read, what tools it can call, and who uses it. Then pick the three risks that matter most for that map. For most teams that's Prompt Injection, Excessive Agency and Sensitive Information Disclosure. Finally, add a small set of adversarial test prompts to your test suite so regressions get caught automatically.
For Indonesian teams: if your AI feature handles personal data, Indonesia's Personal Data Protection Law (UU PDP) applies to prompts, logs and retrieved documents just like any other system. Data minimization and access control (LLM02, LLM08 and LLM09) help with compliance as well as security.
If your app uses AI agents, also read OWASP's separate Top 10 for Agentic Applications, which goes deeper into tools, memory and multi-agent risks.
Building an AI feature and want a second pair of eyes? Email Binjesoft for a review of your LLM app against the OWASP Top 10, or see our security services.
Sources: OWASP GenAI Security Project: LLM Top 10 2026 · OWASP announcement (September 2026) · Cloud Security Alliance research note · OWASP GenAI Security Project