OWASP Top 10 for LLM Applications 2026: How to Secure AI Apps

The OWASP Top 10 for LLM Applications is the closest thing the industry has to a shared vocabulary for AI security, and in August 2026 it changed. The 2026 edition reorders eight of the ten entries, renames one and moves excessive agency into the top three. If your threat model, audit template or security backlog still says "LLM06 Excessive Agency" or "LLM07 System Prompt Leakage", it is citing the 2025 numbering.

This guide walks the 2026 list, then goes deep on what decides whether an LLM application survives attackers: prompt injection, data leakage, output handling and red-teaming.

What changed in the 2026 edition

The list is maintained by the OWASP GenAI Security Project. The 2026 edition was published in August 2026; its canonical source describes it as combining community judgment with analysis of real-world incidents. Many pages still show the 2025 numbering, so cite the ID with its year: LLM03:2026, not just "LLM03".

Prompt injection and sensitive information disclosure keep the top two spots. Excessive agency jumps from sixth to third: injections become incidents when the model can act. And System Prompt Leakage becomes Hidden Context Exposure, which also covers tool schemas, retrieved policy text and anything else placed in the context without being shown to the user.

A lower rank is not a lower priority for your system: Improper Output Handling sits at LLM10 and still produces cross-site scripting, SSRF and remote code execution wherever it applies.

The list treats the LLM as a component inside an application. Risks that appear when models plan, hold memory and act with delegated authority belong to the separate OWASP Top 10 for Agentic Applications (the 2026 edition, published in December 2025, IDs ASI01 to ASI10).

Turning this map into a threat model, guardrail architecture and test plan for a real system is the core of AI Security: Defending LLM Applications, which walks each category with implementation-level defenses.

The ten risks, one paragraph each

LLM01:2026 Prompt Injection

Any input that changes the model's behavior in ways the developer did not intend: a user message, retrieved document, tool result, image, audio or poisoned memory entry. Covered in depth below.

LLM02:2026 Sensitive Information Disclosure

Data exposed through a channel nobody authorized, and the final answer is only one channel: tool-call arguments, reasoning traces, retrieved chunks, logs, telemetry, embeddings and even timing or token length can all disclose.

LLM03:2026 Excessive Agency

Damaging actions performed in response to unexpected, ambiguous or manipulated model output, whatever caused the malfunction. The root causes are excessive functionality, excessive permissions and excessive autonomy.

LLM04:2026 Supply Chain

Compromised or unverified base models, LoRA adapters, datasets, conversion and merge pipelines, and packages. OWASP recommends extending your SBOM to models, adapters and datasets (an AI BOM).

LLM05:2026 Data and Model Poisoning

Manipulated data or artifacts that plant backdoors, bias or hidden behavior during pre-training, fine-tuning, embedding creation or retrieval. The entry also lists chat templates, tokenizer configs and quantization artifacts as security-relevant code.

LLM06:2026 Unbounded Consumption

Uncontrolled inference that causes outages, runaway cost ("denial of wallet") or model extraction. The 2026 entry stresses cost asymmetry, amplified by reasoning models, multimodal input and agent tool chains, and says request-rate limits alone are no longer enough: add token-aware cost controls, hard spending caps and agent-level circuit breakers.

LLM07:2026 Misinformation

Incorrect or unsupported output that is trusted and acted on, now a system-level failure because output drives tool calls, code and agent decisions. The recommended pattern is claim-check-act: verify claims before anything executes on them.

LLM08:2026 Hidden Context Exposure

Extraction or reconstruction of the system prompt, developer instructions, tool schemas and other hidden context. The guidance is blunt: assume hidden context is discoverable, put no credentials in it, and never rely on it for authorization or content policy.

LLM09:2026 Vector and Embedding Weaknesses

Attacks that exploit embedding geometry and similarity search rather than instruction following. OWASP's frame: "poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate."

LLM10:2026 Improper Output Handling

Model output passed downstream without validation, sanitization or encoding. The 2026 entry explicitly adds terminals and logs that interpret ANSI escape sequences, and renderers that auto-fetch Markdown images or link previews, an exfiltration channel.

Prompt injection, in depth

