OWASP LLM Top 10 for 2026: the ten risks and where to enforce each

TL;DR

• The 2026 OWASP LLM Top 10 keeps Prompt Injection and Sensitive Information Disclosure at the top, lifts Excessive Agency from sixth to third and Unbounded Consumption from tenth to sixth, and drops Improper Output Handling from fifth to tenth.
• For the first time the ranking is checked against evidence: a practitioner vote carries three quarters of the weight and a classified corpus of 6,639 real incidents carries the rest.
• OWASP’s position on prompt injection is blunt: no reliable prevention exists, so defense is architectural. Least privilege, deterministic authorization outside the model and human approval for irreversible actions do most of the work.
• Controls for the ten risks sit in four places: application code, the model provider, an AI gateway in the request path, and the data and infrastructure layer. A gateway such as Bifrost enforces budgets, token limits, guardrails, tool allow-lists and logging, but authorization of an allowed action stays in application code.
• Agent-specific failures (goal hijack, tool misuse, rogue agents) now live in a separate OWASP Top 10 for Agentic Applications, which the LLM list says should be read alongside it.

The OWASP LLM Top 10, formally the OWASP Top 10 for LLM Applications, is the most widely used list of security risks in software built on large language models, and its 2026 edition, published by the OWASP GenAI Security Project in August 2026, reorders the list more than any revision before it. Excessive Agency jumps to third, Unbounded Consumption rises four places, Improper Output Handling falls to last, and System Prompt Leakage becomes Hidden Context Exposure. This guide walks the ten risks in the new order, gives a documented example of each, and maps every control to the layer that can enforce it: application code, the model provider, an AI gateway, or the data and infrastructure underneath. All claims come from the 2026 OWASP document, the 2025 risk pages and the vendor documentation cited inline, read in October 2026.

The OWASP LLM Top 10 and who publishes it

The OWASP LLM Top 10 is a ranked, community-written list of the ten most critical risks in LLM applications, maintained by the OWASP GenAI Security Project and licensed under Creative Commons BY-SA 4.0. Each entry gives a description, common examples, prevention strategies and attack scenarios.

The list has had four editions. Version 1.0 shipped on 1 August 2023 and version 1.1 on 16 October 2023, according to the revision history in the 2026 document. The 2025 edition followed on 18 November 2024. The 2026 edition appeared as a download on the project’s resource page dated 3 August 2026, a 122-page PDF led by Steve Wilson and Rock Lambros.

The method changed in 2026. Earlier editions ranked risks by practitioner judgment alone. This time the project collected 7,714 incidents from public vulnerability databases and an AI-harm database, classified the 6,639 that carried enough detail, and compared what practitioners fear with what the record shows. In the final ranking, the vote carries three quarters of the weight and the incident data one quarter. The project leads explain the choice directly: “one noisy year of data does not get to overturn the judgment of the people doing the work,” but a quarter weight “is enough to move an entry a tier when the gap between belief and evidence runs wide.”

Two disagreements shaped the list. Ranked by raw incident count, prompt injection falls out of the top ten, which the leads attribute to a defense effect: teams fight injection hard, so fewer clean exploits reach public databases. It stays first. Misinformation went the other way, voted near the bottom but near the top of the incident record, and it moved up two places as a result.

Changes from the 2025 list to 2026

The 2026 edition keeps the same ten risk areas as 2025 but changes six positions and renames one entry. The most consequential move is Excessive Agency rising from sixth to third, because, in OWASP’s words, “the vote and the record agree that agentic deployments are where the damage is landing.”

The 2025 entries remain online as individual pages, such as LLM10:2025 Unbounded Consumption, and many security tools and vendor pages still cite the 2025 numbering. When a report says “LLM06,” check which edition it means: in 2025 that was Excessive Agency, in 2026 it is Unbounded Consumption.

The 2026 document also draws a boundary that matters for any team running agents. The LLM list owns a risk “when the model is a component inside your application.” Once the model becomes an actor, with tools, memory and downstream consequences, the risk moves to the OWASP Top 10 for Agentic Applications. The section on the agentic list below covers that companion.

The ten risks at a glance

The ten 2026 risks fall into three groups by where they enter an application: inputs the model reads, the data and artifacts it is built from, and what happens to its output. Figure 1 places each risk ID on that path; the table gives a one-line definition and the layer that carries most of the control.

Figure 1: Every input lands in one token stream, so the controls that matter most sit after the model, where its output turns into actions.

