OWASP LLM Top 10 2026: The Risks Explained

The current list is the OWASP Top 10 for LLM Applications 2026, published 3 August 2026. It replaces the 2025 list. If the system you are reviewing plans, calls tools, and acts on its own, you also need the separate Top 10 for Agentic Applications 2026, announced 9 December 2025. Most teams building on top of a hosted model need the LLM list first and the agentic list second.

The ten 2026 risks, in order: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, and LLM10 Improper Output Handling.

Four things moved enough to matter. Excessive Agency climbed from sixth to third. Unbounded Consumption rose four places, from tenth to sixth. Improper Output Handling fell the furthest, from fifth to tenth. System Prompt Leakage was renamed and widened into Hidden Context Exposure. The full 2025 to 2026 mapping is further down.

The 2026 edition is also the first one that checked the vote against evidence. The project leads say they pulled a corpus of 7,714 real incidents from public vulnerability databases and an AI-harm database, classified the 6,639 that carried enough detail, and weighted that record at a quarter against three-quarters for the community vote. That is why Misinformation moved up and why Prompt Injection stayed at number one despite falling out of the raw incident top ten.

The table below translates the official list into observable application behavior, a test, and a first fix. It also records three signals from a fixed AxonBuild cohort reviewed in June and July 2026. Those cohort figures describe the eligible apps reviewed, not all AI-built applications.

The OWASP LLM Top 10 for 2026

The unmeasured cells are intentional. A risk earns its OWASP slot because of its security significance, while a corpus frequency requires a defined eligible denominator and consistent measurement. Presence in one list cannot supply the missing denominator for the other.

OWASP’s list tells you which ten failure classes matter. It was never going to tell you whether your app is one of the apps that has them.

How these risks show up in AI-built apps

The ten risks are provider-neutral. The way they arrive in your codebase is not. Each builder has a default shape, and that shape decides which of the ten you inherit before you write a line of your own code. The product facts below come from each vendor’s own documentation; the risk shapes come from what the review cohort kept producing.

Lovable and other Supabase-backed builders. The database is the authorization boundary, and row level security is the thing enforcing it. Lovable’s own security documentation is explicit that the responsibility sits with you: “You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or critical functions.” Its basic scan lints RLS policies and flags overly permissive rules, which helps, but a lint is not a test. The risks this shape produces are LLM09 and LLM02: a vector table or a document table that the database will happily serve to the wrong tenant because the policy was written once and never checked with a second account. Start with how to test Supabase RLS with two accounts and whether RLS alone is enough.

Base44. The platform owns auth, data, and hosting, so your posture is whatever the per-entity permissions say. Base44’s own security overview puts that squarely on you: “You are responsible for your app’s security settings. Base44 provides the tools, but always review your permissions and run a security scan before you publish.” This is LLM02 and LLM03 territory. The model gets a tool that can read an entity, and the entity’s permissions were left open because nobody opened that screen. Our longer read on whether Base44 is safe covers the same boundary.

Bolt. Bolt “builds full-stack web applications using a wide range of JavaScript-based web frameworks”, runs the development environment in your browser, and hands you code you own and can push to source control. There is no platform guardrail between the generated app and production, so whatever the generator wrote is what ships. Across the cohort, the single most common thing missing from a generated AI endpoint was a login check and a spend cap, which is LLM06.

Replit. Replit Agent “sets up your project, creates applications, checks its work, and fixes problems along the way”, handling “writing code, setting up infrastructure, configuring databases”. The path from prompt to a public URL is short enough that nobody stops to ask who is allowed to call the expensive route. The risks are LLM06 first and LLM03 second, because agent-built apps acquire tools faster than they acquire permission checks. See is Replit safe.

Cursor and Claude Code. These write into your existing repository, so you review the diff and you own the result. The risk moves to LLM10. The 2026 edition widened Improper Output Handling to cover the insecure code that assistants generate at scale, which is the honest description of a suggestion that concatenates a value into SQL or drops model output into innerHTML. Our note on why AI coding tools ship security holes is the same failure seen from the generator’s side.

Firebase-backed builders. Firebase makes you choose at creation time: Locked mode denies access by default, and Test mode, in Google’s own words, allows “anyone access” to your data. A generated app that shipped in Test mode is an LLM02 finding waiting to be written up, and the rules file is usually the last thing anyone opens. Google’s guidance is blunt: “be sure to update your Security Rules before you deploy your app to production.” Confirm the current state on the Firebase Security Rules basics page.

