OWASP Top 10 for LLM Applications 2026: assume the model will be fooled

Two lists and their status as of October 2026

Anyone working with last year's materials has an outdated ranking in hand. The OWASP GenAI Security Project now maintains two separate documents, and both have changed over the past year.

• OWASP Top 10 for LLM Applications 2026. The publication page gives the date as 3 August 2026, the project repository as 4 August 2026. It replaces the 2025 edition and describes the risks of an application built on top of a language model.
• OWASP Top 10 for Agentic Applications 2026. Released on 9 December 2025; according to OWASP, more than 100 experts worked on it. It covers systems that plan on their own, call tools and act over multiple steps.

For the first time, the 2026 edition is not based on voting alone. According to Help Net Security, expert voting carried a weight of 75%, and the remaining 25% came from data on 6,639 real-world incidents from public vulnerability databases and a database of AI-caused harms. The same article quotes the project leads: stop trying to build a model that cannot be fooled, and build the system around it so that nothing important breaks when it is fooled.

On 1 September 2026, both lists were joined by the Agent Control Standard (ACS) – an open framework under which agents should be inspectable, traceable and instrumentable, with the ability to control their behavior at runtime. The standard is new; it is worth following, but not yet worth basing internal standards on.

What changed compared with the 2025 edition

All ten categories remained; the order and one name changed. The exact list is in the project repository, and a comparison with 2025 is summarized, for example, by Imperva.

The pattern is clear: risks that only exist while the application is running (permissions, consumption) moved up, and those for which application security has long-established defenses moved down. The drop of Improper Output Handling to tenth place therefore does not mean the problem has gone away – it means we know how to deal with it.

LLM Top 10: what each risk is and how to defend

The examples below are typical scenarios unless they link to a specific incident.

LLM01 Prompt Injection

The model does not distinguish instructions from data, so text in an email, document or web page can change its behavior. The 2026 edition explicitly includes instructions hidden in images and audio as well. A real case: the EchoLeak vulnerability (CVE-2025-32711) in Microsoft 365 Copilot, where according to a published analysis a single crafted email was enough to exfiltrate data without any user action; among other things, the attack bypassed both the prompt injection classifier and link redaction. Defense: treat input filtering as one layer, not a solution. What matters is what the model has access to and where data is allowed to go.

LLM02 Sensitive Information Disclosure

The model returns data the user should not have seen – from training data, from the context or from RAG. Typically an internal assistant over shared storage that answers from HR documents to anyone. Defense: authorization before retrieval (the index query runs with the user's permissions, not the service's), data minimization in the context, output filtering.

LLM03 Excessive Agency

The system has more tools, permissions or autonomy than the task requires. A ticket-reading agent with a token that can also delete repositories. Defense: narrowly scoped tools, separate identities, human approval for irreversible actions.

LLM04 Supply Chain

Models, adapters, datasets, plugins and extensions are dependencies like any other. A real case: in July 2025, malicious code made it into version 1.84.0 of the Amazon Q Developer extension for VS Code via an improperly scoped GitHub token in the build configuration; according to the AWS bulletin, it did not execute due to a syntax error, and version 1.85.0 brought the fix. Defense: pinned model versions and hashes, verified provenance, dependency scanning – the same discipline as SCA for regular code.

LLM05 Data and Model Poisoning

Manipulated training, fine-tuning or embedding data changes the model's behavior. Defense: data provenance records, reviewing dataset changes just like code changes, regression evaluation before deploying a new model version.

LLM06 Unbounded Consumption

Uncontrolled inference exhausts budget or capacity – including “denial of wallet” attacks. Typically a public chatbot without limits, or an agent stuck in a loop of repeated calls. Defense: rate limiting, token and step limits per request, budget caps per user and tenant, alerting on cost anomalies.

LLM07 Misinformation

Confidently worded incorrect output, which does the most harm when automation builds on it. Defense: grounding answers in sources, validating structured outputs, human review for decisions with impact.

LLM08 Hidden Context Exposure