The pattern behind the table is the one the project leads put in their opening letter: “Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.”

Input risks: prompt injection and hidden context

Prompt injection (LLM01) and hidden context exposure (LLM08) are both failures of the input boundary: the model cannot separate the developer’s instructions from text it was given to process, and it cannot keep its own instructions secret. OWASP’s guidance for both is to assume the boundary fails and to keep consequential decisions outside the model.

LLM01:2026 Prompt Injection

Prompt injection occurs when any input, “direct user input, retrieved content, tool output, image, audio, or video content, intermediate reasoning, or persistent memory,” alters the model’s behavior in ways the developer did not intend. The 2026 entry explains why it cannot be patched like SQL injection: models “make no architectural distinction between ‘instructions’ and ‘data’,” a point the UK’s NCSC made in its essay Prompt injection is not SQL injection.

The documented cases are concrete. The entry cites Aim Security’s zero-click attack on Microsoft 365 Copilot, in which a crafted email triggered data exfiltration and bypassed both the deployed injection classifier and the link-redaction filter. It cites a poisoned public GitHub issue that led an MCP-connected agent to exfiltrate private repositories, a production database dumped through Cursor’s Supabase MCP server running with a privileged service role, and the malicious postmark-mcp package, which blind-copied email to an attacker across an estimated 300 organizations. For retrieval systems, as few as five poisoned documents reached roughly 90% attack success against a knowledge base of millions of texts.

OWASP states that “no reliable prevention mechanism exists today,” consistent with NIST AI 100-2 E2025. Its eleven mitigations split into two kinds. Some reduce injection success and degrade against adaptive attackers: input classifiers, provenance-labeled channels, and stripping invisible Unicode (tag-block U+E0000 to E007F, variation selectors U+FE00 to FE0F, and zero-width characters). Others bound the blast radius: holding credentials and state-change capability in application code, routing privileged calls through a deterministic policy engine, and requiring human confirmation of the exact rendered action. The entry warns that research by Nasr and colleagues found static attack success near zero but adaptive success above 90% for most of twelve recent defenses, so a filter’s published block rate says little on its own.

Classifiers still have a place as one layer. Microsoft’s Prompt Shields scan for user prompt attacks and for document attacks hidden in emails or web pages, and Microsoft’s own documentation says they do not determine whether content is harmful, accurate or compliant. The Frontier Wire’s guide to prompt injection covers the attack classes in more depth.

LLM08:2026 Hidden Context Exposure

Hidden Context Exposure, formerly System Prompt Leakage, is the extraction or reconstruction of “hidden, non-user-facing system instructions or operational context.” The rename widens the scope from the system prompt to everything the application assembles into context out of the user’s view: developer instructions, retrieved policy text and the schemas of the tools exposed to the model.

The entry’s core instruction is to “design under the assumption that hidden context is discoverable.” Severity depends on what is in it. A prompt with no secrets and no security logic is informational. One that holds credentials or is relied on for authorization is high, and critical if disclosure chains to remote code execution or privilege escalation. Its three mitigations are short: keep sensitive data out of hidden context, enforce behavior with deterministic guardrails outside the model, and enforce authorization independently of the LLM. One scenario shows the quieter version of the risk: an attacker extracts the tool list and parameter schemas through conversation, discloses nothing secret, and gains concrete targets for the next injection.

Data risks: disclosure, poisoning and embeddings

Three entries concern the data a model touches: what it leaks (LLM02), what corrupts it (LLM05), and what the retrieval layer exposes (LLM09). Their controls sit mostly in data pipelines and indexes, with the request path handling redaction and logging hygiene.

LLM02:2026 Sensitive Information Disclosure

Sensitive information disclosure is exposure of confidential, regulated or proprietary data “through a channel the data subject, controller, or system owner did not authorize.” The 2026 entry is explicit that the final answer is only one channel: tool-call arguments, reasoning traces, retrieved chunks, logs, telemetry, embeddings and even measurable properties such as token length and cache-hit timing are all disclosure surfaces.

Its incident list spans the lifecycle. The March 2023 ChatGPT Redis bug exposed payment details for 1.2% of Plus subscribers. More than 4,500 shared conversations were indexed by Google in 2025 because of missing noindex directives. DeepSeek’s January 2025 database exposure leaked more than a million rows of logs and API keys. The Whisper Leak research classified conversation topics at over 98% AUPRC across 28 production models from encrypted traffic alone. The entry also notes that observability platforms “log full prompts, completions, chunks, and traces by default,” which turns a monitoring tool into a disclosure surface.