Across all six, the pattern is the same. The generator produces the feature and leaves the boundary. Our audit statistics across 26 AI-built apps put numbers on that.

LLM01:2026 Prompt Injection

Prompt injection is when input to the model changes its behavior in a way the developer did not intend. The 2026 entry is explicit that the input need not be human-readable, need not come from a user, and need not be visible in the rendered interface. It can arrive as a chat message, a document, a web page, an email, a database row, an image, an audio track, or a row of persistent memory.

OWASP’s framing for why this is hard is worth quoting because it kills the most common bad fix: models make “no architectural distinction between ‘instructions’ and ‘data’ (both are tokens on the same stream), so there is no clean equivalent to parameterized queries.” Separating user text with delimiters can make the prompt clearer, but delimiters do not create a security boundary. Assume some hostile instructions will influence the output, then limit what that influence can accomplish.

Test each path where outside content reaches the model:

1. direct user messages and form fields;
2. uploaded files, images, and audio;
3. retrieved documents and search results;
4. emails, tickets, CRM notes, and database content;
5. tool output and messages from another agent;
6. stored conversation memory that carries between sessions;
7. URLs the system fetches or summarizes.

Attempt to override the task, reveal restricted context, change an output classification, select a prohibited tool, and act on another account. Then verify authorization and output controls outside the model still prevent harm. The rule is the same one AI-generated code keeps breaking: untrusted data must stay constrained even when the model treats it persuasively.

The clearest example I found was in a compliance-incident tool I audited, a Next.js app built to help teams document and grade security incidents against GDPR and HIPAA rules. The compliance verdict, the sentence saying an incident “is” or “is not” compliant, came from a model call that took the incident description straight from a text box and stringified it into the prompt with no delimiter and no instruction to ignore embedded commands. Confirming the finding meant doing the obvious thing: an incident description that ends by instructing the model to disregard the rubric and rule the incident compliant gets exactly that verdict. The steering text goes in the same field where a real incident description belongs, so the person being graded holds the pen.

LLM02:2026 Sensitive Information Disclosure

Sensitive information disclosure is when the system exposes confidential, regulated, privileged, or proprietary data through a channel nobody authorized. The 2026 entry stresses that the final answer is not the only channel: tool-call arguments, reasoning traces, retrieved chunks, logs, telemetry, embeddings, and observable inference properties such as timing and token length are all disclosure surfaces.

Map the data flow before testing. Record which fields enter the model, the provider and region that process them, retention settings, who can retrieve stored conversations, and which logs capture prompts or outputs. Minimize the data supplied to the model and redact fields that the task does not require.

Use two accounts and at least two roles. Ask account B for account A’s records through normal questions, indirect descriptions, search, exports, summaries, and references to known identifiers. Test whether a user can retrieve system prompts, secrets, hidden metadata, or other restricted content. Treat the result as an authorization test across the entire retrieval and tool chain.

One cohort example makes the point without any model involved. A health-data API decided which customer’s records to return based on a tenant identifier the caller supplied in a request header. Change the header, get another customer’s health data. The model sitting on top of that API was well behaved; it simply relayed whatever the data layer handed it. Fix the data surface, not the prompt.

The cohort’s “at least 5 of 21” PII/PHI figure includes application-layer exposures like that one, outside LLM output. It shows that sensitive-data boundaries deserve early testing. It does not establish that five apps had LLM02.

LLM03:2026 Excessive Agency

Excessive Agency is the most consequential move in the 2026 list, from sixth to third. OWASP’s reason is that the vote and the incident record agree: agentic deployments are where the damage is landing. The vulnerability is that damaging actions can be performed in response to unexpected, ambiguous, or manipulated model output, whatever caused the model to misbehave. OWASP names three root causes: excessive functionality, excessive permissions, and excessive autonomy.

List every tool and the identity used to call it. Remove tools the task does not need. Give each tool the narrowest resource and operation scope available. Derive the acting user and tenant outside the model. Require fresh approval before destructive, financial, public, cross-account, or otherwise high-impact actions.

Test whether the model can delete, send, purchase, publish, transfer, invite, change permissions, or retrieve another tenant’s data through indirect instructions. Verify retries and loops cannot repeat a valid side effect. Log the requested action, resolved actor, authorization decision, tool arguments, result, and approval event.

LLM04:2026 Supply Chain

