The LLM security guide: OWASP Top 10 and how to detect the risks
The OWASP Top 10 for LLM applications, translated from a checklist into detectable behaviors — what each risk looks like in a real trace, and how to catch it before it becomes an incident.
TL;DR: The OWASP Top 10 for LLM applications is the standard map of what can go wrong in an LLM system — prompt injection, insecure output handling, data leakage, excessive agency, and more. A checklist you read once doesn't protect anything; the value comes from turning each risk into something you can detect in a trace and score on live traffic.
Securing an LLM application is different from securing a normal app, because the attack surface includes the model's behavior itself. The OWASP Top 10 for LLM applications is the community's map of that surface. This guide walks the risks that matter most in production and, for each, what it looks like when you can see the trace — because a risk you can't observe is one you can't defend.
The risks that matter most in production
- Prompt injection — untrusted content (user text, a retrieved document, tool output) carries instructions that hijack the model. The signature risk, because the attacker doesn't have to be the user. (See how to jailbreak LLMs.)
- Insecure output handling — the app trusts model output and passes it into a shell, a SQL query, or the DOM. The model becomes an injection vector into your systems.
- Sensitive information disclosure — the model leaks PII, secrets, or another user's data from its context or training.
- Excessive agency — an agent has more tool permissions than the task needs, so a single manipulated step can take a real, damaging action.
- Overreliance — users (or downstream code) act on hallucinated output as if it were verified. This makes groundedness a security metric, not just a quality one.
- Supply-chain and model risks — compromised models, plugins, or datasets behave maliciously by design.
From checklist to detection
The security win is reframing each risk as an observable pattern in a trace and a scorable behavior:
| OWASP risk | What to detect in the trace |
|---|---|
| Prompt injection | Model following instructions that appeared in retrieved/tool content |
| Insecure output handling | Model output flowing unescaped into a tool, query, or render |
| Sensitive disclosure | PII/secrets present in an output; cross-user data in context |
| Excessive agency | Tool calls beyond what the task required |
| Overreliance | Low groundedness score on outputs users acted on |
You can only detect these if you trace the full interaction — the prompt, the retrieved documents, every tool call and its arguments, and the response. Logging the final answer alone hides exactly where the attack entered. (See observability for AI agents and tool calls.)
Defenses that actually hold
- Treat all non-system content as data, not instructions — isolate retrieved and tool-returned text so it can't reprioritize the model's rules.
- Never trust model output downstream — validate, escape, and sandbox it like any untrusted input before it hits a shell, query, or the DOM.
- Least privilege on tools — scope every tool so a manipulated step can't do more than the task needs. Treat each tool as a trust boundary. (See secure enterprise deployment strategies.)
- Score groundedness — so overreliance becomes a measured risk, not a hope.
- Evaluate adversarially and continuously — run red teaming into an adversarial dataset and score production traffic against it. (See run LLM evals on production traces.)
How Currai fits
Currai traces the whole interaction — prompt, retrieved context, each tool call and its arguments, and the response — so every OWASP risk has somewhere to be seen. You can score production traffic against security rubrics (injection resistance, leakage, groundedness), watch those rates across model and prompt changes, and turn any exploited trace into a permanent test case. The trace log also serves as the audit record for what the system did and when. See the LLM safety guide and the AI chatbot compliance guide, or start with Currai free.
Frequently asked questions
What is the OWASP Top 10 for LLMs?
A community-maintained list of the most critical security risks in LLM applications — including prompt injection, insecure output handling, sensitive information disclosure, and excessive agency — meant as the baseline threat model for anyone deploying LLMs.
What is the most important LLM security risk?
Prompt injection, because the attack can arrive through any content the model reads — a document, a web page, tool output — so the attacker never needs to be the person using the app. It underlies many downstream exploits.
How do I detect LLM security issues in production?
Trace the full interaction (prompt, retrieved context, tool calls, response) and score it against security rubrics on live traffic. Detection depends on seeing where an attack entered, which the final answer alone doesn't show.
Is LLM security the same as LLM safety?
They overlap. Security defends the system against attack and abuse; safety keeps the model's behavior acceptable. Jailbreaks and prompt injection sit in the overlap. (See the LLM safety guide.)