Mitigations come in three tiers. The foundational tier applies to every deployment: minimize the context sent to external providers, authorize “before retrieval” inside the index query rather than filtering afterward, keep secrets out of system prompts, sanitize with classifiers and named-entity recognition rather than regex alone, budget queries per user, and scrub logs and traces before they reach monitoring tools. Hardening and advanced tiers add differential privacy, gated log-probabilities, partitioned caches and confidential computing for regulated workloads.

LLM05:2026 Data and Model Poisoning

Data and model poisoning is manipulation of data or model artifacts to embed harmful behavior, bias or backdoors, anywhere data is “ingested, transformed, retrieved, or reused.” It differs from a runtime bug because the fix can require revalidating data, retraining or replacing the model.

The 2026 entry carries two numbers worth remembering. Souly and colleagues (2025) found that as few as 250 poisoned documents compromised models from 600 million to 13 billion parameters regardless of dataset size. Fogel and colleagues (2026) modified chat templates in redistributed model packages and, under trigger conditions, cut factual accuracy from 90% to 15% across 18 models and four inference runtimes. The mitigations track lineage with ML bills of materials, use data version control for rollback, treat chat templates, tokenizer configs and adapters “as security-relevant code,” and red-team for triggers after every alignment cycle, because safety training does not reliably remove backdoors.

LLM09:2026 Vector and Embedding Weaknesses

Vector and embedding weaknesses are attacks that exploit “the geometry of the embedding space and the mechanics of similarity search,” in retrieval-augmented generation, vector-backed agent memory and semantic caches. The entry’s summary is compact: “poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate.”

Each has a documented form. Inversion methods reconstruct source text from stored vectors, with Vec2Text reaching 92% exact reconstruction of short inputs, so an “embeddings-only” backup leak is a source-document leak. A single “blocker” document can make a retrieval system refuse a target query. Semantic cache poisoning, demonstrated end to end across AWS, Azure and Alibaba deployments by Wu and colleagues (2026), crafts content that lands just above a similarity threshold and serves attacker text to every equivalent query. The controls are mostly in the data layer: tenant scoping inside the index query, separate indexes per trust tier, provenance on every vector, no raw similarity scores returned to clients, and deletion of embeddings when the source is deleted. Teams choosing between retrieval and longer prompts can weigh this attack surface alongside the trade-offs in the Frontier Wire’s RAG versus long context analysis. The gateway-side version of the cache problem, where similarity thresholds decide what counts as the same question, is examined in a write-up on semantic cache grey zones.

Agency and output risks

Excessive agency (LLM03), misinformation (LLM07) and improper output handling (LLM10) all describe what happens after the model responds: an action taken, a decision made or a string executed. OWASP’s controls here are the most deterministic on the list, and most of them belong in application code.

LLM03:2026 Excessive Agency

Excessive Agency is “the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction.” Its root causes are three: excessive functionality (a read-only task given a tool that can also delete), excessive permissions (a tool connecting with an identity that holds UPDATE and DELETE when it needs SELECT), and excessive autonomy (deletions with no confirmation).

The entry’s canonical scenario is an email assistant given a mail tool that can send as well as read. A crafted incoming email tells the model to search the inbox and forward sensitive messages. OWASP lists three fixes, any one of which breaks the chain: a read-only tool, a read-only OAuth scope, or a human pressing send. The 2026 text adds two controls that matter for agents: preserve the original user’s authorization scope “across chained tool or agent calls,” and apply complete mediation, so a policy decision point outside the model validates every downstream request. It also recommends graduated enforcement (audit, warn, block, escalate), rate limits on tool invocations and circuit breakers.

The prompt injection entry adds a capability budget. Simon Willison’s lethal trifecta names the dangerous combination: access to private data, exposure to untrusted content and the ability to communicate externally. Meta’s Agents Rule of Two, which OWASP sets “as a floor,” turns that into a design rule, shown in Figure 2.

Figure 2: Removing any one of the three capabilities removes the conditions for high-impact prompt injection; keeping all three means a human approves each action.

LLM07:2026 Misinformation

Misinformation is output that is “incorrect, incomplete, unsupported, or misleading” yet credible enough to drive a human decision, an automated workflow or an agent action. The incident data pulled it up the list, and the leads single it out: “a wrong answer turns into a wrong action, and the record says that failure lands more often than the vote assumes.”

