The OWASP LLM Top 10, in plain English (for people shipping features, not papers)
We’ve spent five days on the cost meter. Now the failure mode cloud never had: abuse. The industry already has a shared checklist for it — the OWASP Top 10 for LLM Applications — but like most OWASP docs it’s written for security engineers. Here it is for someone who just shipped an LLM feature and needs to know what can actually go wrong: each risk in plain English, the real incident that makes it concrete, and the one control that helps most.
(This is the 2025 list; OWASP revises it, so treat owasp.org as the source of truth. The point isn’t to memorize numbers — it’s to recognize the shapes.)
The ten, in plain English
- LLM01 · Prompt Injection. User-supplied text overrides your instructions, because to the model your system prompt and their input are the same thing — tokens. Incident: chat bots repeatedly talked into “ignoring previous instructions” and going off-script. Control: never treat the prompt as a security boundary; least privilege on anything the model can trigger. (Tomorrow’s whole lesson.)
- LLM02 · Sensitive Information Disclosure. The model surfaces data it shouldn’t — secrets in the prompt, another tenant’s data, PII. Incident: engineers pasting proprietary source code into ChatGPT, which then lived on a third party’s servers. Control: keep secrets and other users’ data out of the model’s context; scope everything per-tenant.
- LLM03 · Supply Chain. The model, library, adapter, or dataset you pulled in is compromised or unvetted. Incident-type: a backdoored or typosquatted model/package from a public hub. Control: pin and vet model/lib sources like any other dependency.
- LLM04 · Data and Model Poisoning. Bad training or fine-tuning data bends the model’s behavior — a backdoor trigger, a bias, a planted falsehood. Control: control and audit what goes into training and fine-tunes; treat training data as attack surface.
- LLM05 · Improper Output Handling. You trusted the model’s output as safe and rendered it, ran it, or fed it to another system — so an injected payload becomes XSS, SQLi, or SSRF via the model. Control: treat model output as untrusted input; escape/validate it exactly like user input before it touches a browser, a shell, or a database.
- LLM06 · Excessive Agency. You handed the model tools, permissions, or autonomy it can be tricked into misusing — sending email, moving money, calling APIs. Incident-type: an agent manipulated into taking an action it shouldn’t. Control: least agency — every privileged action gets a deterministic check in your code, not the model’s say-so.
- LLM07 · System Prompt Leakage. Your “hidden” instructions (and anything you foolishly put in them) get extracted. Incident: Bing Chat’s internal “Sydney” rules were coaxed out and posted publicly. Control: assume the system prompt is public; never put keys, data, or your only guardrail in it.
- LLM08 · Vector and Embedding Weaknesses. In RAG, your retrieval layer serves poisoned content, or leaks one tenant’s documents into another’s answers. Control: access-control the vector store per user/tenant; treat retrieved content as untrusted (that’s Day 8).
- LLM09 · Misinformation. Confident, wrong output that you’re legally and reputationally on the hook for. Incident: a tribunal held Air Canada liable for a refund policy its chatbot invented. Control: ground answers in real sources, constrain scope, and don’t let the bot make promises you’ll have to honor.
- LLM10 · Unbounded Consumption. Cost and denial-of-service with no ceiling — the runaway bill, the resource-exhaustion attack. Incident: this entire cost series. Control: the gateway, caps, quotas, and per-run breaker from Days 3–4.
The four that bite a small team first
You can’t threat-model all ten before shipping, and you don’t need to. On a small team, these four show up first and hurt most:
- LLM10 Unbounded Consumption — the surprise bill. (You’ve now got the controls for it.)
- LLM01 Prompt Injection — the front door to most of the others.
- LLM05 Improper Output Handling — the classic web vulns, re-entering through the model.
- LLM02 Sensitive Information Disclosure — the data leak, often through a careless prompt or a shared cache.
Four of the ten hit a small team first — start there.
Notice the throughline: none of this is exotic. It’s the appsec you already know — input validation, least privilege, output encoding, tenant isolation, rate limiting — pointed at a new, probabilistic target. That’s the whole reason a security-and-infra background transfers straight into this.
Next in the series — Day 7: prompt injection, demonstrated on my own bot — the one at the top of the list, broken on purpose so you can see exactly why “just tell it not to” isn’t a defense.
If you shipped an AI feature fast, some subset of these ten is live and unguarded right now — and finding which is exactly the audit I do. Every message comes straight to me — I read and reply to each one myself, usually within a day, and what readers send shapes what I build next. It’s just me for now, so that’s genuinely true; it won’t be forever. Send me your setup and I’ll tell you which of the ten actually apply to you — free, within a business day.