An LLM feature can depend on a hosted model, client SDK, orchestration framework, embedding model, vector database, tool server, prompt package, dataset, and evaluation library. Each dependency can change behavior, gain access, or introduce vulnerable code. The 2026 entry adds one trust failure explicitly: a promoted model artifact that is not what it claims to be. Adapters shared as LoRA weights and conversion or merge workflows now count as first-class attack surface.

Maintain an inventory with source, version, integrity or signature evidence where available, permissions, data handled, update owner, and rollback path. Pin versions where the ecosystem supports it. Review release notes and security advisories before upgrades, and test the application’s critical behavior after model or dependency changes.

The provider relationship also matters. Document what is sent, what the provider retains, whether the data may be used for training, which subprocessors are involved, and which account controls apply. Use the current contract and product settings rather than assuming every API and consumer plan handles data the same way.

Supply-chain risk specific to agentic systems, including tool registries and MCP servers, sits in the agentic list under ASI04 rather than here.

LLM05:2026 Data and Model Poisoning

Poisoning changes training, fine-tuning, retrieval, or embedding data so later outputs favor an attacker’s goal. The 2026 entry widens this to absorb fine-tuning subversion, and it makes the operational point that matters most to a small team: poisoning targets the learning process, not a single runtime bug, so the fix can require data revalidation, retraining, or model replacement rather than a patch.

A small app that calls a hosted model with no fine-tuning has little control over pre-training. It can still expose writable knowledge bases, feedback loops, shared documents, or embedding pipelines.

Track provenance for content entering a knowledge source. Separate tenants, roles, trusted reference material, and user submissions. Require review for high-impact sources, scan or normalize uploads where appropriate, and preserve the ability to remove a source and rebuild affected indexes.

Test a hostile document that contradicts the trusted policy, includes injected instructions, or uses misleading metadata. Confirm its reach is limited to the intended tenant and that removing it removes its influence from future retrieval.

LLM06:2026 Unbounded Consumption

Unbounded consumption covers token, request, compute, memory, storage, and financial exhaustion. It rose four places in 2026, and OWASP’s stated reason is cost asymmetry: an attacker can trigger disproportionately expensive computation at negligible cost to themselves. The entry is also blunt that request-rate limiting alone is no longer enough, because reasoning models with large output budgets, multimodal inputs, and tool protocols that turn one request into cascading downstream calls all multiply the bill per request.

Require an authenticated actor where the feature is private or paid. Enforce per-user and per-organization request, token, file-size, context-size, concurrency, tool-call, and loop limits. Add timeouts, bounded retries, caching where safe, provider budgets, and alerts that fire before the hard limit becomes an outage.

This is the item with the starkest cohort signal: 12 of the 14 apps with an AI surface had a confirmed path. One route I audited let anyone on the internet mint paid model sessions with zero login. The fix was boring compared to the failure: an auth check and a per-user cap on the one endpoint that calls the model, enforced before the call goes out, not noticed when the bill arrives.

Test parallel requests and retries around the limit. Confirm rejected work does not call the provider first. Verify one user cannot distribute the same workload across free accounts or make another organization pay for it. Payment and entitlement boundaries can leak money through the same pattern, as shown in the checkout trust-boundary guide and in what happens when an app gives away paid access for free.

LLM07:2026 Misinformation

Misinformation moved up from ninth to seventh, and it is the entry OWASP’s project leads ask readers to slow down on. Voters placed it near the bottom; the incident record placed it near the top. The definition is output that is incorrect, incomplete, unsupported, or misleading, and credible enough to influence a human decision, an automated workflow, or an agent action. The core risk is that the wrong output is trusted and acted upon.

The required control depends on consequence. A brainstorming feature can show uncertainty. A medical, financial, legal, compliance, access, payment, or operational decision may need authoritative sources and qualified human review.

Create an evaluation set containing known answers, missing information, conflicting sources, time-sensitive facts, and questions the system should decline. Record accuracy, citation validity, abstention, and the effect of model or prompt changes. Do not let the model’s confidence or writing style substitute for evidence.

When output triggers an action, validate the action under LLM10 and LLM03 even if the statement itself sounds plausible.

LLM08:2026 Hidden Context Exposure

This is the renamed and widened version of 2025’s System Prompt Leakage. Hidden Context Exposure covers the unauthorized extraction, inference, or reconstruction of any hidden, non-user-facing instruction or operational context in the model’s window: the system prompt, developer instructions, retrieved policy text, configuration, user-profile data, and the schemas of the tools you expose.

OWASP’s design guidance is the whole fix in one line. Assume hidden context is discoverable, and treat nothing in it as a secret. Sensitive values such as credentials, connection strings, and tokens should not be there, and hidden context should never be the only thing enforcing authorization, privilege separation, policy, or content filtering.

