Wiki · Concept · Last reviewed June 25, 2026

OWASP Top 10 for LLM Applications

The OWASP Top 10 for LLM Applications is a security-awareness reference for applications that embed large language models, prompts, retrieval, tools, model providers, data pipelines, vector stores, and generative-AI outputs into software systems.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI security, OWASP, LLM applications, prompt injection, governance

Snapshot

Definition

The OWASP Top 10 for Large Language Model Applications is an OWASP GenAI Security Project awareness document for developers, data scientists, application-security teams, platform engineers, and governance reviewers building applications and plug-ins that use LLM technologies. OWASP's project repository describes it as a standard awareness document, a broad-consensus reference for critical LLM application risks, and a project scoped to LLM application security.

It is not a statute, certification scheme, vendor attestation, or guarantee of safety. It is a vocabulary and review scaffold. It helps teams discuss recurring places where LLM-backed systems fail: instruction boundaries, secrets, dependencies, training and retrieval data, output handling, delegated actions, system prompts, vector stores, factual reliability, and resource consumption.

The useful unit of analysis is the deployed application, not the base model alone. A model that is low risk in a sandbox can become high risk when connected to private documents, enterprise search, code execution, email, ticketing, browsers, databases, production APIs, or a vector index that mixes tenants and trust levels.

Current Context

As of June 25, 2026, OWASP's released LLM list is the 2025 Top 10. OWASP's resource page dates the 2025 guide to November 17, 2024, and the GenAI Security Project's LLM Top 10 page still labels the current LLM list as "2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps." The OWASP Foundation project page now points readers to the GenAI Security Project for the latest LLM list. That date and source path matter because earlier OWASP LLM versions used different category names and ordering.

OWASP separately released the Top 10 for Agentic Applications for 2026 on December 9, 2025. That 2026 agentic list should not be treated as a replacement for the 2025 LLM list. It covers a narrower class of systems that plan, use tools, coordinate, or act across workflows. A chatbot, RAG tool, summarizer, or coding assistant can be in scope for the LLM list even when it is not agentic.

Other official guidance fills different layers. NIST AI 600-1, the Generative AI Profile, frames generative-AI risk management under Govern, Map, Measure, and Manage. NIST SP 800-218A adapts the Secure Software Development Framework for generative AI and dual-use foundation models. CISA, UK NCSC, and partner agencies frame secure AI system development across secure design, development, deployment, and operation. The OWASP LLM list is most useful when paired with those lifecycle and governance frameworks rather than treated as a standalone compliance checklist.

How It Works

The OWASP GenAI Security Project's 2025 list names ten categories: LLM01 Prompt Injection; LLM02 Sensitive Information Disclosure; LLM03 Supply Chain; LLM04 Data and Model Poisoning; LLM05 Improper Output Handling; LLM06 Excessive Agency; LLM07 System Prompt Leakage; LLM08 Vector and Embedding Weaknesses; LLM09 Misinformation; and LLM10 Unbounded Consumption.

The categories cover both model behavior and surrounding application design. Prompt injection names cases where user input, retrieved content, or external data alters intended behavior. Sensitive information disclosure covers leakage of private, confidential, or restricted information. Supply-chain risk includes models, data, packages, plug-ins, and service dependencies. Poisoning covers corrupted training, fine-tuning, model, or embedding inputs.

The remaining categories focus on what happens after a model responds. Improper output handling describes insufficient validation or sanitization before model output reaches downstream software. Excessive agency addresses systems where the model can take consequential actions with too much permission. System prompt leakage concerns exposure of internal instructions. Vector and embedding weaknesses cover retrieval and similarity-search failure modes. Misinformation covers harmful reliance on false or misleading outputs. Unbounded consumption covers cost, capacity, denial-of-service, and resource abuse patterns.

Category Evidence Map

The most useful way to apply the OWASP list is to translate each category into evidence that can survive design review, procurement, audit, and incident response.

Agent Context

The LLM Top 10 is broader than, and different from, the OWASP Top 10 for Agentic Applications. The LLM list applies to chatbots, retrieval-augmented generation, summarizers, coding assistants, enterprise search, classification, and model-backed workflows even when they do not qualify as autonomous agents.

Agentic systems inherit the LLM risks and add more. A tool-using agent can suffer prompt injection, disclose sensitive information, rely on poisoned retrieval, leak a system prompt, or consume resources without also being compromised through an agent-specific failure such as inter-agent communication or rogue workflow behavior. Good review keeps those two OWASP lists adjacent but separate.

This distinction is important for Model Context Protocol and tool ecosystems. MCP, browser automation, and plugin systems can add agent-specific risks such as token exposure, tool poisoning, missing authorization, and weak telemetry, but the underlying LLM categories still apply whenever prompts, retrieved content, model output, vector stores, or generated actions cross a trust boundary.

Governance and Safety

A governance program can use the LLM Top 10 as a design-review checklist. For each category, record the system boundary, data sources, model provider, prompts, retrieval stores, output consumers, tool permissions, logging, human review points, abuse controls, and incident owner. The list becomes useful when every category points to an artifact and an accountable team.

Procurement reviews should ask vendors which OWASP LLM categories they test, what evidence they preserve, how they handle prompt-injection reports, whether customer data enters training or logs, how vector indexes are protected, and how resource limits are enforced. Internal deployments should preserve the same evidence for auditors and incident responders.

Coverage should be risk-based, not ceremonial. A marketing chatbot, RAG search tool, coding assistant, claims-processing workflow, and database-connected agent need different evidence even when all are "LLM applications." The reviewer should be able to trace each relevant category to a control, test, owner, exception, and retest trigger.

The list also helps safety teams avoid a common category error: treating model behavior as the whole system. Improper output handling, supply chain, vector weaknesses, and unbounded consumption are often application, infrastructure, data, and operations problems. They cannot be solved by a safer prompt alone.

For high-impact deployments, OWASP evidence should connect to an AI system inventory, AI procurement record, AI bill of materials, model or system card, red-team report, audit trail, incident reporting process, and AI change management. Otherwise, "we use OWASP" is only a slogan.

Minimum Evidence Record

A serious OWASP LLM review should leave enough evidence for security, procurement, audit, and incident response without storing secrets or private prompts unnecessarily.

Failure Modes

Defense Pattern

Source Discipline

Claims about the OWASP LLM list should cite the 2025 source page, the specific LLM category page, or the project repository. Category names changed from earlier versions, so source notes should identify the year and label. Do not mix the 2025 LLM list with the 2026 agentic list or with MCP-specific security checklists.

The list is a security taxonomy, not a prediction that every LLM application will fail. It also is not proof that an LLM application is safe after a team checks ten boxes. The useful claim is narrower: these are widely recognized risk classes that should be reviewed with local evidence.

For current status, prefer OWASP GenAI Security Project pages, the OWASP Foundation project page, and official repositories over vendor blogs. For governance claims, cite NIST AI RMF, NIST AI 600-1, NIST SP 800-218A, CISA/NCSC secure-AI guidance, procurement records, audit reports, incident logs, and system documentation. Secondary explainers can help readers, but they should not carry claims about official category names, dates, or compliance duties.

Spiralist Reading

Spiralism reads the OWASP LLM list as a map of where language becomes infrastructure. A sentence can become an instruction. A retrieval result can become evidence. An answer can become code, a ticket, an email, or a decision record.

The practical lesson is sobriety. Once language is wired into systems of action, security cannot live only in the model. It has to live in provenance, permissions, boundaries, validation, logs, and the human habit of asking what authority a text has been given.

Open Questions

Sources

Return to Wiki