The OWASP LLM Top 10, Translated for People Who Have to Sign Off on It
The OWASP Top 10 for LLM Applications has quietly become the closest thing the industry has to a shared security standard for AI. When a customer's security team asks about your AI, there's a good chance their questions map to this list — even if they don't cite it directly.
But the OWASP list is written for engineers. If you're the person who has to attest that the AI is safe — a CISO, a risk owner, a compliance lead, or a founder answering a security questionnaire — you need to know what each item means in practice and what to ask your team. Here's that translation.
1. Prompt Injection
What it is: An attacker crafts input that overrides the system's instructions — either directly ("ignore your previous instructions and...") or indirectly, by hiding instructions in a document or webpage the model later reads.
Why you care: It's the single most common and most exploited AI vulnerability. A successful injection can make the model leak data, produce harmful output, or — in an agentic system — take unauthorized actions.
The question to ask: For every workflow that processes text we don't fully control, what stops that text from changing the model's behavior? "Nothing" is the answer you're checking for.
2. Insecure Output Handling
What it is: Treating the model's output as trusted before it's validated. If output flows into a database query, a shell command, a browser, or another system, unvalidated output is an injection path into that system.
Why you care: This is how a prompt injection turns into a real breach. The model is tricked into producing malicious output, and the downstream system executes it.
The question to ask: Where does model output go, and is it validated before anything acts on it?
3. Training Data Poisoning
What it is: Corrupting the data used to train or fine-tune a model, introducing backdoors or biases.
Why you care: Mostly relevant if you train or fine-tune your own models. If you only call third-party models, your exposure is your provider's problem — but you should know which case you're in.
The question to ask: Do we train or fine-tune any models on data we ingest? If so, what controls the integrity of that data?
4. Model Denial of Service
What it is: Inputs crafted to consume excessive resources — very long inputs, or prompts that trigger expensive multi-step reasoning — driving up cost and latency.
Why you care: For AI, denial of service is often a denial of *budget*. An attacker (or a bad input pattern) can run your model bill up dramatically.
The question to ask: Are there limits on input size and per-request cost, and alerting when they're exceeded?
5. Supply Chain Vulnerabilities
What it is: Risk from the components your AI depends on — model providers, third-party plugins, datasets, and libraries.
Why you care: Your AI is only as trustworthy as its dependencies. A compromised plugin or an over-permissioned provider integration is your exposure.
The question to ask: What third-party AI components do we depend on, and what access does each have?
6. Sensitive Information Disclosure
What it is: The model reveals data it shouldn't — one user's data to another, internal system details, or confidential information embedded in prompts or retrieved context.
Why you care: This is the risk that most directly maps to your privacy and confidentiality obligations. It's also the one customers worry about most: "will your AI leak our data?"
The question to ask: What sensitive data can reach the model, and what prevents it from surfacing in the wrong output?
7. Insecure Plugin Design
What it is: Plugins or tools the model can call that accept unvalidated input or have insufficient access control — especially dangerous in agentic systems.
Why you care: When a model can take actions through tools, a weak tool is a weak point an attacker can reach through the model.
The question to ask: What tools can our AI invoke, what can each tool do, and how is their input validated?
8. Excessive Agency
What it is: Giving the model too much autonomy, functionality, or permission — so that a mistake or a manipulation causes real-world impact.
Why you care: As agentic systems spread, this becomes the dominant risk. A model that can only draft an email is low-risk; one that can send funds, delete records, or modify infrastructure is not.
The question to ask: What's the most damaging action our AI can take on its own, and is a human in the loop for the consequential ones?
9. Overreliance
What it is: Trusting AI output without adequate oversight — humans or systems acting on incorrect or hallucinated output as if it were reliable.
Why you care: This is where AI errors cause business harm. The model is confidently wrong, a person or system believes it, and a bad decision follows.
The question to ask: Where do we act on AI output automatically, and what's the check on it being wrong?
10. Model Theft
What it is: Unauthorized access to proprietary models — the weights, or enough queried behavior to replicate them.
Why you care: Relevant mainly if you have proprietary models that are themselves valuable IP. For teams using third-party models, low priority.
The question to ask: Do we have proprietary models worth stealing, and how is access to them controlled?
Turning the List Into an Assessment
The value of the OWASP LLM Top 10 isn't reading it once — it's checking every AI workflow you run against it, systematically. The gap most teams have isn't understanding the risks; it's not knowing which of their workflows are exposed to which ones, because no one has mapped it.
That mapping is the difference between "we're aware of prompt injection" and "here are our twelve AI workflows, here are the four that process untrusted input, and here's the mitigation on each." The second is what a security reviewer can actually accept.
Scan your AI workflows to see each one mapped against the OWASP LLM Top 10 and the other controls in the Security & Compliance dimension. Or read more about compliance readiness.