Severity tracks what you put there. Informational when there are no secrets and nothing depends on the content staying hidden. Medium for internal rules and workflow logic that help an attacker without gating a decision. High for embedded credentials, or when authorization depends on the prompt staying private. Critical when disclosure chains into remote code execution, broad data exfiltration, or privilege escalation somewhere connected.

Test direct requests, translation, encoding, completion of a quoted prefix, simulated debugging, tool errors, and indirect injection through retrieved content. A leak should reveal no credential and should not grant an action the caller could not otherwise perform.

LLM09:2026 Vector and Embedding Weaknesses

This risk applies to any application that turns text, images, code, or audio into vectors and uses similarity search to decide what the model sees. Retrieval-augmented generation is the familiar case, but the same machinery sits under vector-backed agent memory, semantic caches, and deduplication. OWASP’s summary frame is useful: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate.

A shared vector index can return another tenant’s document if filtering is missing, caller-controlled, or applied after retrieval. Deleted content can remain embedded after the source record disappears.

Create two tenants with distinctive private documents. Query both accounts using exact phrases, semantic paraphrases, metadata filters, and known document IDs. Attempt to change the tenant or collection selector in the request. Test deletion, permission revocation, reindexing, and a hostile document designed to outrank trusted sources.

Authorization should constrain the candidate set before restricted content reaches the model. Keep a source identifier on each returned passage so the application can enforce, cite, remove, and investigate it.

One cohort finding is worth borrowing here even though it predates the vector layer. An AI coding workspace let a logged-in customer read another customer’s private chats, because the query filtered on “is this person logged in” rather than “does this person own this row”. Retrieval makes that same mistake harder to see, because the wrong row arrives as a paragraph of prose instead of a database record.

LLM10:2026 Improper Output Handling

Improper Output Handling fell from fifth to tenth, the largest drop in the 2026 list. It did not get smaller; it got outranked. It also grew, because the 2026 entry now spans the insecure code that coding assistants generate at scale.

Model output is untrusted data. Its next destination determines the required control:

• rendered HTML needs safe encoding or sanitization;
• a database operation needs a typed, allowlisted schema and parameterized query;
• a URL needs destination validation and safe redirect handling;
• code or shell execution needs strong isolation and a narrow command contract;
• a tool call needs authorization, argument validation, and a side-effect policy;
• a factual claim needs source and uncertainty handling appropriate to its consequence.

Structured output helps only when the application validates the structure and permitted values. A valid JSON object can still request the wrong account, destructive function, excessive amount, or prohibited URL.

Build tests that make the model return extra fields, unexpected types, markup, instructions, fake citations, large values, and tool arguments outside the allowed set. Confirm the application rejects or safely handles them before any side effect.

The cohort version of this is unglamorous. A retail point-of-sale app shipped a GET endpoint that could drop every production table, guarded only by a secret in the query string. Nothing about that is model-specific, which is the point: once model output can select an operation, every unguarded operation becomes reachable through a sentence.

What changed in the 2026 list

Every item from 2025 survived into 2026. What changed was order, one name, and the scope of four entries.

Nothing was deleted, so 2025 testing work still counts. Re-label your findings to the 2026 IDs, re-read the four entries whose scope grew, and re-run the two that climbed most, Excessive Agency and Unbounded Consumption, because the ranking says that is where damage is landing.

Nothing was removed from the 2025 list. What changed is the order, and the order now carries a quarter of its weight from what actually went wrong in the field.

And what changed in 2025, from the 2023 list

The 2025 list replaced the earlier 2023-24 version. Several concepts stayed while their names or positions changed:

System Prompt Leakage and Vector and Embedding Weaknesses arrived as their own 2025 positions, and the 2025 list is still published for anyone reconciling older findings. Losing a standalone position does not make plugin design or model theft irrelevant; each Top 10 is a prioritized list rather than a complete inventory of every possible AI risk.

Is there an OWASP Top 10 for AI agents?

Yes. The Top 10 for Agentic Applications 2026 was announced on 9 December 2025 and addresses systems that plan, use tools, make decisions, and operate across workflows. Its risks carry ASI identifiers rather than LLM ones:

OWASP draws the boundary between the two lists this way: the LLM list owns the risk when the model is a component inside your application, and the risk moves to the agentic list the moment the model becomes an actor with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream. Many real incidents sit right on that line, which is why an agentic system usually needs both assessments. It still contains an LLM application underneath the agent loop.

