The OWASP Top 10 for LLM apps, for developers

The OWASP Top 10 has been the standard list of web application risks for years. In 2023 OWASP published a parallel list for applications built on language models, and updated it in 2025 — the OWASP Top 10 for LLM Applications. If you build a chatbot, a RAG assistant, an agent or any feature that calls a model, these are the ten ways it gets attacked.

The list is written for security people, so it reads like a specification. Here’s what each item means when you’re the one building the thing, and the one change that matters most for each.

1. Prompt injection

The defining attack. An attacker writes text the model treats as instructions, overriding yours. It can be typed directly, or hidden inside content the model reads — an email, a web page, a PDF it summarises. There’s no complete fix, so the real defence is limiting what a compromised model can do. That’s covered separately in Prompt injection: the practical defence.

2. Sensitive information disclosure

Models leak things they shouldn’t: personal data, API keys, another user’s details. It happens because the model was trained on too much, or because your prompt and documents contain secrets. Treat everything the model can read as potentially exposed, and filter data before it reaches the model.

3. Supply chain

Your feature depends on models, datasets and libraries you didn’t write. A poisoned dataset or a backdoored weights file is a supply-chain attack. Pin versions, check where models and fine-tuned weights come from, and scan dependencies the way you’d scan any other code.

4. Data and model poisoning

If training data is tampered with, the model learns the wrong behaviour. Most teams use someone else’s model, so the exposure is smaller — but fine-tuning and RAG both pull in data you should treat as untrusted.

5. Improper output handling

Model output is untrusted input to the rest of your system. Render it as HTML and you get cross-site scripting. Pass it to a database or a shell and the classic injection attacks come back. Sanitise output before it touches anything else.

6. Excessive agency

The model can call tools. Ask what happens if an attacker controls it completely. A feature that can issue refunds or change records is high risk; one that can only look up an order status is low. Cap permissions and put a person in front of sensitive actions.

7. System prompt leakage

The instructions you gave the model are often exactly what an attacker wants — they describe its tools, rules and limits. Assume the system prompt will leak, and keep secrets out of it.

8. Vector and embedding weaknesses

RAG systems turn text into embeddings and retrieve similar passages. Embeddings can be manipulated, and retrieval can pull in poisoned content. Validate what you retrieve before it reaches the model.

9. Misinformation

A confident wrong answer can do more damage than a refused one. Keep a person in the loop for anything consequential, and show sources so people can check.

10. Unbounded consumption

Every call costs money and compute. Without limits, an attacker can run up a bill or cause a denial of service. Cap input length, output length, rate and spend.

Where to start

If you only do two things, test for prompt injection and cap what your model can do. Those two account for most real-world damage. The rest of the list is about making the gaps smaller and the failures cheaper.

Our AI Governance Scanner runs these checks automatically and saves the results as evidence. If you need a one-off test before a launch, our application security assessment covers both the AI feature and the application around it.