The scenarios are operational rather than reputational. A coding assistant recommends a package that does not exist, which an attacker has already registered. A retrieval agent reports a customer as identity-verified and a payment agent releases funds on that state. An agent reports that a nightly backup ran when it did not. The mitigations follow a “claim, check, act” pattern: separate generation from execution, verify claims and tool preconditions before acting, require structured outputs with mandatory fields to catch omissions, and limit the blast radius with least privilege and rate limits.

LLM10:2026 Improper Output Handling

Improper output handling is “insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems.” Because prompts control output, the entry likens it to “providing users indirect access to additional functionality.” The results are classic web and backend vulnerabilities: cross-site scripting, SQL injection, path traversal, server-side request forgery and remote code execution.

The 2026 edition adds two sinks. Terminals, logs and IDE panes that interpret ANSI escape sequences allow visual spoofing and clipboard hijacking. Chat interfaces that auto-render Markdown images let an attacker exfiltrate conversation data through an image URL’s query string. The controls are standard application security: treat the model as an untrusted user, follow the OWASP Application Security Verification Standard, use parameterized queries, apply context-aware encoding and a strict Content Security Policy, strip control characters before terminal output, and disable automatic fetching of external resources in chat renderers. The entry’s drop to tenth reflects the vote, not a smaller risk; OWASP also folded the insecure code that assistants generate at scale into it.

Supply chain and unbounded consumption

The remaining two entries sit at opposite ends of the stack. Supply chain (LLM04) concerns what gets deployed before any request arrives, while unbounded consumption (LLM06) concerns what each request is allowed to cost once it does, which makes it the entry most directly enforceable in the request path.

LLM04:2026 Supply Chain

LLM supply chains are vulnerable through “training data, models, adapters, conversion pipelines, and deployment platforms.” The 2026 entry treats model artifacts, provenance and conversion workflows as first-class attack surfaces. Its examples include a heap overflow in llama.cpp’s GGUF parsing (CVE-2024-23496), a remote code execution in Ollama through a malicious model manifest (CVE-2024-37032), the ShadowRay attacks on unauthenticated Ray dashboards, and model namespace reuse, where an attacker re-registers a deleted author’s name on a public hub and pipelines that resolve models by name pull the replacement. It also names “slopsquatting,” registering package names that coding assistants hallucinate.

Mitigations combine classic software supply-chain hygiene with model-specific steps: a signed inventory extended to models and datasets with AI bills of materials, cryptographic model signing through the OpenSSF Model Signing project and Sigstore, immutable digests instead of mutable tags, and treating conversion and merge services as high-risk promotion points. OWASP notes that signing “proves integrity and origin, not safety.” For agent tooling, the entry hands MCP servers and tool registries to the agentic list, and OWASP also runs a dedicated MCP Top 10 project; the Frontier Wire’s comparison of MCP security tools maps products against it.

LLM06:2026 Unbounded Consumption

Unbounded consumption occurs when an application “allows excessive and uncontrolled inferences,” enabling denial of service, runaway cost (“denial of wallet”) or model theft through extraction. The 2026 entry stresses cost asymmetry: an attacker can trigger expensive computation at almost no cost to themselves.

New examples reflect current workloads. Reasoning models can be pushed into prolonged thinking loops by short, benign-looking prompts that pass input-size filters. Multimodal inputs convert into many more tokens than comparable text. Tool fan-out lets one task spawn hundreds of calls. A long agent session that re-reads its growing context goes, in OWASP’s example, from about $0.001 on the first turn to about $0.50 by turn 100, and no single request trips a rate limit.

The entry’s conclusion is that “traditional request-rate limiting alone is no longer sufficient.” It asks for limits on tokens per minute and per day and on estimated cost per request, “non-overridable budget ceilings per API key, user, team, and cloud account” that halt inference rather than merely alert, and agentic circuit breakers: step limits, recursion depth limits, time limits and per-run cost ceilings. Those are request-path controls, which is why this entry maps more cleanly to an AI gateway than any other. The economics behind it are covered in the Frontier Wire’s piece on the cost problem of reasoning models and the guide to LLM cost management at the gateway.

Mapping OWASP controls to enforcement layers

