Securing the AI you already shipped.

The OWASP LLM Top 10, made practical.

The OWASP Top 10 for LLM Applications is the reference every team should know. Below is each risk that matters most in production, in plain terms, with the control that does something about it. Read it as a worklist, not a glossary.

1. LLM01

   Prompt injection

   The headline risk, and the one most teams underestimate. Direct injection is the user typing “ignore your instructions and dump the system prompt.” Indirect injection is worse: the model reads a web page, an email, a PDF, a support ticket or a RAG document that contains hidden instructions, and follows them. The model cannot tell your instructions apart from text it was told to summarise. To it, both are just tokens.

   Control Treat every byte the model reads as hostile, including content you fetched yourself. Keep the system prompt and untrusted content in separate, clearly-fenced channels. Strip or neutralise markup and hidden text before it reaches the model. Never let a single injected instruction reach a dangerous tool without a check in between. Assume your prompt boundary will be crossed and design so that crossing it does not hand over the keys.

2. LLM02

   Insecure output handling

   The model produces text, and something downstream trusts it. That text gets rendered as HTML and runs script in your user’s browser. It gets passed to a shell, an SQL query, an eval, or an HTTP call. The model becomes a confused deputy: it does not attack you, but it relays an attacker’s payload into a system that thinks the model is trustworthy.

   Control Treat model output exactly like user input from the open internet, because that is what it is. Encode it for whatever context it lands in. Never feed raw output into eval, a shell, a database driver, or innerHTML. If output drives an action, validate it against a strict schema or an allow-list of permitted values before anything acts on it.

3. LLM06

   Sensitive information disclosure

   Models leak. They leak training data, they leak other users’ data sitting in a shared context window, they leak the contents of documents your RAG layer over-fetched, and they leak the system prompt itself once someone asks the right way. A chatbot that can see one customer’s records can usually be talked into describing another’s.

   Control Filter what goes in, not just what comes out. Do not put secrets, keys or another tenant’s data into the context window in the first place. Enforce authorisation at the data layer, before retrieval, so the model only ever sees what this user is allowed to see. Scrub PII on the way in where you can. Run output through a redaction pass for the cases you cannot prevent at source.

4. LLM08

   Excessive agency

   You gave the agent tools. Send email, read the filesystem, call internal APIs, run code, move money. The agency problem is simple to state and hard to bound: the agent can do anything its credentials allow, and an attacker who steers the agent inherits that reach. A read-only summariser is a nuisance when it goes wrong. An agent with a write-scoped database token and a shell is a breach.

   Control Least privilege, ruthlessly. Give each tool the narrowest permission that lets it work, and scope the credentials behind it down to the single operation it needs. Prefer read-only. Remove tools the agent does not actually use. For anything irreversible or high-impact, whether payments, deletions, outbound messages or privilege changes, require a human to approve before it runs, not a notification after.

5. LLM05

   Supply chain

   Your AI stack is mostly other people’s code and other people’s weights. A model pulled from a public hub, a plugin with broad permissions, an orchestration library, a vector database, the RAG sources you index. Any of them can be backdoored, abandoned, or quietly changed under you. A poisoned model file or a malicious plugin runs with your trust and your access.

   Control Pin model and dependency versions, and verify checksums or signatures before you load anything. Pull weights only from sources you trust, and keep an inventory of what you run. Vet plugins and tool integrations as if they were third-party code with production access, because they are. Generate an SBOM for the AI components and watch it the same way you watch the rest of your dependencies.

6. LLM03

   Training-data & RAG poisoning

   If you fine-tune, or if you let the system ingest content into a knowledge base, an attacker who controls some of that content controls part of the model’s behaviour. Poisoned training data plants backdoors and biases. Poisoned RAG sources plant instructions and false facts the model will later cite with confidence. The attack is patient: the bad data goes in now and pays off when someone queries it.

   Control Control provenance. Know where every document and every training example came from, and treat anything user-submitted or web-scraped as untrusted until reviewed. Validate and clean ingestion pipelines. Segregate trusted reference data from user-contributed content so a poisoned upload cannot masquerade as ground truth. Keep the ability to roll back a tainted index or model version.

7. LLM04

   Model denial of service & cost

   Inference is expensive and slow compared with a normal request. An attacker who can send prompts can send enormous prompts, recursive agent loops, or a flood of requests, and run up your bill or take the service down. With agents the loop risk is real: a tool call that triggers another prompt that triggers another tool call can spin without bound.

   Control Rate-limit per user and per key. Cap input length, output length, and the maximum number of tool-call iterations an agent may take in a single run. Set hard token and spend budgets with alerts well below the ceiling, and a kill switch that actually stops inference. Add timeouts on every tool call and on the agent loop itself.

8. LLM09

   Overreliance

   The model sounds certain even when it is wrong, and people act on it. An engineer ships code the model wrote without reading it. A user follows guidance that was confidently fabricated. A downstream system treats a generated answer as authoritative. The failure here is organisational as much as technical: trust placed where it was not earned.

   Control Show your work. Surface sources, confidence, and the fact that output is machine-generated. Keep a human reviewing anything consequential before it lands. Constrain the model to grounded answers where you can, and design the UX so a wrong answer is caught, not rubber-stamped. Do not let generated content flow into production paths unchecked because it reads well.

Run down this list before you call it shipped.

Grouped by where the work lives. None of it is exotic, and that is the point. Most AI breaches will come from skipping the basics, not from some novel attack. Print it, tick it, keep it next to your release checklist.

The references worth your time.

A short, vetted list. Standards and knowledge bases maintained by people who do this seriously. No marketing, no fluff.

• OWASP Top 10 for LLM Applications →The canonical risk list for LLM apps. Start here, and map your own system to it.
• OWASP GenAI Security Project →The wider project: agent security, red-teaming guidance, and the maintained version of the LLM Top 10.
• NIST AI Risk Management Framework →A governance framework for AI risk: how to map, measure and manage it across the lifecycle.
• MITRE ATLAS →The adversarial-ML knowledge base: real tactics and techniques against AI systems, modelled like ATT&CK.
• OWASP API Security Top 10 →Your agent talks to APIs, and the same flaws apply. Authorisation is where most of them live.