The OWASP LLM Top 10 has become the standard reference for AI application security — and, like every Top 10, it has also become a checklist teams fill in without testing. "We covered the ten categories" usually means someone read the ten descriptions.
This guide is the opposite: what each category means when your hands are on the system, what evidence proves exploitation, and where the real severity concentrates.
The starting point: map before you test
None of the ten categories can be assessed without a map of the surface. Before the first payload, document:
- Endpoints — who calls the model, with what authentication, under what rate limits.
- System prompts — the full text, including instructions injected dynamically.
- Tools and plugins — every function the model can invoke and what it can do.
- RAG pipeline — where the documents come from, who can write to them, how they are indexed.
- Data flow — what enters the context, what leaves it, what gets persisted.
Without that map, an LLM test is a trial-and-error session against a black box. With it, every category below has concrete targets.
LLM01 — Prompt Injection
What it is. Manipulated inputs that alter the model's behavior, bypass guardrails, or trigger unintended actions.
What to test. Separate direct from indirect. Direct injection (the user is the attacker) is the easy case and the least interesting. Indirect injection — the instruction arrives inside a retrieved document, a processed email, a page the agent browsed — is where the real incidents happen, because it does not require the attacker to have access to the system.
Evidence that counts. It is not the model saying something it should not. It is the model executing something it should not: an unauthorized tool call, data that crossed a tenant boundary, a write action triggered by third-party text.
LLM02 — Insecure output handling
What it is. The model's output is consumed downstream without validation — and becomes XSS, SSRF, command injection, or SQL injection.
What to test. Follow the output. Is it rendered as HTML? Passed to a shell? Interpolated into a query? Used as a URL? Each of those destinations is a traditional vulnerability with a new entry point.
Why it matters. This is the category that converts an AI problem into RCE. Treat the model's output exactly the way you treat untrusted user input — because that is what it is.
LLM03 — Training data poisoning
What it is. Manipulation of pre-training, fine-tuning, or embedding data to introduce bias or backdoors.
What to test. In application assessments, the practical target is rarely pre-training — it is the embeddings corpus. Who can write to the vector store? Does a support ticket submitted by a customer end up indexed? If so, write access control to the index is a first-order security control.
LLM04 — Model denial of service
What it is. Operations that degrade performance, inflate cost, or take the service down.
What to test. Context window exhaustion, recursive prompts, uncontrolled expansion of tool calls. Measure cost, not just latency: in agent architectures, a single input can trigger a cascade of paid calls.
LLM05 — Supply chain
What it is. Pre-trained models, datasets, plugins, and third-party extensions that carry vulnerabilities.
What to test. Provenance of the weights, integrity verification, serialization format, permissions of the installed plugins. The audit question is direct: if the model's source repository were compromised today, would you know?
LLM06 — Sensitive information disclosure
What it is. Exposure of PII, secrets, or system prompts through responses or side channels.
What to test. System prompt leakage (underestimated — it is the map of tools and limits), cross-tenant leakage in shared context, PII retrieved from documents the user should not reach. Verify access control at retrieval, not just at the interface.
LLM07 — Insecure plugin design
What it is. Tool integrations that allow unauthorized actions or code execution.
What to test. Every plugin as an API with no authentication, because in practice that is what it is: the model authorizes the call, and the model can be influenced by text. Are parameters validated? Is scope checked per user or inherited from the service? A plugin that runs with a service credential turns any injection into escalation.
LLM08 — Excessive agency
What it is. Permissions or autonomy beyond what is needed — exploitable for arbitrary actions.
What to test. Enumerate the actual capabilities and compare them with the declared use case. A read-only assistant with write permission, a triage agent with production access, an integration with an administrator token because "it was simpler."
Why it matters. This category is the severity multiplier for all the others. Reducing agency is the best cost-benefit mitigation in AI security — and it does not depend on the model resisting anything.
LLM09 — Overreliance
What it is. Trusting the model's output without validation — wrong decisions, vulnerable code, misinformation.
What to test. This is as much a process control as a technical one. Is there human review where the decision has consequences? Does generated code pass the same security gate as hand-written code? In financial or clinical workflows, does the model decide or recommend?
LLM10 — Model theft
What it is. Unauthorized extraction, replication, or exfiltration of proprietary models and weights.
What to test. Extraction through bulk querying, direct access to the weights artifact, exposure of the model serving endpoint. For most companies that consume third-party models, this is the lowest-priority category — which does not mean storage and access controls can be ignored.
Where the severity actually concentrates
Across the assessments we run, critical findings cluster in three categories: LLM02 (output handling), LLM07 (plugin design), and LLM08 (excessive agency). All three share one characteristic: they are not model flaws. They are flaws in the application around the model.
That has an uncomfortable practical consequence. Swapping the model for a better-aligned one solves none of them. What solves them is architecture — output validation, per-user authorization scope, least privilege on the tools.
LLM01 remains the category with the highest volume of findings. But volume is not severity: prompt injection on its own, in a system with no agency and validated output, is a nuisance. Prompt injection in an agent with write permission and tools running on a service credential is a compromise.
From report to decision
An OWASP LLM Top 10 test that delivers ten sections and a list of findings does not solve the CISO's problem, which is remediation order. What closes that gap:
- Reproducible evidence per finding — the payload, the response, the observable effect. If it does not reproduce, it is not a finding.
- Classification by business impact, not by OWASP category. LLM08 in a public chatbot and LLM08 in an agent with ERP access are not the same risk.
- A link to the kill chain. A finding that only enables stage 1 is different from one that chains all the way to exfiltration.
The Top 10 is a good coverage map. On its own, it is not a security program.
Our AI/LLM pentest covers all ten categories with reproducible PoC and AI-VRM classification. See also the Promptware Kill Chain for the model we use to chain findings together.