What is the OWASP Top 10 for LLM applications, and why is it a separate list?
The OWASP Top 10 for LLM Applications is a ranked list of the ten most consequential security risks in systems built on large language models, maintained by the OWASP Gen AI Security Project and last revised in 2025. It exists separately from the classic web Top 10 because an LLM application handles untrusted language, and language can carry instructions. Add tools (database, email, payments) and retrieval over private documents, and you get failure modes that no SQL-injection checklist covers. The 2025 revision added excessive agency, system prompt leakage, vector and embedding weaknesses and misinformation, based on what actually broke in deployments (OWASP, 2025).
Classic injection vs prompt injection: what changes?
SQL injection and prompt injection share a root cause — data that is interpreted as instructions — but the defences differ. SQL injection has a complete fix: parameterised queries. Prompt injection has no complete fix, because the model cannot reliably tell instruction from content, so defence moves to limiting what an injected instruction can achieve. The table shows the shift; it is why the rest of the list is mostly about permissions and output handling.
| Criterion | Classic injection (SQL, command) | Prompt injection |
|---|---|---|
| Where it enters | Form fields, URL parameters, headers | User messages, retrieved documents, tool outputs, web pages |
| Why it works | Parser mixes code and data | Model mixes instructions and content by design |
| Complete fix exists? | Yes: parameterised queries, encoding | No: only layered mitigation |
| Primary defence | Fix the parser boundary | Limit what the model can do and verify what it did |
| Detection | WAF signatures, static analysis | Attack suites in CI, output checks, human approval |
| Blast radius | One database or host | Every tool and document the agent can reach |
How does each of the ten show up in a real system, and what is the fix?
Each entry below is a concrete failure we have seen in a chatbot, a RAG system or an agent, paired with the fix we apply in production. The order is OWASP's; in practice the first, sixth and eighth cause most of the incidents with real damage, because they are the ones that turn a wrong answer into a wrong action or a leaked document. Breach economics make the fixes worth it: IBM put the global average cost of a data breach at USD 4.88 million in 2024 (IBM, 2024).
- 1. Prompt injection. A user, or a document the model reads, tells it to ignore its instructions. Indirect injection is the dangerous one: an email, a web page, a PDF in the knowledge base. Fix: separate instructions from data, treat everything retrieved as untrusted, require confirmation for actions, run an injection test suite on every change.
- 2. Sensitive information disclosure. The model repeats PII, secrets or another tenant's data. Fix: minimise what reaches the model, enforce authorisation at retrieval time, scrub logs.
- 3. Supply chain. Third-party models, adapters, datasets, plugins of unknown provenance. Fix: inventory, signed artefacts, pinned versions, evaluation before swap.
- 4. Data and model poisoning. Someone plants content that changes what the model says. Fix: control who can write to the knowledge base, review ingestion, monitor answer drift.
- 5. Improper output handling. Model output goes to SQL, shell, HTML or a browser unescaped. Fix: treat output as user input — parameterise, encode, sandbox.
- 6. Excessive agency. The agent has more tools, permissions and autonomy than the task needs. Fix: least-privilege tools, scoped credentials, human-in-the-loop for irreversible actions.
- 7. System prompt leakage. Your instructions — and the secrets some teams put in them — are extractable. Fix: assume the prompt is public; keep secrets and authorisation out of it.
- 8. Vector and embedding weaknesses. RAG returns documents the user should not see, or embeddings are inverted. Fix: per-document ACLs applied in the query, not after; tenant isolation.
- 9. Misinformation. Confident wrong answers with business impact. Fix: grounding with citations, evaluation sets, disclaimers where the stakes are real.
- 10. Unbounded consumption. Token floods, recursive tool loops, denial of wallet. Fix: rate limits, budgets per user and per run, loop detection.
How do you test an LLM application against the list?
Test in two layers: an automated suite of injection, jailbreak, extraction and abuse prompts that runs in CI like unit tests, and a manual phase where engineers who understand the tools behind the agent try to chain them. The automated layer catches regressions on every prompt or model change; the manual layer finds the paths a generator cannot imagine, such as reading a poisoned ticket and then using CRM access to leak data. Manual findings become new automated cases, so the suite grows with the system. MITRE ATLAS provides a public catalogue of adversarial techniques against AI systems that is a good seed for the suite (MITRE, 2024).
This is what our AI & LLM security assessment does; the same engineers build our production AI systems, which is why the fixes are practical rather than theoretical.
Who needs to care, and what do regulators expect?
Any team that connects a model to private data or to tools needs to work through the list — that is most chatbots with a knowledge base and every agent. Regulators are converging on the same controls: the EU AI Act (Regulation 2024/1689) requires providers of general-purpose models and deployers of high-risk systems to manage cybersecurity risks and document them (EU, 2024), and NIST's generative AI profile lists prompt injection, data leakage and confabulation among the risks organisations should measure and manage (NIST, 2024). The OWASP list is the practical bridge between those obligations and a test plan.