OWASP Top 10 for LLM Applications

OWASP published the 2026 edition of its Top 10 for LLM Applications on August 4, 2026. What makes this version different is that the ranking was checked against a body of real incident data instead of resting on practitioner opinion alone. Two entries moved several places, one was renamed outright, and the document now draws a hard boundary around where its own scope ends.

This guide walks AppSec, platform, and AI engineering teams through all ten categories. You get a plain description of each risk, what shifted since the 2025 list, and a defense playbook that runs across the SDLC and the Agentic Development Lifecycle (ADLC). If your models call tools and carry memory between sessions, read this alongside our guides to the OWASP Agentic Top 10 and the OWASP MCP Top 10.

What Is the OWASP Top 10 for LLM Applications?

The OWASP Top 10 for LLM Applications is a community-built list of the ten security risks most likely to break an application that has a large language model inside it. It covers prompt handling, retrieval, model supply chain, output sinks, and resource consumption. Each entry carries an identifier from LLM01 through LLM10.

The project sits under the OWASP GenAI Security Project alongside two sibling lists. The Agentic Top 10 covers what happens once a model gains tools, memory, and the authority to act. The MCP Top 10 covers the narrower protocol layer that connects an agent to external systems.

How the 2026 edition was built

Every earlier version of the list came out of a vote. Hundreds of practitioners ranked the risks, and the result was consensus about what worried people most. That vote still carries three quarters of the weight in 2026.

The other quarter comes from data. OWASP pulled a corpus of 7,714 real AI-related security incidents from public vulnerability databases and an AI harm repository, of which 6,639 carried enough detail to classify. Where belief and evidence disagreed sharply, even a quarter weight was enough to move an entry up or down a tier.

The two disagreements are the most useful part of the document. Prompt injection held first place despite a thin incident record, which OWASP attributes to a defense effect where heavy investment keeps successful attacks out of public databases. Misinformation went the other way, sitting near the bottom of the vote while ranking near the top of the incident record.

Why the OWASP LLM Top 10 Matters for AI Driven Development

LLM features have moved from experiments into revenue paths, internal copilots, and developer tooling. Cycode’s 2026 State of Product Security report found that 81 percent of organizations lack full visibility into how AI is used across the SDLC, and 65 percent report increased security risk from AI tooling. A model with database access and no output validation sits on top of both problems.

Model output now drives actions, not conversations

A chatbot that gives a bad answer wastes someone’s afternoon. A model whose output feeds a shell command, a SQL query, or a ticket queue turns a wrong answer into a wrong action. That shift is why Excessive Agency climbed from sixth to third and why Misinformation moved up two places.

Think about a coding assistant asked to review a service and file issues for anything broken. A hallucinated vulnerability becomes a critical ticket, and an on-call engineer loses three hours chasing something that never existed. Give that same pipeline write access to production and the failure gets considerably more expensive.

Existing AppSec tooling was not built to read prompts

SAST reads source code and SCA reads dependency manifests. Neither of them reads a system prompt, a tool schema, a retrieved document, or a vector store. That is where most of these ten risks actually live.

A clean scan tells you nothing about whether a poisoned RAG chunk just rewrote your model’s instructions. It also will not tell you that someone quietly removed the token cap on an inference endpoint last week. The gap widens with every new integration you add.

Compliance is catching up

The EU AI Act, ISO 42001, SOC 2, DORA, and the NIST AI Risk Management Framework all reach into automated decision making and traceability. Auditors have started asking who approved a model’s permissions and where its request logs live. An AI Bill of Materials covering models, frameworks, and connectors is becoming the artifact they expect to see.

One structural change in the 2026 edition helps here. The per-entry framework links from 2025 have been replaced with a single appendix that maps all ten risks to nine external frameworks, with pinned versions. For anyone building a compliance mapping, that appendix is worth the download on its own.

The OWASP LLM Top 10 Risks Explained

Below is a category by category walkthrough of the 2026 list. For each risk you get what it is, why it landed where it did, and the controls that do the most work. The table gives you the short version first.

LLM01:2026 Prompt injection

