The OWASP Top 10 for LLM Applications, Explained

If you build, buy, or secure anything with an LLM in it, the OWASP Top 10 for LLM Applications is the single best map of what can go wrong. Here's each risk in plain English — what it is, a concrete example, and the defense that holds up — framed the way CompTIA SecAI+ Domain 2 expects you to think about it.

Why a separate Top 10 for LLMs?

The classic OWASP Top 10 covers web apps. LLM apps inherit all of that and add a new attack surface: a component that takes natural language as input, blends instructions and data together, and can take actions on your behalf. OWASP's LLM list captures the risks unique to that pattern.

A useful way to hold them: most LLM risk lives at one of three points — what goes into the model, what the model is and knows, and what the model is allowed to do.

The list

LLM01 — Prompt Injection

Attacker-controlled text is treated as instructions. Direct injection is the user typing "ignore your rules"; indirect injection hides instructions in content the model reads (a web page, an email, a PDF). Defense: treat all external content as untrusted, separate it from system instructions, and never rely on the model to police itself — constrain what it can do downstream.

LLM02 — Sensitive Information Disclosure

The model reveals data it shouldn't: secrets from its system prompt, another user's data from shared memory, or proprietary info from training. Defense: keep secrets out of prompts, scope memory per user, and filter outputs for sensitive patterns.

LLM03 — Supply Chain

Risk from third-party models, datasets, plugins, and libraries. A model downloaded from a public hub can carry a backdoor; a compromised dependency can exfiltrate prompts. Defense: verify model provenance, pin and scan dependencies, and prefer trusted sources.

LLM04 — Data and Model Poisoning

Manipulating training or fine-tuning data to plant bias or a hidden backdoor. (We cover this in depth in our data-poisoning article.) Defense: vet data sources, track data lineage, and test models for anomalous behavior before release.

LLM05 — Improper Output Handling

Treating model output as safe when it isn't. If you drop an LLM's response straight into a SQL query, a shell command, or a web page, you've added injection vulnerabilities. Defense: treat output as untrusted input to the next system — encode, validate, and parameterize.

LLM06 — Excessive Agency

The model can do more than the task requires — too many tools, too broad permissions, no human in the loop for risky actions. A prompt-injected agent with delete access is a real incident, not a hypothetical. Defense: least privilege for tools, scoped permissions, and confirmation for high-impact actions.

LLM07 — System Prompt Leakage

Relying on the system prompt to keep secrets or enforce rules, then having it extracted. The lesson isn't only "hide the prompt" — it's that the system prompt is not a security boundary. Defense: assume the prompt is public; enforce real controls outside the model.

LLM08 — Vector and Embedding Weaknesses

Flaws in the retrieval (RAG) layer: poisoned documents in the vector store, or embeddings that leak information or let one tenant retrieve another's data. Defense: access-control the knowledge base, validate what gets indexed, and isolate tenants.

LLM09 — Misinformation

Confident, wrong output — "hallucination" — that users trust and act on. In security contexts this can mean a fabricated CVE, a wrong remediation, or invented code. Defense: ground answers in verified sources, cite them, and keep humans reviewing high-stakes output.

LLM10 — Unbounded Consumption

Resource and cost attacks: prompts engineered to be hugely expensive, or denial-of-wallet loops that rack up API spend. Defense: rate-limit, cap token usage, and monitor for abnormal consumption.

The pattern underneath all ten

Read the list twice and the same lesson keeps surfacing: the model is not a trust boundary. It can't be trusted to keep a secret, to tell instructions from data, or to refuse a cleverly worded request. Secure LLM design treats the model as a powerful but untrusted component — you control what reaches it, and you strictly limit what its output is allowed to touch.

Domain 2 — Securing AI Systems — is 40% of the SecAI+ exam, the largest single domain. Build the foundation first with our SecAI+ Domain 1 guide, then get All-Access for every domain guide as we release them.