The OWASP Top 10 for LLM Applications is a community-maintained list of the most critical security risks specific to large language model applications, published by the Open Worldwide Application Security Project and updated periodically as new attack patterns emerge. The list typically covers prompt injection, where crafted input overrides intended instructions; sensitive information disclosure, where a model reveals confidential data from its training set or context; supply chain risks from third-party models, plugins, or datasets; data and model poisoning during training or fine-tuning; improper handling of model output that lets it trigger unintended code execution or actions downstream; excessive agency, where an application grants a model more autonomy or system access than a task requires; system prompt leakage; weaknesses in vector and embedding retrieval pipelines; overreliance on unverified outputs; and unbounded resource consumption that enables denial-of-service or runaway cost. Security and engineering teams use the list as a shared checklist during design review and penetration testing rather than as a compliance certification, and it maps well onto the categories a red team exercise should cover. The exact wording and ordering of items has changed between OWASP revisions, so teams should check the current version rather than an older cached copy. Nanobase AI structures its LLM security assessments around this OWASP framework so findings are comparable across projects.
Why this list exists separately from the classic OWASP Top 10
The original OWASP Top 10 for web applications covers risks like injection and broken access control, but it was not written with the specific failure modes of a language model in mind. The OWASP Top 10 for LLM Applications, maintained by the Open Worldwide Application Security Project and updated as new attack patterns emerge, fills that gap with risks specific to how LLMs process untrusted input, generate output, and increasingly take actions through tool access. Treating LLM security as "web security plus a chatbot" misses most of what is actually in this list, since several of the top risks have no real equivalent in traditional application security.
The list mapped to concrete mitigations
| Risk category | What it means | Primary mitigation |
|---|---|---|
| Prompt injection | Crafted input overrides intended model instructions | Instruction hierarchy design, input/output filtering |
| Sensitive information disclosure | Model reveals training data, system prompts, or other confidential context | Data minimization, output filtering, avoiding sensitive data in prompts |
| Supply chain vulnerabilities | Risks from third-party models, plugins, or training data of unclear provenance | Vendor due diligence, model provenance verification |
| Data and model poisoning | Training or fine-tuning data manipulated to introduce bias or backdoors | Data source vetting, anomaly detection in training pipelines |
| Insecure output handling | Model output executed or rendered without validation, enabling downstream injection (e.g., XSS) | Treat model output as untrusted input to downstream systems |
| Excessive agency | An AI agent granted more permissions or autonomy than its task requires | Least-privilege tool access, human approval for consequential actions |
| System prompt leakage | Confidential instructions or logic exposed through the system prompt | Avoid embedding secrets or sensitive logic directly in system prompts |
| Vector and embedding weaknesses | Vulnerabilities in RAG retrieval, including injected or poisoned embeddings | Ingestion-time scanning, access control on vector databases |
| Misinformation | Confident but incorrect output presented as fact | Retrieval grounding, output review for high-stakes use cases |
| Unbounded consumption | Uncontrolled resource use through excessive or automated requests, driving cost or denial-of-service risk | Rate limiting, usage quotas, cost monitoring |
The exact wording and ranking evolve between OWASP's published revisions, but these ten categories have remained the consistent core across versions as of 2026. Mapping each category to a specific mitigation, rather than treating the list as an abstract awareness exercise, is what makes it operationally useful.
Two categories that catch experienced teams off guard
Excessive agency and insecure output handling are the two categories most often underestimated by teams with strong traditional application security backgrounds. Excessive agency shows up when an agent is given broad tool access "to be safe for future use cases" rather than scoped tightly to its actual task, turning a successful prompt injection into a much larger blast radius than intended. Insecure output handling shows up when a model's output is passed directly into a downstream system, such as rendering it as HTML or executing it as code, without the same validation any other untrusted input would receive, effectively reintroducing classic injection vulnerabilities through the AI layer. A team with strong traditional application security instincts can still miss excessive agency and insecure output handling precisely because neither has a direct analog in pre-AI security review.
Using the list as an assessment structure
- Walk through each of the ten categories against the specific application, marking which are relevant given its architecture and tool access.
- For each relevant category, identify the current mitigation in place, if any, rather than assuming coverage because a general security review already happened.
- Prioritize gaps by the categories most relevant to the application's actual risk, such as excessive agency for a tool-using agent versus misinformation for a pure information-retrieval assistant.
- Use the list as a structure for red team test cases, ensuring adversarial testing covers categories systematically rather than opportunistically.
The OWASP list is most useful as a structured checklist during both design review and red teaming, not as a one-time reading exercise.
Frequently asked questions
Is the OWASP Top 10 for LLMs a compliance requirement?
No, it is a voluntary community-maintained resource, not a regulatory framework. It is, however, increasingly referenced in security questionnaires and vendor risk assessments as a recognized baseline for LLM application security.
Does the list apply to RAG systems specifically?
Yes, several categories, particularly prompt injection, vector and embedding weaknesses, and misinformation, are directly relevant to RAG architectures, covered in more depth in our guide to indirect prompt injection in RAG and agent systems.
How often is the list updated?
OWASP periodically revises the list as new attack patterns and defenses emerge in the field, so teams building a security program around it should check for the current version rather than relying on an older revision indefinitely.
Can automated tools check for all ten categories?
Automated tools can meaningfully test for several categories, such as prompt injection and unbounded consumption, but categories like excessive agency and supply chain risk require architectural and process review that automated scanning alone does not fully capture.
How Nanobase AI helps
Nanobase AI uses the OWASP Top 10 for LLM Applications as a structured baseline for both design review and red team testing, closing the gaps in excessive agency, insecure output handling, and prompt injection that generic application security reviews tend to miss. This is part of our AI security and compliance practice, alongside our dedicated red teaming work and hands-on guardrail implementation.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.