The UK National Cyber Security Centre put the core problem plainly in a December 2025 post titled Prompt injection is not SQL injection (it may be worse): current LLMs "simply do not enforce a security boundary between instructions and data inside a prompt." SQL injection has a structural fix, parameterized queries. Prompts have none: system prompt, user turn, retrieved documents and tool results arrive as one token stream.

Direct injection

The attacker types into the input box, intentionally (a jailbreak, which OWASP treats as the subset of prompt injection aimed at safety protocols) or not (a user pasting text that happens to contain conflicting instructions). It matters most when the person typing is not the person whose permissions the application uses, as in a public support bot connected to back-office systems.

Indirect injection

The model reads content the user never wrote and never saw: a web page, an email, a PDF, a ticket, a RAG passage, an MCP tool result, a database row. OWASP's 2026 entry sorts delivery surfaces by trust:

• Untrusted: public web pages, email from unknown senders, search results.
• Semi-trusted: public issue titles, package READMEs, third-party API responses.
• Trusted: your own repositories, databases and internal documents, which an attacker can still reach through a low-privilege channel such as a public bug-report form.

The trusted case is the one teams miss: the attacker plants text where your assistant will read it and waits for it to act with your credentials. OWASP's examples include a poisoned GitHub issue that led an MCP-connected agent to exfiltrate private repositories (Invariant Labs, 2025), and a production database dumped through an MCP server running with a role that bypassed row-level security (General Analysis, 2025). It also cites EchoLeak, a zero-click attack in which a crafted email made Microsoft 365 Copilot exfiltrate organizational data with no user interaction (Reddy and Gujral, 2025).

To threat-model a scenario, OWASP decomposes it along three axes: delivery surface (how it reaches the model), propagation (single-shot, multi-step, cross-session through memory or RAG, or self-replicating across agents) and encoding (plain text, Base64, invisible Unicode, steganographic images, low-resource languages).

Why detection alone fails

Classifiers and provenance labeling reduce attack success on static tests, then degrade against adaptive attackers who know the defense. OWASP cites Nasr et al. (2025), who found static attack success near zero while adaptive attack success exceeded 90% for most of 12 recent defenses. The 2026 entry concludes that no reliable prevention mechanism exists today, consistent with NIST AI 100-2 E2025.

Keep the filters, they catch unsophisticated attempts. But design as if the instruction boundary will be crossed, so that crossing it gains the attacker nothing.

Architecture that survives an injection

Two heuristics cited by OWASP turn that into design checks.

Simon Willison's lethal trifecta (2025): an agent that can access private data, ingest untrusted content and communicate externally has the conditions for exfiltration. Remove any one leg and the chain breaks. Meta's Agents Rule of Two (2025) generalizes it: treat (A) untrusted input, (B) sensitive data and (C) state change or external communication as a capability budget. OWASP's recommendation is to use it as a floor: an agent with all three needs per-action human approval, and an agent that combines untrusted input with either of the other two needs an explicit residual-risk assessment.

The remaining controls from LLM01:2026, in the order they pay off:

1. Hold credentials and state changes in application code, behind a deterministic policy layer that re-validates arguments at execution time.
2. Validate a strict output schema in trusted code. It catches format violations, not semantic manipulation, so it complements the policy layer.
3. Strip invisible characters at every ingest and render boundary: the Unicode tag block (U+E0000 to U+E007F), variation selectors (U+FE00 to U+FE0F) and zero-width characters (U+200B, U+200C, U+200D, U+2060).
4. Require human confirmation for irreversible or externally visible actions, showing the exact action, not a summary.
5. Treat memory writes as privileged: one poisoned entry reaches every future session.

A well-structured system prompt still matters for quality (see Prompt Engineering in 2026: From Beginner to Pro). It just cannot be your security boundary.

Data leakage: the channels you are not watching

Most leakage is not a clever extraction attack. OWASP names two structural failures behind most incidents: oversharing upstream (unscoped drives, legacy permissions and knowledge bases that feed sensitive data to RAG, which then retrieves it as designed) and persistence (once data shapes weights, embeddings or adapters, it stays extractable after the source is deleted).

The LLM02:2026 entry describes disclosure across four phases, and each needs its own control:

The most important rule for RAG systems: enforce document- and chunk-level authorization inside the index query, not in application code after retrieval. LLM09:2026 explains why: in a multi-tenant deployment, similarity search runs across the whole index before the application filters by tenant, and a probing tenant can infer the existence, topic and approximate volume of another tenant's documents from result counts, scores and timing. Isolate per-tenant indexes for high-sensitivity workloads.

