When a new technology gets a shared risk taxonomy, the field grows up a little. The OWASP Top 10 for Large Language Model Applications — also called the OWASP AI Top 10, OWASP Top 10 for AI, or the LLM OWASP Top 10 depending on who's searching for it — is that taxonomy for AI. First published in 2023 (making "OWASP Top 10 2023" and "Top 10 OWASP 2023" accurate ways to describe its origin, alongside newer revisions since), it's a community-built, regularly updated list of the ten most critical risks in LLM-powered software. It is the closest thing we have to a common vocabulary, and if you build with LLMs, it is the checklist to know. Here is each risk in plain language, in the order OWASP presents it, with the defense that moves the needle.
LLM01: Prompt Injection
The signature risk. An attacker crafts input that overrides the developer's instructions, either directly (typed by the user) or indirectly (hidden in content the model ingests — a document, a webpage, an email). Because the model processes instructions and data through the same channel, there is no perfect fix. Defense: assume injection will land, constrain what the model can do afterward (least privilege, output handling), and treat every ingested source as untrusted.
LLM02: Sensitive Information Disclosure
The model reveals data it should not — training data, secrets in its context, another user's information, or confidential system details. Defense: minimize sensitive data in prompts and context, enforce access control before data reaches the model, and scrub outputs. Do not put a secret in a context window you would not put on a billboard.
LLM03: Supply Chain
The models, datasets, libraries, and plugins an LLM application depends on can be compromised — malicious weights, poisoned datasets, typosquatted packages, rug-pulled models. Defense: inventory every AI component (an AI bill of materials), pin and verify provenance, and scan dependencies. This is classic supply-chain hygiene extended to model and data artifacts.
LLM04: Data and Model Poisoning
An attacker corrupts training, fine-tuning, or embedding data to implant backdoors, bias, or degradation. Recent research suggests a small, near-constant number of poisoned documents can suffice, so dilution is not a defense. Defense: control who can contribute data, record data provenance, curate and deduplicate, and test models for triggered behavior — not just accuracy.
LLM05: Improper Output Handling
The application trusts model output and passes it, unsanitized, into a browser, a shell, a database query, or a downstream API — turning a generation into stored XSS (the same OWASP Top 10 XSS class that's plagued web apps for two decades, just with an LLM as the new injection source), command injection, or SSRF. Defense: treat model output as untrusted user input. Encode, escape, and validate it before it reaches any sink. This is often the single highest-leverage fix in a real codebase.
LLM06: Excessive Agency
An agent is granted too much functionality, too many permissions, or too much autonomy, so a manipulated or mistaken decision causes real damage. Defense: scope tools narrowly, give each agent its own least-privilege identity, authorize actions (not just sessions), and keep a human in the loop for high-impact, irreversible operations.
LLM07: System Prompt Leakage
The application relies on the system prompt to hide secrets or enforce controls, and an attacker extracts it — exposing credentials, logic, or the very rules meant to constrain the model. Defense: never put secrets or sole security controls in the system prompt. Treat the prompt as discoverable and enforce real controls in code and infrastructure.
LLM08: Vector and Embedding Weaknesses
In RAG systems, the vector store becomes an attack surface: embedding inversion leaks source text, index poisoning plants retrievable malicious content, and weak access control leaks one tenant's documents to another. Defense: enforce authorization at retrieval time, isolate tenants structurally, sanitize documents before indexing, and treat embeddings as sensitive data.
LLM09: Misinformation
The model produces confident, plausible falsehoods — hallucinations — that users act on, or overreliance leads teams to ship the model's mistakes. Defense: ground responses in verified sources with citation, add validation for high-stakes outputs, and design the UX so users treat output as a draft, not an oracle.
LLM10: Unbounded Consumption
An attacker (or a runaway loop) drives excessive inference — denial of wallet, resource exhaustion, or model extraction through high-volume querying. Defense: rate-limit and quota by user, cap token and cost budgets, monitor for anomalous usage, and time-box agent loops so they cannot run indefinitely.
Using the list well
The Top 10 is a prioritization aid, not a compliance box. Two patterns cut across almost every item. First, treat both inputs and outputs as untrusted — most of these risks are a trust boundary that was assumed rather than enforced. Second, constrain capability — the difference between an embarrassing bug and a breach is usually how much the model was allowed to do when something went wrong. Map your application against the list, find the two or three risks that apply most sharply to your architecture, and fix those first. If your team wants a more structured OWASP Top 10 tutorial or formal OWASP Top 10 training before doing that mapping, OWASP's own project pages and community workshops are the right starting point — OWASP doesn't issue its own OWASP Top 10 certification, but several training vendors build certificate programs on top of the same material.
How Safeguard helps
Several of these risks are, at bottom, ordinary application-security problems wearing AI clothing — and that is exactly where Safeguard operates. The Griffin AI detection engine inspects your code for the concrete sinks behind LLM05 (improper output handling), LLM06 (excessive agency), and LLM08 (vector weaknesses): generated output flowing unsanitized into a shell or a page, a tool wired to execute without authorization, retrieval that skips an access check. Auto-fix remediation proposes the corrected pattern rather than leaving you a ticket.
For LLM03 (supply chain) and LLM04 (poisoning), software composition analysis inventories the models, datasets, and libraries your AI application depends on — an AI bill of materials — and reconciles them against vulnerability and reputation data, so a compromised or poisoned artifact becomes a prioritized finding. For applications that expose an interface, dynamic testing exercises the running system to catch the injection and disclosure weaknesses behind LLM01 and LLM02. And because much of this work happens as code is written, Safeguard's MCP server surfaces findings and remediation guidance directly inside the AI assistants your engineers use.
The OWASP LLM Top 10 gives you the map. Create a free account or read the documentation to start closing the gaps it names.