Prompt injection is what happens when text a model reads gets treated as an instruction it should follow. It can arrive directly from a user or indirectly through a document, a web page, a ticket, or a retrieved chunk. The 2026 entry widens the scope to cover cross-modal attacks, where the payload hides in an image, an audio file, or a video frame.

The reason it kept the top spot despite a thin incident record is worth sitting with. Fewer clean exploits reach public databases because teams spend real money stopping them, not because the surface shrank. An injection written into persistent memory or a RAG corpus does not expire after one session either.

The code-level version usually starts somewhere unglamorous:

• User input concatenated into developer or system role fields inherits the authority those channels carry.
• Cross-modal payloads hide in images, audio, and video that text filters never inspect.
• A poisoned memory or RAG entry taints every later read, not just the session that planted it.

LLM02:2026 Sensitive information disclosure

This is the one entry where the community vote and the incident data agreed completely. Models leak through memorized training data, through retrieved chunks the requesting user was never authorized to see, and through side channels like response timing. The answer is boring and effective, which is to authorize before retrieval rather than filter after generation.

Hardcoded provider credentials belong in this category too. An API key that a model can read is an API key an attacker can extract. Continuous secrets detection across repos, config files, and pipelines catches these before they ship.

Most disclosure shows up through one of three paths:

• Memorized training data surfaces verbatim when prompted the right way.
• Retrieval pipelines return records the requesting user has no right to see.
• Credentials sitting in config or context get read back out in a response.

LLM03:2026 Excessive agency

Excessive Agency climbed from sixth to third, the biggest single move on the list, and it is where the vote and the data agreed most clearly. A model that can call tools, modify files, send email, and hit cloud APIs with the deploying user’s privileges is a different animal from a chat box. Damage lands where agency lives.

Least agency is the principle to apply, meaning each integration gets the minimum autonomy and permission its task needs. Irreversible actions should sit behind a human approval that shows the raw operation rather than the model’s summary of it. If the deployment leans autonomous, the Agentic Top 10 picks up from there.

Three limits are worth setting this week:

• Give each integration the narrowest tool set its task actually needs.
• Require human approval on anything irreversible, displaying the raw action.
• Review automated identity permissions on the same cadence as human access reviews.

LLM04:2026 Supply chain

The supply chain entry dropped from third to fourth and absorbed artifact trust failures along the way. Base models, fine-tuned checkpoints, adapters, embedding libraries, and inference runtimes all enter your application from somewhere, and much of that somewhere is maintained by one person on a weekend. Unsafe serialization formats remain a reliable way to turn a model download into code execution.

The controls look like ordinary dependency hygiene applied to unfamiliar artifacts. Require signed releases, maintain an AI Bill of Materials across the ADLC, and run SCA policy before a component loads rather than after an incident. AI and ML packages carry CVEs like anything else.

The habits that carry over from ordinary dependency work do most of the job:

• Require signed releases and verified publishers before a component loads.
• Keep an AIBOM covering models, adapters, frameworks, and connectors.
• Watch CVE feeds for AI and ML packages the way you watch web frameworks.

LLM05:2026 Data and model poisoning

Poisoning covers contaminated pretraining corpora, manipulated fine-tuning sets, and compromised adapters. The 2026 entry absorbs fine-tuning subversion, which had been drifting toward becoming its own category. It sits fifth after dropping one place.

What makes poisoning awkward is the delay between injection and effect. A bad training run produces a model that behaves normally for most inputs and badly for the ones the attacker cares about. By the time anyone notices, the artifact has usually shipped.

That delay is why this one is hard to catch after the fact:

• Poisoned models pass general evaluation and fail only on attacker-chosen inputs.
• Dataset provenance is the only reliable record of what went into a training run.
• Integrity checks on adapters and checkpoints catch tampering before deployment.

LLM06:2026 Unbounded consumption

Unbounded Consumption rose four places, from tenth to sixth, on the back of a reframe. This is no longer really about denial of service. It is about cost asymmetry, where an attacker triggers wildly expensive computation for almost nothing on their side.

Extended thinking models, multimodal inputs, and long tool chains all multiply the cost of a single crafted request. Rate limiting by request count stopped being sufficient somewhere around the time reasoning models shipped. Token aware budgets and hard spending caps are what the entry now asks for.

Application code often hands attackers the lever directly:

