A prompt security reference guide helps teams shipping LLM features avoid the mistakes that turn a helpful assistant into a liability. The OWASP Top 10 for LLM applications catalogues the risks unique to these systems — prompt injection, leaked training data, over-broad agency, insecure output handling, and more. This tool turns that list into something you can actually use: each risk with a definition, an example, a test pattern, and a mitigation checklist.
How it works
The guide is a structured dataset of the OWASP LLM Top 10. You filter by risk category to focus on one item or browse all ten. Each entry gives a plain-English definition, a concrete example of how the risk manifests, a test pattern you can adapt to probe your own application, and a mitigation checklist of concrete controls. Everything runs in your browser; nothing you view or copy is sent anywhere. Use it as a learning aid for engineers new to LLM security and as a baseline checklist during code review.
How to use it safely
Only run the test patterns against systems you own or are authorised to test, in a non-production environment with no real customer data — injection payloads can trigger real actions if your model has tool access. Treat the mitigation checklists as a starting point, not a finish line: defence in depth matters because no single control stops prompt injection completely. Pair input validation with least-privilege tool access (so a hijacked prompt cannot do much damage), output encoding (so model output cannot inject into downstream systems), and human approval for high-impact actions. For production systems handling sensitive data, follow up with a full threat model and an independent penetration test — this guide raises your baseline, it does not replace expert review.
The ten risk categories at a glance
The OWASP LLM Top 10 clusters into a few natural families worth understanding before diving into individual entries:
Input attacks — prompt injection (direct and indirect) sit here. A user directly asks the model to ignore its instructions; indirect injection hides the override inside a document the model retrieves and reads, making it much harder to catch with simple keyword filters.
Output attacks — insecure output handling means the model’s response lands in a downstream system (a browser, a SQL query, an email) without being sanitized, letting the model’s output act as an injection payload in a completely different attack surface.
Supply chain and data — training data poisoning and model or plugin supply chain risks cover the integrity of what the model learned and what third-party components it calls. These are harder to detect at runtime but increasingly important as fine-tuning and plugin ecosystems grow.
Agency and access — excessive agency and insecure plugin design describe what happens when a model that can act (call APIs, read files, send emails) is manipulated or misconfigured. The damage from a prompt injection is bounded by what the model is allowed to do, which is why least-privilege tool access is the single highest-leverage control.
Information disclosure — sensitive information disclosure and training data extraction cover cases where a model leaks personal data, confidential context, or memorized training examples.
What good mitigation looks like in practice
A useful mental model: treat every piece of user input as potentially adversarial, treat every piece of model output as potentially unsafe for downstream systems, and assume every tool the model can call could be invoked against your intentions. That framing leads naturally to sandboxing, output encoding, human approval for consequential actions, and rate limiting — the layered approach the OWASP list recommends. Engineers new to LLM security often focus on blocking “bad” prompts; experienced teams focus on minimising the blast radius when an injection succeeds.