Also treat reasoning traces as output under the same redaction rules, and assume (LLM08:2026) that everything in the system prompt will eventually be extracted.

Output handling: the model is an untrusted user

LLM10:2026 opens with a sentence worth putting on the wall: since LLM-generated content can be controlled by prompt input, passing it downstream is like giving users indirect access to that downstream functionality. The mitigations are classic web security: zero trust toward model output, context-aware encoding, parameterized queries and a strict Content Security Policy.

Two items the 2026 entry spells out deserve code. Markdown images are an exfiltration channel: an injected instruction asks the model to emit an image whose URL carries the conversation, and the client fetches it automatically. And terminals and log viewers interpret escape sequences. A minimal sanitizer for text you are about to render or log:

import re
from urllib.parse import urlparse

# Invisible characters listed in OWASP LLM01:2026: tag block,
# variation selectors, zero-width characters.
INVISIBLE = re.compile("[\U000E0000-\U000E007F\uFE00-\uFE0F\u200B\u200C\u200D\u2060]")
# ANSI/OSC escape sequences and other control bytes that terminals interpret.
CONTROL = re.compile(r"\x1b\[[0-9;?]*[ -/]*[@-~]|\x1b\][^\x07\x1b]*(?:\x07|\x1b\\)|[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]")
MD_IMAGE = re.compile(r"!\[([^\]]*)\]\(\s*<?([^)\s>]+)>?[^)]*\)")
ALLOWED_IMAGE_HOSTS = {"static.example.com"}

def sanitize_model_text(text: str) -> str:
    text = INVISIBLE.sub("", text)
    text = CONTROL.sub("", text)

    def keep_or_drop(match: re.Match) -> str:
        host = urlparse(match.group(2)).hostname or ""
        return match.group(0) if host in ALLOWED_IMAGE_HOSTS else "[image removed]"

    # An auto-loaded image URL can carry data out: only allow-listed hosts render.
    return MD_IMAGE.sub(keep_or_drop, text)

This is a last line of defense, not the first. Encode for the destination as well (HTML-escape before inserting into a page, never build SQL or shell commands from model text), and enforce the image allow-list in your Content Security Policy too, so a parser bypass in one layer does not reopen the channel.

Excessive agency: briefly, because it multiplies everything else

Excessive agency belongs to agent design, so here is the short version. The OWASP mitigations: minimize tools and what each can do, avoid open-ended tools (a file-writing tool, not a generic shell), minimize permissions, execute tools in the user's context, require approval for high-impact actions, apply complete mediation, and monitor and rate-limit tool use.

The pattern that matters most is that the model proposes and deterministic code disposes. Authorization comes from the session, never from the prompt:

from dataclasses import dataclass

@dataclass(frozen=True)
class ToolCall:
    name: str
    args: dict

# The model may only propose these calls, with exactly these arguments.
POLICY = {
    "lookup_order": {"args": {"order_id"}, "approval": False},
    "issue_refund": {"args": {"order_id", "amount_cents"}, "approval": True},
}
MAX_REFUND_CENTS = 5_000

def authorize(call: ToolCall, user, orders) -> str:
    rule = POLICY.get(call.name)
    if rule is None or set(call.args) != rule["args"]:
        return "reject"
    order = orders.get(call.args["order_id"])
    # Ownership is checked against the authenticated user, not the model's claim.
    if order is None or order["owner_id"] != user["id"]:
        return "reject"
    if call.name == "issue_refund":
        amount = call.args["amount_cents"]
        if not isinstance(amount, int) or not 0 < amount <= min(order["total_cents"], MAX_REFUND_CENTS):
            return "reject"
    return "needs_human_approval" if rule["approval"] else "allow"

An injected instruction can still make the model ask for a refund on someone else's order. It cannot make this function approve it.

Red-teaming your own LLM application

The last control in LLM01:2026 is the one most teams skip: test against adaptive attackers who have read your defenses, and distrust attack-success numbers from static test sets. A practical program has four parts.

1. Scope and rules of engagement. Test only systems you own or are authorized to test, in staging with production-like permissions and fake data, with written limits and an escalation contact.