• Never let user input set max_tokens, output limits, or logit_bias.
• Budget by token spend rather than by request count.
• Add circuit breakers that halt a chain when spend or step count crosses a threshold.

LLM07:2026 Misinformation

Misinformation is the finding that should make teams uncomfortable. Practitioners voted it near the bottom while the incident record placed it near the top, and that gap is the widest on the list. It moved up two places, which the project leads suggest is still conservative.

The 2025 framing treated this as users trusting fluent output too readily. That framing is now too narrow, because model output authorizes actions, generates production code, and coordinates other models. A confident wrong answer inside an automated pipeline becomes a wrong action nobody reviewed.

The failure chain here is short:

• Model output feeds tool calls that run before anyone reads them.
• Fabricated findings create real work for engineers chasing things that do not exist.
• Grounding and verification belong before the action, not after the incident.

LLM08:2026 Hidden context exposure

System Prompt Leakage was renamed to Hidden Context Exposure, and the rename carries real weight. The system prompt is only one slice of what the model sees. Tool schemas, retrieved policy text, configuration values, and developer instructions all sit in the same context window and are all potentially extractable.

OWASP frames this as an amplifier rather than a standalone risk. Leaked behavioral logic makes injection more targeted, and leaked tool schemas expand the surface for excessive agency. The guidance is to assume hidden context is discoverable.

Design as though the window is already public:

• Keep credentials and secrets out of the context window entirely.
• Treat tool schemas as disclosed information when you scope tool permissions.
• Stop relying on hidden instructions as a security control.

LLM09:2026 Vector and embedding weaknesses

This entry slid from eighth to ninth with its scope unchanged. Retrieval pipelines carry their own failure modes, including embedding manipulation, poisoned index writes, and context bleeding between tenants or sessions. A vector store is infrastructure, but it is also an attack surface.

Shared memory across users stays convenient right up until it becomes a disclosure incident. Long-lived indexes make it worse, because a single poisoned write keeps returning results months later. Nothing about a vector database enforces the access model your application assumes.

Isolation does most of the work here:

• Scope vector indexes per tenant and per task.
• Validate anything written into an index or into persistent memory.
• Treat retrieval permissions with the same rigor as database permissions.

LLM10:2026 Improper output handling

Improper Output Handling fell the furthest on the list, from fifth to tenth, but the entry actually grew. It now explicitly covers terminal and IDE sinks that render ANSI escape sequences, along with client renderers that auto-fetch external resources referenced in model output. That second one is a working exfiltration channel.

The drop in rank reflects everything above it becoming more urgent, not the risk going away. Model output that reaches a shell, a query, a browser, or a template is untrusted input arriving from an unusual direction. Encode and validate at the sink, the same as you would anywhere else.

Start by auditing the sinks you already have:

• Shells and subprocess calls that receive generated commands.
• Database queries and templates assembled from model output.
• Terminal and chat renderers that interpret escape sequences or fetch URLs on their own.

How to Mitigate the OWASP LLM Top 10

No single control closes this list. The project leads open the document with advice worth repeating, which is to stop trying to build a model that cannot be fooled and instead build the system around it so that when the model is fooled, nothing important breaks. That reframes the whole exercise as blast radius control.

Separate instructions from everything the model reads

This control set covers LLM01, LLM08, and LLM09. Keep privileged instruction channels static and never interpolate user or retrieved content into them. Validate writes into vector stores and persistent memory, and scope both per user and per task.

Assume the context window is readable and design so that nothing inside it is a secret. If a control depends on hidden context staying hidden, that control has already failed and nobody has noticed yet. The same rule applies to anything a retrieval pipeline hands back.

Three changes deliver most of the value:

• Build system and developer messages from static templates only.
• Wrap retrieved content in a clearly marked data boundary before it reaches the model.
• Reject or sanitize writes into memory and vector stores at the point of ingestion.

Cap agency before anything else

This control set covers LLM03 and reduces the damage from most of the rest. Give each integration the narrowest tool set and shortest-lived credential its task allows, then require human approval for anything irreversible. Show the raw action at confirmation time rather than a model-written summary of it.

Access reviews for automated identities should run on the same schedule as human ones. Most teams have never revoked a scope they granted during a proof of concept. That single habit closes more exposure than any detection rule will.

