Securing LLM apps: prompt injection and the OWASP Top 10 for LLMs
In short: LLM applications mix instructions and data in the same text, so attackers can hide instructions in input or documents. The OWASP Top 10 for LLM Applications lists the main risks. Defend with least privilege for tools, careful output handling, human approval for risky actions and good monitoring.
Why LLM apps need their own security thinking
A large language model (LLM) reads text and predicts a useful continuation. Applications wrap it with a system prompt (the developer’s instructions), user input, and often extra data pulled from documents or the web, known as retrieval-augmented generation (RAG). Many apps also let the model call tools: send email, query a database, run code. The core problem is that the model cannot reliably tell trusted instructions from untrusted data, because everything arrives as text.
Prompt injection
Direct prompt injection is when a user types instructions designed to override the system prompt, for example asking a support bot to ignore its rules and reveal internal notes. Indirect prompt injection is more dangerous: the instructions are hidden in content the model processes on someone else’s behalf, such as a web page, an email or a shared document. If an assistant that can send email summarises a poisoned message, the hidden text might tell it to forward private data elsewhere.
There is no complete fix today. Input filters and stronger system prompts help, but determined attackers find new wording. The reliable approach is to limit what a successful injection can do.
The OWASP Top 10 for LLM Applications
The OWASP project publishes a list of the most important risks for LLM applications. The 2025 edition covers:
| Risk | In plain terms |
|---|---|
| LLM01 Prompt Injection | Input changes the model’s behaviour against the developer’s intent |
| LLM02 Sensitive Information Disclosure | The app reveals personal, secret or confidential data |
| LLM03 Supply Chain | Risky third-party models, datasets, plug-ins or libraries |
| LLM04 Data and Model Poisoning | Tampered training or fine-tuning data plants bad behaviour |
| LLM05 Improper Output Handling | Model output used unchecked in HTML, SQL, shell or code |
| LLM06 Excessive Agency | The model has more tools, permissions or autonomy than it needs |
| LLM07 System Prompt Leakage | Secrets or logic placed in the system prompt are exposed |
| LLM08 Vector and Embedding Weaknesses | Flaws in RAG stores, such as poisoned or over-shared documents |
| LLM09 Misinformation | Confident but false output that people or systems trust |
| LLM10 Unbounded Consumption | Abuse that drives up cost or denies service |
Practical controls
- Least privilege for tools: give the model narrow, read-only functions where possible, using the end user’s own permissions, never a shared admin account.
- Human approval for high-impact actions such as sending external email, making payments or deleting data.
- Treat output as untrusted: encode before showing in a web page, use parameterised queries, never pass output straight to a shell.
- No secrets in prompts: keep API keys and access rules in code and back-end checks, not in the system prompt.
- Access control in RAG: only retrieve documents the current user is allowed to read.
- Limits and monitoring: rate limits, token budgets, logging of prompts and tool calls, and alerts on abuse.
Tip: test your own LLM app with red-team prompts in a non-production environment and with permission. Record which attacks succeeded and fix the design, not just the wording.
Practice
What is the difference between direct and indirect prompt injection?
Why should API keys never be placed in a system prompt?
An assistant can delete files when asked. Which OWASP LLM risk applies and how do you reduce it?
Key takeaways
- LLMs cannot reliably separate instructions from data, so prompt injection is a design risk.
- Indirect injection hides instructions in documents, emails or web pages the model reads.
- The OWASP Top 10 for LLM Applications gives a shared list of risks to review.
- Limit the blast radius: least-privilege tools, human approval, no secrets in prompts.
- Treat model output as untrusted input to every downstream system.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.