Run the OWASP LLM Top 10 in an afternoon

Ten equal-weight risks are not a plan. This is the order a two-person team should actually work in, because it follows the data flow rather than the list numbering.

1. Write down every path where outside text reaches the model. Form fields, uploads, retrieved documents, tool output, emails, database rows, stored memory, fetched URLs. This inventory is the input to steps 2 and 4, and it usually takes twenty minutes.
2. Send one injection down each path. Instruct the model to ignore its task, reveal its instructions, and call a tool it should not. Record what happened outside the model, not what the model said. (LLM01)
3. Find every endpoint that spends money and call it logged out. Then call it a hundred times logged in. If the logged-out call is answered, or the hundredth call still goes through, stop and fix that before anything else on this list. It is the only risk here that bills you while you read. (LLM06)
4. Trace every model output to its destination. Browser, database, shell, tool call, another service. Confirm each destination validates the output rather than trusting it. (LLM10)
5. Create two accounts and ask each for the other’s data. Direct questions, search, exports, summaries, and known record IDs. Do it through the chat surface and through the API. (LLM02)
6. If you use retrieval, repeat step 5 against the index. Query across tenants, edit the metadata filter, and check that a deleted document stops being retrievable. (LLM09)
7. List the tools the model can call and delete the ones the task does not need. For what remains, confirm the acting identity is derived server-side and destructive actions need a fresh human approval. (LLM03)
8. Ask the model for its own instructions, five different ways. Then check whether anything you found was load-bearing. If a leaked instruction changes what an attacker can do, that is the finding, not the leak. (LLM08)
9. Inventory your models, adapters, SDKs, datasets, and tool servers, with versions and owners. Add the writable knowledge sources to the same document. (LLM04, LLM05)
10. Build a twenty-question evaluation set with known answers. Include questions the system should refuse. Re-run it after every model or prompt change. (LLM07)

Steps 1 through 4 are the afternoon. Steps 5 through 10 are the following week. If you only have one hour, do step 3.

Common questions about the OWASP LLM Top 10 2026

Which OWASP AI list is current?

The current list for LLM and generative AI applications is the OWASP Top 10 for LLM Applications 2026, published 3 August 2026. OWASP also maintains a separate Top 10 for Agentic Applications 2026 for systems that plan and act through tools. Use the list that matches the system, and use both when an LLM application also acts autonomously.

Is the OWASP LLM Top 10 2025 still valid?

The risks are still valid; the version label is not. Every 2025 entry survived into 2026, so testing done against the 2025 list still counts as coverage. What changed is the order, one renamed entry (System Prompt Leakage became Hidden Context Exposure), and the scope of four entries, so re-label your findings to the 2026 IDs and re-read those four.

When did the OWASP LLM Top 10 2026 come out?

The OWASP GenAI Security Project published version 1.0 of the Top 10 for LLM Applications 2026 on 3 August 2026. It arrived as a downloadable document rather than a set of web pages, which is why most search results still display the 2025 or even the archived 2023 names. The Agentic Applications 2026 list is separate and was announced earlier, on 9 December 2025.

What is the difference between the OWASP LLM Top 10 and the Agentic Top 10?

The LLM list covers risks where the model is a component inside your application, answering questions and producing output that your code handles. The Agentic list covers risks that appear once the model becomes an actor with tools it can call, memory that persists between sessions, and consequences it sets in motion downstream. Most agentic systems need both, because there is still an LLM application underneath the agent loop.

Which LLM risks should a small team test first?

Follow the feature’s data flow. Test prompt injection wherever untrusted text enters the model, unbounded consumption wherever a request costs money, and improper output handling wherever model output reaches code or a user. Move sensitive-information and retrieval tests to the front when the feature can reach private data, and add excessive-agency tests before the model can take consequential actions.

Do I need to test data poisoning if I use a hosted model API?

You may have little control over the hosted model’s pre-training, but your application can still accept fine-tuning examples, user feedback, uploaded documents, or writable retrieval sources. Inventory those paths first. If none exists, document the narrower exposure and focus on supply-chain, prompt, output, data-access, and consumption risks that do apply.

Does passing the OWASP LLM Top 10 make an AI app secure?

No. The list provides ten high-priority risk categories, not a complete inventory. The application still needs ordinary API, authentication, authorization, secrets, dependency, privacy, recovery, and operational testing, and you should record the exact release, data flows, roles, model and provider, tests run, and limitations of the result.