Start with the permissions you already granted:

• Inventory every tool and credential each model integration can reach today.
• Replace standing tokens with short-lived credentials scoped to a single task.
• Route deletes, payments, and merges through an approval that shows the raw call.

Secure what the model is built from

This control set covers LLM04 and LLM05. Maintain an AIBOM covering models, adapters, frameworks, and connectors, and require signed releases with verified provenance before anything loads. Watch CVE feeds for AI and ML packages the same way you watch them for web frameworks.

Serialization format matters more here than it does elsewhere. A model artifact that executes code on load is a supply chain compromise waiting for a download. Pinning versions is not enough when the risk arrives inside the artifact itself.

The supply chain work breaks down into three moves:

• Gate component loads on signature and publisher verification.
• Record dataset and checkpoint provenance for every fine-tuning run.
• Prefer serialization formats that cannot execute code when deserialized.

Put a price ceiling on inference

This control set covers LLM06. Enforce server-side caps on every consumption parameter, budget by token rather than by request, and add circuit breakers that halt a chain when spend crosses a threshold. Reasoning models and multimodal inputs make the ceiling more important than it was a year ago.

Cost controls also work as a containment mechanism for other failures. A runaway loop caused by a poisoned instruction gets stopped by the same budget that stops a deliberate attacker. Treat the spending cap as a safety control, not an accounting one.

Three limits belong in every deployment:

• Clamp every consumption parameter server side, ignoring whatever the client sent.
• Track spend per user, per tenant, and per session rather than per request.
• Alert and halt when token burn or step count exceeds the normal baseline.

Validate output where it lands

This control set covers LLM07 and LLM10. Encode and validate model output at every sink, including shells, queries, templates, and terminal renderers. Ground answers against retrieved sources and require verification before output authorizes an action rather than after.

The mental shift is treating generated text as untrusted input that happens to arrive from inside your system. Nothing about the model being yours makes its output safe to interpolate. Apply the same encoding discipline you would apply to a form field.

Work through the sinks in order of blast radius:

• Parameterize any query or command built from generated content.
• Strip escape sequences and disable auto-fetch in renderers that display output.
• Require a source or a check before generated content triggers a downstream action.

Enforce it at the developer edge

Most of this risk enters through the developer environment first, which makes the IDE, the CLI, and the pull request the places where policy actually holds. Intercept prompts and file reads before sensitive data leaves the machine, and gate merges on AI-specific policy rather than catching problems after deploy. Making the secure path the default path is the only version of this that survives contact with delivery pressure.

Post-deploy controls arrive too late for most of these categories. By the time a prompt injection reaches production, the untrusted content has already crossed several trust boundaries. Catching it at the point of authorship costs a fraction of what incident response costs.

Three places to put the guardrails:

• The IDE, where prompts and file reads leave the developer machine.
• The pull request, where AI-specific policy can block a merge.
• The CLI and pipeline, where agents and scripts run without anyone watching.

How Cycode Helps You Address the OWASP LLM Top 10

Cycode is the Agentic Development Security Platform, with controls across every layer this list touches. The ADLC Security capabilities govern the AI layer of development while the scanners handle the code that AI helps produce. Both run inside the workflows your developers already use.

The result is that these ten categories stop being something you track by hand. They become policy that runs where the work happens. Findings land in the same triage queues your team already works through.

• AI Risk Detection unifies AI findings into one violation category instead of scattering them across separate queues.
• SAST policies semantically analyze LLM API calls and catch untrusted input flowing into privileged instruction channels or user-controlled token limits.
• Change Impact Analysis reads every pull request and classifies its security impact against policies you define, covering the context-dependent risks static rules miss.
• AI Guardrails intercept prompts, file reads, and tool calls in the IDE and CLI before sensitive data leaves the developer machine.
• AI Visibility discovers the assistants, models, and connectors already in use, including the ones nobody registered.
• Maestro handles triage, exploitability validation, and PR-ready fixes by reasoning over the Context Intelligence Graph, so LLM risk stays correlated with the rest of your supply chain.

Book a demo to see how Cycode secures every layer of the Agentic Development Lifecycle.