2. A threat-driven test plan. For each feature, list its Rule of Two profile and delivery surfaces, then write attacks per surface: direct overrides, injections planted in retrievable documents, payloads split across fields, Base64 and invisible-Unicode encodings, image-borne instructions and hidden-context probes. A useful trick for LLM08:2026 is a canary string in the system prompt: if it ever appears in output or logs, you have a confirmed extraction.

3. Baselines plus humans. OWASP names AgentDojo and JailbreakBench as baselines for agents and jailbreaks. Open-source scanners such as NVIDIA's garak automate known probes. Then give skilled testers the full defense specification and let them adapt: adaptive testing is what produced the 90% figures cited above.

4. Regression, not a one-off. Every successful attack becomes a test case that runs on every prompt, model or tool change. In production, alert on canary hits, unusual tool-call sequences, token-spend spikes and refusals clustered around one user. Feeding those signals into a security operations workflow is covered in AI for Cybersecurity: Threat Detection and SOC Operations.

A pre-launch checklist mapped to the 2026 list

• LLM01 Delivery surfaces and Rule of Two profile documented per feature; invisible characters stripped.
• LLM02 Authorization inside retrieval queries; context minimized; logs and traces scrubbed.
• LLM03 Tools minimal and narrow; credentials outside the model; approval for irreversible actions.
• LLM04 Models, adapters and datasets inventoried with provenance; packages and MCP servers pinned and verified.
• LLM05 Write access to training data and RAG corpora controlled and logged; data versioned for rollback.
• LLM06 Token budgets, hard spending caps, timeouts and agent loop limits in place.
• LLM07 Claims grounded and verified before any automated action depends on them.
• LLM08 No secrets or authorization logic in the system prompt; canary string monitored.
• LLM09 Per-tenant isolation for sensitive indexes; ingest validated; vector store access-controlled.
• LLM10 Output encoded per destination; parameterized queries; CSP and image allow-list.

Frequently Asked Questions (FAQ)

What is the current version of the OWASP Top 10 for LLM Applications? The 2026 edition, published by the OWASP GenAI Security Project in August 2026: Prompt Injection, Sensitive Information Disclosure, Excessive Agency, Supply Chain, Data and Model Poisoning, Unbounded Consumption, Misinformation, Hidden Context Exposure, Vector and Embedding Weaknesses and Improper Output Handling (LLM01:2026 to LLM10:2026).

What is the difference between direct and indirect prompt injection? Direct injection arrives through the user's own input, such as a jailbreak typed into a chat. Indirect injection hides in content the model reads on the user's behalf, such as a web page, email, document, RAG passage or tool result, so the user never writes or sees the malicious instructions.

Can prompt injection be fully prevented? Not with current technology. OWASP's 2026 entry states that no reliable prevention mechanism exists, and the UK NCSC argues it may never be mitigated the way SQL injection was. The practical goal is to limit impact: least privilege, deterministic authorization outside the model, human approval for irreversible actions and capability budgets such as the Rule of Two.

Is the OWASP LLM Top 10 enough for AI agents? It covers the LLM as a component and includes excessive agency, but agent-specific risks such as tool misuse, identity and privilege abuse, memory poisoning and cascading failures across agents are covered in more depth by the OWASP Top 10 for Agentic Applications. Teams building agents should use both lists.

How often should we red-team an LLM application? Continuously, in the sense that every successful attack becomes a regression test. Deeper manual exercises with testers who know your defenses belong before launch and after any change that adds tools, data sources or autonomy.

Conclusion

The OWASP Top 10 for LLM Applications 2026 keeps prompt injection at the top, raises excessive agency to third and widens system prompt leakage into hidden context exposure. The thread through all ten entries: the model cannot enforce a boundary, so the boundary lives in deterministic code around it. Authorize retrieval in the index, keep credentials and decisions outside the model, treat every output as untrusted input, budget capabilities with the Rule of Two, and prove it with adaptive red-teaming that becomes regression tests. That is what making a model "trustworthy enough to put in front of a paying customer" means in practice, the core of the role described in What Is an AI Engineer?

Sources

• OWASP GenAI LLM Top 10 2026, OWASP GenAI Security Project
• Canonical source of the 2026 release, GenAI-Security-Project on GitHub
• Prompt injection is not SQL injection (it may be worse), UK National Cyber Security Centre, 8 December 2025
• NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST, March 2025