Every OWASP mitigation has to run somewhere, and most teams have four candidate layers: application code, the model provider’s own safety features, an AI gateway in the request path, and the data and infrastructure underneath. The table assigns each 2026 risk’s main controls to those layers, based on the mitigations listed in the OWASP document.

Two things stand out. First, application code appears in every row, and for LLM03, LLM07, LLM08 and LLM10 it carries the controls OWASP calls load-bearing. No external layer can decide whether a particular refund or deletion is safe in context. Second, the gateway column is filled for most rows but rarely carries the whole control. It is strongest for LLM06, where budgets and token limits are its native job, and useful as a uniform enforcement point for redaction, tool access and logging across every application that calls a model. The Frontier Wire’s explainer on how an AI gateway differs from an API gateway covers why token-aware controls need a separate layer.

How an AI gateway covers its share

An AI gateway enforces the OWASP controls that apply to every model call, regardless of which application sent it: identity, token and cost limits, content guardrails, tool access and logs. Several gateways document these controls, and they differ mainly in which ones ship in the core product and how tool calls are governed.

Bifrost, an open-source AI gateway written in Go, serves as the worked example here because its documentation covers every gateway cell in the mapping table, including MCP tool governance, and because its source is public, so the controls can be checked against code. It exposes 25+ providers and 10,000+ models through one OpenAI-compatible API, and Bifrost’s published benchmark reports 11 µs of added overhead per request at 5,000 RPS on an AWS t3.xlarge, documented on its benchmarking page. Figure 3 shows how its controls line up on a single request.

Figure 3: The gateway can bound consumption, filter content and restrict tools, but it cannot decide whether an allowed action is safe in context; that stays in application code.

Mapped to the 2026 entries, Bifrost’s documented controls are:

• LLM06 Unbounded Consumption. Budgets and rate limits attach to virtual keys, teams, customers and individual provider configurations, and rate limits count both requests and tokens. A request must pass every applicable level; a provider that exceeds its limits is excluded from routing and requests are blocked once budgets are exhausted. That matches OWASP’s call for token-aware limits and hard caps per key, user and team. The design of hierarchical budgets is examined further in an analysis of budget and rate limit architecture for multi-tenant LLM platforms.
• LLM03 Excessive Agency. MCP tool filtering is deny-by-default per virtual key: a key with no MCP configuration gets no tools, and a caller-supplied tool header can only narrow the allow-list, never widen it. Tool calls returned by a model are not executed automatically; in agent mode, only tools explicitly marked auto-executable run without application approval, and max_agent_depth (default 10) acts as the step limit OWASP recommends. How these pieces combine for agent fleets is described in a post on MCP access, audit and cost controls.
• LLM01, LLM02, LLM08 and LLM10. Guardrails run as CEL-defined rules on inputs and outputs of both model calls and MCP tool executions. Built-in providers include Secrets Detection (based on Gitleaks rules), a Custom Regex PII template and Prompt Guardrails, an LLM judge for natural-language policies; external profiles include Microsoft Presidio, Azure Content Safety, AWS Bedrock Guardrails, Google Model Armor and CrowdStrike AIDR. Redaction can apply at runtime, to logs only, or with reversible placeholders. The split between what ships natively and what integrates is laid out in Guardrails at the gateway: what Bifrost ships and what it integrates.
• LLM02 logging hygiene and monitoring. Built-in observability records inputs, outputs, tool calls, tokens, cost and latency per request, and disable_content_logging skips request and response content where logs would otherwise become the disclosure surface OWASP warns about.

Enterprise tier. Guardrails, signed audit logs of administrative activity, secret-manager integration (HashiCorp Vault, AWS and GCP) and role-based access control are part of Bifrost Enterprise. Bifrost Edge, in early access, extends the same policies to AI apps and MCP servers on employee machines, documented on the Edge product page.

Other gateways document parts of the same column:

• Cloudflare AI Gateway offers guardrails that flag or block harmful content categories in prompts and responses, data loss prevention scanning in both directions, and rate limiting.
• Kong AI Gateway has the AI Prompt Guard plugin, which applies regex allow and deny lists to user messages, and its AI Rate Limiting Advanced plugin, part of Kong’s AI Gateway Enterprise, rate limits on the token costs reported by providers.
• LiteLLM supports guardrails before and after model calls and budgets and rate limits for keys, teams and agent sessions, and its documentation links its own OWASP 2026 mapping.
• Azure API Management has an llm-token-limit policy for per-key token rates and quotas, and an llm-content-safety policy that sends prompts, completions, MCP tool traffic and A2A agent APIs to Azure AI Content Safety.

