OWASP Top 10 for LLM Applications

Pilots do not fly from memory. Before every flight, someone reads a checklist out loud and someone else confirms each item.

They are not incompetent. The list exists because memory is unreliable under pressure, and because the industry decided long ago that the same mistakes should not have to be rediscovered by everyone individually.

The OWASP list for LLM applications is that checklist for AI features. It is maintained by people who read real incidents, it is refreshed as the field moves, and it is free.

Your job is not to memorise it. Your job is to read it and turn it into tests.

What the list is, and what it is not

It is a categorised list of failure modes for applications built on language models, with guidance on each. It covers ground this layer has already walked through in plain words: instructions arriving as data, secrets leaking out, untrusted content steering behaviour, features being given more power than the job needs, and the supply chain behind the model itself.

It is not a compliance certificate, and it is not a tool. Nothing scans your app and prints a score. It is a checklist, and like the pre-flight one it only works if a person reads it against a specific aircraft.

Why you should care about this

Because it turns "I have a bad feeling about this feature" into a line item somebody has to answer.

An engineering team can dismiss a tester's hunch. It is much harder to dismiss "this is item four on the OWASP list for LLM applications, here is our version of it, and here is the transcript." You have not become more senior; you have borrowed the authority of a list everybody in security already respects.

It also solves the blank-page problem. Nobody can invent every risk category from scratch, and the list is the fastest route from "we should test the security of this" to a charter with ten concrete lines in it.

How you turn it into tests

1. Read the current list, once, properly. An hour. Do not skim a summary.

2. Write one line per item: how would this show up here? Most items become a specific attempt against your specific feature. Items about model supply chains and training data may not apply at all if you are consuming a hosted model — write "not applicable, we use a hosted model" and move on. That is a real answer.

3. Rank by what your feature can reach. Every item is more serious when the feature has tools, credentials or customer data. This is your blast-radius table doing double duty.

4. Attempt the ones you can, by hand. Most of them you already know how to test from this layer: instruction override, poisoned content, data leaks, unbounded permissions.

5. Record what you tried and what happened. Item, method, result, rate, evidence. A clean negative with a method is worth reporting.

6. Turn every success into a regression case. Straight into the eval set, so it can never quietly come back.

7. Re-run it when the shape of the feature changes. A new tool, a new content source or a new integration moves several items at once.

Try this today

Take your feature and write the charter. One row per item, in your own words, with your own verdict. This is the whole deliverable.

Ten rows, half of them already tested by things earlier on this layer, and two questions nobody had an owner for. That page is a security review, produced by a tester, in an afternoon.

How to show you know it

The charter, with your own wording. Not the list copied out — your feature's version of each item. It proves you read it against something real.

Verdicts including "not applicable". Knowing which items do not apply to a hosted-model app is as much a sign of understanding as finding a bug.

One finding quoted against the list. "This is the untrusted-content case, and here is the transcript." It changes how the bug is triaged.

A named edition and a date. It shows you know the list moves, which most people citing it do not.