An extension of the original system prompt leakage to everything the application feeds the model without the user's knowledge: retrieved documents, tool definitions, memory, configuration. Defense: assume anything in the context can be extracted. No keys, passwords or authorization logic in the prompt – access is enforced by code outside the model.

LLM09 Vector and Embedding Weaknesses

RAG weaknesses: planted documents in the index, leakage between tenants, missing access control in the vector database. Defense: document-level permissions, separate indexes for different sensitivity levels, control over who may write to the index.

LLM10 Improper Output Handling

Model output is passed on without validation – to the browser, SQL, a shell. The principle is the same as with the injection flaws in the classic OWASP Top 10. Defense: model output is untrusted input; encoding for the target context, parameterized queries, schemas.

Agentic Top 10: when the model starts acting

The list for agentic applications does not repeat the LLM Top 10; it describes what gets added once the system is given tools, memory and other agents. The category names are listed in the OWASP announcement, which for ASI01 refers precisely to EchoLeak and for ASI02 to the Amazon Q incident.

The wording of the defenses in the table is based on a summary published by Cycode. The same text explains the principle of least agency: an agent gets only the degree of autonomy, tools and permissions it strictly needs.

Mapping to practices your team already has

Most of the defenses are not new. The only new thing is that the “user” with permissions is a non-deterministic component that can be persuaded by text.

Least privilege and identity

• Each agent has its own workload identity (IAM role, managed identity, service account), not a shared key or a developer's token.
• Permissions are enforced in the cloud and in the API, not in the prompt. The instruction “do not delete data” is not a control.
• Read and write tools are separate; writing to production requires approval.

Pipeline

• Prompts, tool definitions and agent configuration belong in Git and go through review.
• Models and MCP servers are pinned to a version and hash, much like images.
• An agent in CI has no access to production secrets; the Amazon Q incident started precisely with an overly broad token in the build. More detail in our article on CI/CD security.
• Evaluations and prompt injection tests run as a gate before deployment.

Isolation and network

Code generated by an agent should run in a sandbox with no outbound access by default. In Kubernetes, the foundation is a NetworkPolicy that denies egress and allows only DNS and a specific gateway to the model:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-sandbox-egress
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: agent-sandbox
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: llm-gateway
      ports:
        - protocol: TCP
          port: 443

The policy only works with a CNI that enforces NetworkPolicy. This is exactly what helps against EchoLeak-style exfiltration: even a successfully injected agent has nowhere to send the data.

Logging and limits

• Log every tool call: who, which agent, which parameters, what result. Without that, you cannot investigate an incident. It ties in directly with security monitoring and logging.
• A central model gateway handles rate limiting, budgets and audit in one place.
• Watch what goes into the logs: prompts and responses often contain personal or sensitive data.

Where the lists fall short and what can be criticized

• They are awareness documents, not standards. The Top 10 does not tell you how to verify that a control is in place. For an audit, you need your own requirements and tests.
• Their ranking is not your ranking. Three quarters of the weight comes from expert voting. For an internal RAG without tools, LLM02 and LLM09 come first, not Excessive Agency.
• Prompt injection has no reliable fix. Filters and classifiers reduce the risk, but EchoLeak showed they can be bypassed. Anyone promising complete protection at the model level is promising too much.
• Human approval has a ceiling. With dozens of confirmations a day, people click without reading – exactly what ASI09 describes. Reserve approvals for irreversible actions.
• Strict isolation has a cost. An agent without outbound access and with narrow tools is less useful. For a prototype on synthetic data, the full set of controls is unnecessary; for an agent with access to production, it is not.

What to do on Monday

Key takeaways

• The 2026 edition is the current one. It came out in early August 2026; Excessive Agency is third, Unbounded Consumption sixth, and System Prompt Leakage has become Hidden Context Exposure.
• Agents have their own list. ASI01–ASI10 from December 2025 complements the LLM Top 10 with identity, tools, memory and inter-agent communication.
• Assume the model will be fooled. Defense shifts from the model to the architecture: permissions, isolation, limits.
• You already know most of it. Least privilege, a secure pipeline, network segmentation and logging apply unchanged – just to a new type of workload.
• The list is not a certification. Adapt the ranking to your own architecture and verify controls with tests.