The Frontier Wire’s ranking of AI guardrails tools compares the content-filtering layer on its own.

Broader treatments of the gateway as a security layer include a survey of LLM gateway security for prompt injection, PII and audit compliance and an overview of GenAI security risks and controls for production apps.

The Frontier Wire’s rankings of open-source AI gateways and MCP gateways compare the products on more criteria than security.

The OWASP Agentic Top 10 and the boundary between lists

The OWASP Top 10 for Agentic Applications is a separate list, announced on 9 December 2025 and developed with more than 100 contributors, that covers risks once a model plans and acts across tools, memory and other agents. The 2026 LLM list maps every one of its entries to these agentic risks in an appendix.

The mapping shows why Excessive Agency climbed: it is the bridge between the two lists, mapped to seven of the ten agentic risks as their trigger or manifestation. A team running coding agents, MCP-connected assistants or multi-agent workflows needs both documents. MCP-specific threats such as tool poisoning, rug pulls and shadow MCP servers sit in a third OWASP project, the MCP Top 10, still in beta.

Using the list in a security review

The OWASP LLM Top 10 is most useful as a structured checklist for threat modeling and design review, not as a compliance standard. The 2026 document’s own advice is to “work all ten, start at the top, and build each of them for the day the model is turned against you.”

A review that follows the document’s structure has five steps:

1. Inventory every input surface. For each feature, list what reaches the context window: user text, retrieved documents, tool results, images, memory. The LLM01 entry suggests describing each injection path by delivery surface, propagation and encoding before choosing controls.
2. Score agent capabilities. Apply the Rule of Two to every agent: untrusted input, sensitive data, and state change or external communication. Any agent with all three needs per-action approval.
3. Assign each control to a layer. Use the mapping table above to decide what the application enforces, what the gateway enforces and what the data platform enforces, so no control is assumed to live somewhere it does not.
4. Test adaptively. OWASP asks teams to baseline with benchmarks such as AgentDojo and JailbreakBench, then red-team with the defense disclosed to testers, and to “reject static-only attack-success claims.”
5. Map to frameworks. Appendix A of the 2026 document pins each risk to MITRE ATLAS v2026.06, MITRE ATT&CK v19.1, CWE 4.20, NIST AI 600-1, the NIST AI RMF, the CSA AI Controls Matrix v1.1 and OWASP’s AIVSS scoring system, which shortens the path from an engineering review to an audit artifact.

The regulatory pressure is real but indirect. The LLM02 entry lists the EU AI Act, with high-risk obligations from August 2026, alongside GDPR, HIPAA, CCPA and ISO/IEC 42001 as regimes that apply to disclosure incidents. None of those laws cite the OWASP list as a requirement; it is a way of showing that known risks were considered.

Limits of the 2026 list

The 2026 edition is better evidenced than its predecessors, but it is still a consensus document with stated limits. A reader should know what it does not do before treating a ranking position as a measure of risk to a specific application.

• The ranking is mostly a vote. Three quarters of each position comes from practitioner judgment. The incident data covers one year and, as the prompt injection case shows, undercounts risks that defenders already fight hard.
• Rank is not severity for a given system. Improper Output Handling fell to tenth, but an application that pipes model output into a shell is exposed to remote code execution regardless of the list’s order.
• The document carries a placeholder. The 2026 PDF’s title page still reads “Publication date to be set,” although the project’s resource page dates it 3 August 2026. Teams citing it in audits should record the version and the download date.
• Agent risks are split across documents. The LLM list deliberately stops where the model becomes an actor, so a review that uses only this list will miss memory poisoning, inter-agent communication and rogue agents in depth.
• It is not a certification. No product or application is “OWASP LLM Top 10 compliant.” Vendor pages that claim coverage usually mean their feature maps to some of the mitigations in some of the entries.

The practical reading of the 2026 OWASP LLM Top 10 is that the model will be fooled and the system around it has to absorb that. Most of the work sits in application code: narrow tools, user-scoped permissions, deterministic authorization and validated output. The data layer owns retrieval and training integrity. An AI gateway is the natural place for the controls that must apply identically to every call, above all the token budgets and hard caps of Unbounded Consumption, plus tool allow-lists, redaction and logs. Teams that assign each control to one of those layers, and test them against attackers who know the defenses, will have covered what the list asks.