The OWASP Top 10 for LLM Applications, Explained

The table below shows both numberings. The 2025 numbers come from the OWASP list page and the 2026 numbers from Superwise's summary of the 2026 release, both as read in October 2026.

Sources for the numbering: OWASP LLM Top 10 and Superwise. Superwise also reports that prompt injection would drop out of the top ten on incident counts alone, and that the project leads kept it first because every model that reads untrusted input is exposed to it.

Prompt injection. OWASP's entry begins: "A Prompt Injection Vulnerability occurs when user prompts alter the" model's behavior or output in unintended ways (OWASP LLM Top 10). Cloudflare's summary separates direct injection, where the attacker overrides the system prompt through their own input, from indirect injection, where the attacker controls websites, files or other external sources the model reads (Cloudflare). Superwise's summary of the 2026 entry widens the scope to anything the model reads, including tool output and memory, and lists the controls that matter: keep credentials and state changes in application code, validate every response, label outside content by source, and require human confirmation for irreversible actions (Superwise). None of these stop injection outright. They limit what a successful injection can do.

Data and model poisoning. Someone manipulates the data a model learns from or retrieves, to plant bias, errors or hidden behavior. Cloudflare's summary of the list recommends securing the data supply chain, verifying the legitimacy of data sources and keeping the model from ingesting data from untrusted sources (Cloudflare).

Vector and embedding weaknesses. This entry covers the retrieval layer behind retrieval-augmented generation (RAG). OWASP lists unauthorized access to embeddings that contain sensitive data, leaks between users who share one vector database, embedding inversion that recovers source text, and poisoned documents. Its example is a resume with white-on-white text instructing the screening system to recommend the candidate. The core control is permission-aware retrieval with strict partitioning between user groups, plus validation of every knowledge source and immutable logs of retrieval activity (OWASP vector and embedding weaknesses).

The shared lesson for this group: anything that can reach the model's context is an input, and inputs need an owner, a source you trust and a permission check.

Sensitive information disclosure. OWASP's entry covers personal data, financial details, health records, confidential business data, credentials and legal documents leaking through model output. Its mitigations include sanitizing data before it is used in training, applying least privilege so the model only sees data the current user may see, limiting the model's access to external data sources, telling users what not to enter, and publishing clear retention and opt-out policies (OWASP LLM02).

The practical rule is that the model should never hold data the current user is not allowed to see. If retrieval or a tool returns another customer's record, no instruction in the system prompt will reliably stop the model from repeating it.

System prompt leakage, or hidden context exposure. Attackers extract the hidden instructions behind an application. The prompt itself is rarely the real loss. Promptfoo's summary of the list notes that system prompts can contain information about a system's restrictions or architecture, "such as API keys or special features" (Promptfoo). Superwise's example from the 2026 entry is a system prompt holding a tool's login credentials, which an attacker pulls out and reuses (Superwise). The control is to assume the system prompt will be read: keep credentials, internal URLs and authorization logic out of it.

Excessive agency. OWASP defines it as the vulnerability "that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," whatever the cause. It names three root causes: excessive functionality, excessive permissions and excessive autonomy (OWASP excessive agency). Its examples are concrete:

• A tool that only needs to read documents also modifies and deletes them.
• An extension meant to run one shell command fails to block other commands.
• A database connection used for reading has UPDATE, INSERT and DELETE rights.
• A tool acting for one user connects with a privileged account that can see every user's files.
• Deletions happen without any confirmation from the user.

The mitigations mirror the examples. Offer only the tools the feature needs, implement only the functions each tool needs, avoid open-ended tools such as "run a shell command" or "fetch a URL", run tools in the user's own security context, and require human approval for high-impact actions. OWASP adds a principle worth quoting: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not" (OWASP excessive agency). Superwise reports that this entry rose from sixth to third in the 2026 edition, which reflects how many applications now let models take actions (Superwise).

Improper output handling. Model output flows into a browser, a database query, a shell or another service without checks. Cloudflare notes that this can lead to cross-site scripting, cross-site request forgery, server-side request forgery and remote code execution, and recommends treating the LLM "like any user or device" by validating its output before it drives other functions (Cloudflare). The standard web defenses apply unchanged: encode for the destination, use parameterized queries, and never pass model text to an interpreter.

Unbounded consumption. OWASP groups three attacks under one name: overloading the service until it stops responding, running up the bill under a pay-per-use model, and querying the model enough to clone its behavior (OWASP unbounded consumption). Its controls are familiar from API design:

• Validate input size so requests cannot exceed reasonable limits.
• Apply rate limits and per-user quotas.
• Set timeouts and throttle resource-heavy operations.
• Restrict the model's access to network resources and internal services.
• Log and monitor usage for anomalies.

For any product that pays per token, add a hard spending cap per user and per day, and alert when it trips. A runaway loop costs as much as an attack.

Misinformation. Models produce confident, wrong output, and people act on it. Promptfoo puts it simply: people trust incorrect model output much as they trust misinformation from websites (Promptfoo). Cloudflare recommends oversight policies and regular comparison of outputs with trusted external sources (Cloudflare). Superwise's 2026 example shows why this belongs on a security list: a coding assistant recommends a package that does not exist, and an attacker has already registered that name with malicious code (Superwise).

Supply chain. An LLM application depends on pre-trained models, adapters, datasets, packages, plugins and hosting platforms. Promptfoo lists outdated models without security patches and third-party software with security holes among the common problems (Promptfoo). Cloudflare recommends vetting suppliers, keeping an up-to-date inventory of components and scrutinizing supplied data and models (Cloudflare).

For most product teams, this means treating model files, model hosting providers and tool integrations the same way you treat open source packages: pin versions, record where each came from, review what each integration can access, and remove the ones you no longer use. OWASP's excessive agency entry gives a supply chain example that is easy to miss: a plugin trialled during development and dropped in favor of another, but still available to the agent (OWASP excessive agency).

The list is most useful as a set of questions asked once per LLM feature, before launch and after any change to the model, prompt or tools.

Superwise's guide sums up the common thread in its recommendations: inventory every LLM application and agent, enforce controls at runtime outside the model, log every request and tool call, and red team before release and after each model change (Superwise). Teams using Quanta Intelligence agents or building their own can run the table above as a pre-launch gate in the same way they run a code review.