OWASP Top 10 for LLM / Generative AI Applications: OWASP Top 10 for LLM / Generative AI Applications – Tutorial (about 60 minutes)

The OWASP Top 10 for LLM Applications is a free, community-built list of the ten most important security risks in software that uses a large language model (LLM), such as chatbots, coding assistants, document summarisers and retrieval-based "ask our knowledge base" tools. Developers, security engineers, architects, product owners and auditors use it as a shared vocabulary for what can go wrong and as a starting checklist for defences. After this tutorial you will be able to explain each of the ten risks in plain words, find them in a real application design, choose sensible controls, and plan how to test and review an LLM feature against the list.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is the OWASP Top 10 for LLM Applications 2026, published by the OWASP GenAI Security Project (part of the OWASP Foundation) in early August 2026; the official resource page is dated 3 August 2026 and the document cover 4 August 2026. Its entries carry the suffix :2026, for example LLM01:2026. It replaces the 2025 edition (released 18 November 2024), which itself followed versions 1.0 (August 2023) and 1.1 (October 2023). The 2026 document is licensed under Creative Commons CC BY-SA 4.0. The list is an awareness and guidance document, not a certifiable standard, and OWASP has revised it every year or two, so check the project site for a newer edition before you rely on the ranking. Take the ranking from the official document rather than from secondary summaries; the order taught here comes from the official PDF. Verified 2026-10-29 against the official 2026 PDF and the genai.owasp.org resource page.

Who it is for: software developers and architects adding LLM features, application and cloud security engineers, product and engineering managers, risk, compliance and audit staff, and anyone who must review or buy a generative AI product.

Prerequisites: none. A general idea of how web applications work (a browser, a server, a database, an API) helps. Every AI term is explained when it first appears, and you do not need to know how neural networks are trained.

By the end of this tutorial:

You will be able to explain why applications built on LLMs need their own risk list in addition to the classic OWASP Top 10 for web applications.
You will be able to describe each of the ten 2026 entries, give an example of it and name its main defences.
You will be able to read an LLM application design, mark its trust boundaries and say which entries apply where.
You will be able to choose controls that still hold when the model is fooled, instead of relying on the model to behave.
You will be able to plan an assessment of an LLM feature, including threat modelling, adversarial testing and severity rating.
You will be able to place the list next to related frameworks such as the OWASP Top 10 for Agentic Applications, MITRE ATLAS and NIST AI 600-1.

Lesson 1 – Origins, purpose and scope

Why a separate list was needed

The Open Worldwide Application Security Project (OWASP) is a non-profit foundation known for free, vendor-neutral security material, most famously the OWASP Top 10 for web applications. When teams began wiring LLMs into products in late 2022 and 2023, they discovered that many of their usual security habits did not fit. A web form expects a name or a number; an LLM accepts any text, in any language, and responds with text that can contain code, links, database queries or instructions for other systems. Worse, the model treats everything it reads, whether it came from the developer, the user or a web page it was asked to summarise, as part of one input. Classic advice such as "separate code from data" has no direct equivalent.

A group of volunteers led by Steve Wilson started the OWASP Top 10 for Large Language Model Applications in 2023 to give builders a short, ranked list of the risks that matter most for this new kind of software. Version 1.0 appeared in August 2023 and a lightly revised 1.1 in October 2023. The 2025 edition, released in November 2024, reshaped the list substantially: it added System Prompt Leakage and Vector and Embedding Weaknesses, and broadened older entries into Misinformation (formerly Overreliance) and Unbounded Consumption (formerly Model Denial of Service). The effort grew into the OWASP GenAI Security Project, which now also publishes guidance on agentic AI, data security for generative AI, red teaming and governance. The 2026 edition is led by Steve Wilson and co-lead Rock Lambros.

What the list is for

The list has three practical jobs. First, it is an awareness tool: it gives a team, in one short document, the names and shapes of the failures that have hurt real LLM products. Second, it is a design aid: each entry explains how the risk arises and which defences help, so architects can build controls in from the start. Third, it is a common language: when a penetration tester writes "finding mapped to LLM03:2026", developers, managers and auditors all know which family of problems is meant.

The list is not a complete security standard. It does not list testable requirements, does not define maturity levels, and nobody can certify an application as "compliant". It is the top of a much larger body of knowledge, and it points outwards to deeper material for detailed requirements and testing.

Scope: the model as a component

The 2026 edition draws a clear boundary. It covers the situation where the LLM is a component inside your application: your code sends it a prompt, it returns text, and your code decides what to do with that text. When the model becomes an actor that chooses tools, carries memory between sessions and sets off actions on its own, a second list applies as well: the OWASP Top 10 for Agentic Applications, released in December 2025, whose entries are numbered ASI01 to ASI10. Many real systems sit on that boundary, so the authors recommend reading the two lists together whenever your model can act. This tutorial stays with the LLM list and mentions the agentic list only to show the relationship.

The list is technology-neutral: it applies to hosted models called through an API, open-weight models on your own servers and small models shipped inside apps.

Lesson 2 – Key concepts and vocabulary

You need a small vocabulary before the ten entries make sense. Read these terms once now and come back to them as you go.

Large language model (LLM) – a machine-learning model trained on very large amounts of text that predicts the next piece of text. Given an input, it produces fluent output, but it has no built-in notion of truth or of who is allowed to ask what.
Token – the unit of text a model reads and writes, often a word fragment. Context limits, speed and price are all measured in tokens.
Prompt and system prompt – the prompt is the text sent to the model. The system prompt is the part written by the developer to set the model's role and rules, usually hidden from the end user.
Context window – everything the model can see in one request: system prompt, user message, conversation history, retrieved documents, tool results and memory, all as one stream of tokens.
Hidden context – any part of the context window that the user is not meant to see, such as the system prompt, internal policy text and the descriptions of tools the model may call.
Retrieval-augmented generation (RAG) – a pattern where the application first searches a document store for passages relevant to the question and adds them to the prompt, so the model answers from current, specific information.
Embedding and vector store – an embedding is a list of numbers that represents the meaning of a piece of content; similar meanings give nearby numbers. A vector store is a database that keeps embeddings and finds the nearest ones to a query.
Tool (also plugin, extension, function or skill) – a piece of code the application lets the model invoke, for example "search orders" or "send email". An LLM that chooses and calls tools is often called an agent.
Model Context Protocol (MCP) – an open protocol that connects LLM applications to external tools and data sources through MCP servers; it makes adding tools easy, which also makes it a new route for attacks.
Fine-tuning and adapters – fine-tuning further trains a model on your own examples. An adapter, such as a LoRA (low-rank adaptation) file, is a small add-on that changes a base model's behaviour without retraining all of it.
Jailbreak – an input crafted to make a model ignore its safety rules. It is a subset of prompt injection.
Hallucination – confident output that is false or unsupported, such as an invented court case or software package.
Guardrail – a control that checks inputs or outputs of a model, for example a classifier that blocks certain content. Guardrails help but can be evaded.
Human in the loop – a design where a person must review and approve an action before the system carries it out.
Least privilege – giving every component only the access it needs for its task, and nothing more.

Trust boundaries in an LLM application

A trust boundary is a place where data passes from a less trusted zone into a more trusted one, and where checks belong. In a classic web application the main boundary is the server's input handling. In an LLM application there are several, and the most important lesson of the whole list is where they really are. The model itself is not a trust boundary: it cannot reliably tell the developer's instructions from text that an attacker planted in an email. The real boundaries are in ordinary application code, before content enters the context window and, above all, after output leaves the model and before it reaches tools, databases or a browser.

Figure 1 – Every source is merged into one context window, so the dependable checks sit in application code after the model, before tools and screens.

Keep Figure 1 in mind. Prompt injection enters on the left through any source. Sensitive data can leave through the output or through logs. Excessive agency lives in the arrow to tools. Supply chain and poisoning affect the model and its data before any user arrives. Improper output handling lives in the box before the browser. Almost every entry in the list is a question about one of these arrows.

Lesson 3 – The structure of the 2026 list

How the ranking was built

Earlier editions were ranked by expert judgement: hundreds of practitioners voted on what worried them most. For 2026 the project kept the vote as the backbone but checked it against evidence for the first time. The team gathered 7,714 AI-related incidents from public vulnerability databases and an AI harm database, used classifiers to sort the 6,639 that had enough detail, and compared what practitioners fear with what the record shows. The final order weights the community vote at three quarters and the incident data at one quarter, enough for strong evidence to move an entry up or down a tier but not enough for one year of imperfect data to rewrite the list.

Figure 2 – The 2026 order blends a practitioner vote with classified incident data, then adds framework mappings and a threat-modelling appendix.

The comparison produced two instructive disagreements. Prompt injection stays first even though it would drop out of the top ten if you ranked purely by public incidents; the authors explain this as a defence effect, because teams fight injection hard and many attempts never become public exploits. Misinformation goes the other way: voters ranked it low, but the incident record shows it causing real harm often, so it moved up to the middle of the list.

Anatomy of an entry

Every entry follows the same layout, which makes the list easy to teach and to use in reviews:

Description – what the risk is, how it arises and where its boundaries with neighbouring entries lie.
Common examples of risk – the typical ways the weakness shows up in real systems.
Prevention and mitigation strategies – numbered defences, often noting which ones only reduce the chance of an attack and which ones limit the damage once it succeeds.
Example attack scenarios – short stories, many based on published research or real incidents.

In 2026 the per-entry lists of related frameworks were removed and gathered into Appendix A, a single version-pinned table that maps each entry to the Agentic Top 10, the OWASP GenAI Data Security guidance, MITRE ATLAS, MITRE ATT&CK, CWE, NIST AI 600-1, the NIST AI RMF, the CSA AI Controls Matrix and the OWASP AI Vulnerability Scoring System (AIVSS). Appendix B covers LLM application architecture and threat modelling, and a long reference list closes the document.

The ten entries, in your own words

LLM01:2026 Prompt Injection. Any input changes the model's behaviour in a way the developer did not intend. Direct injection comes from the user's own message, whether deliberate (a jailbreak) or accidental. Indirect injection arrives inside content the model reads on the user's behalf: a web page, an email, a support ticket, a retrieved document, a tool response, an image or an audio track. The 2026 entry stresses that instructions can be invisible (hidden Unicode characters, text in image pixels) and can persist by being written into memory or a RAG corpus. Because models do not separate instructions from data, OWASP states plainly that no reliable prevention exists today; defence must be architectural. The entry describes three helpful axes for analysing an attack: the delivery surface (how it reaches the model), propagation (single shot, multi-step, across sessions or across agents) and encoding (plain text, obfuscated, invisible, multimodal).

LLM02:2026 Sensitive Information Disclosure. Confidential, personal, regulated or proprietary data leaves through a channel nobody authorised. The answer text is only one channel; tool-call arguments, reasoning traces, logs, telemetry, embeddings and even timing or token length can leak information. Disclosure can arise at training time (memorised data), inference time (oversharing live context), in pipelines (fine-tuning and observability tools copying data) and through observation (inferring facts from measurable behaviour). Two root causes dominate: feeding RAG with documents that were already overshared, and data persisting in weights or vectors after the source was deleted. Defences are tiered from foundational (minimise context, authorise before retrieval, keep secrets out of prompts, scrub logs) to hardening and advanced measures for regulated workloads.

LLM03:2026 Excessive Agency. The system can perform damaging actions in response to model output that is wrong, ambiguous or manipulated. What triggers the bad output does not matter, a hallucination and an injection lead to the same place. The root causes are three kinds of "too much": functionality the task does not need, permissions broader than the task requires, and autonomy to act on high-impact steps without independent verification. This entry jumped from sixth to third in 2026 because agentic deployments are where damage is now landing.

Figure 3 – Excessive agency has three root causes; removing each one limits what a fooled model can actually do.

LLM04:2026 Supply Chain. The models, datasets, adapters, packages, conversion services and serving frameworks you depend on can be vulnerable, tampered with or replaced. Examples include outdated libraries, malicious model files that run code when loaded, lookalike or re-registered model names on public hubs, poisoned adapters, compromised conversion or quantisation steps, unclear supplier terms that allow your data to be used for training, and coding assistants that suggest package names that do not exist, which attackers then register. Defences include supplier vetting, an inventory of AI components (an AI bill of materials), signing and hash-pinning artifacts, referencing models by immutable digest, and evaluating models before and after adoption. Note that a signature shows who published an artifact and that it was not altered; it does not show that the model is safe, because a compromised or malicious supplier can sign a backdoored model, so behavioural evaluation is still needed.

LLM05:2026 Data and Model Poisoning. An attacker, or a careless process, corrupts data or model artifacts so that the system learns harmful behaviour, bias or a hidden backdoor that activates only on a trigger. Poisoning can happen in pre-training, fine-tuning, embedding creation, retrieval corpora, feedback loops and shared model files, including chat templates and tokenizer settings. Research cited in the entry shows that a small number of poisoned documents can be enough. Because the damage is in what the model has learned, fixing it can mean revalidating data, retraining or replacing the model. Defences centre on provenance and lineage, validation of incoming data, version control for datasets, anomaly monitoring and trigger-focused red teaming.

LLM06:2026 Unbounded Consumption. The application lets requests consume compute, tokens or money without effective limits. Attackers exploit cost asymmetry: a cheap request can trigger expensive work. The entry covers floods of large inputs, "denial of wallet" attacks that run up a pay-per-use bill, reasoning models pushed into very long thinking, tool-call loops in agents, ever-growing session contexts, and model extraction, where an attacker queries an API enough to clone its behaviour. Defences go beyond requests-per-second to token-based quotas, hard spending caps that actually stop inference, step and recursion limits for agents, and hardened serving infrastructure. It rose four places in 2026.

LLM07:2026 Misinformation. The model produces false, incomplete or misleading content that looks credible enough to drive a decision or an automated action. Causes include hallucination, stale or missing context, weak grounding, biased data and deliberate manipulation. The core problem is overreliance: people and systems trust fluent, confident output. In agentic systems this becomes concrete, for example an agent reporting that a backup ran when it did not. Defences include grounding claims in authoritative sources, separating generation from execution so claims are verified before action, validating tool calls against real system state, and requiring structured outputs that cannot silently omit critical fields.

LLM08:2026 Hidden Context Exposure. Formerly called System Prompt Leakage, this entry now covers any hidden context: system prompts, developer instructions, retrieved policy text and tool schemas. The key design assumption is that hidden context will be discovered. Leaking it becomes a security problem when it contains secrets or details that materially help an attacker (internal rules, filtering criteria, tool permissions), and it is serious when the application relies on its secrecy for authorisation or content policy. The entry offers a simple severity ladder, from informational (nothing sensitive, nothing relied on) through medium and high to critical (disclosure chains to code execution, mass data theft or privilege escalation). The fixes are to keep credentials out of hidden context and to enforce critical rules in deterministic code outside the model.

LLM09:2026 Vector and Embedding Weaknesses. Wherever similarity search decides what the model sees, the embedding layer is part of the trust boundary. The entry summarises the failures neatly: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent and access-control failure makes it indiscriminate. Examples are cross-tenant leakage when search runs over all tenants before filtering, reconstruction of text from stolen embeddings, crafted documents that land next to target queries, "blocker" documents that make the model refuse, and poisoning of semantic caches. Defences include scoping access inside the index query, separating indexes by tenant and trust level, tracking provenance for every vector, not returning raw similarity scores, and treating vector backups as sensitive as the source documents.

LLM10:2026 Improper Output Handling. Model output is passed to other components without validation, sanitisation or encoding. Since an attacker can influence the output through the prompt, this is like giving them indirect access to whatever consumes it. Results include cross-site scripting in the browser, SQL injection, path traversal, remote code execution through shells or eval, terminal escape-sequence tricks, and data exfiltration when a chat interface automatically loads an image whose web address carries stolen data. Defences are classic application security applied to a new source: treat the model like any untrusted user, encode output for its context, use parameterised queries, apply a Content Security Policy and stop renderers from fetching external resources automatically. It fell from fifth to tenth in 2026, the largest drop on the list, but its consequences can still be severe.

What changed from 2025

All ten themes from 2025 remain, but the order moved more than in earlier revisions, one entry was renamed and broadened, and several entries absorbed newer risks: prompt injection now explicitly covers cross-modal attacks hidden in images or audio, supply chain covers artifacts that are not what they claim to be, poisoning covers subverted fine-tuning, and output handling covers insecure code generated by assistants at scale.

Figure 4 – The biggest moves of 2026: agency, consumption and misinformation rose, output handling fell, and prompt leakage became hidden context exposure.

Prompt injection and sensitive information disclosure kept the first two places. Supply chain moved from third to fourth, data and model poisoning from fourth to fifth, and vector and embedding weaknesses from eighth to ninth. If you have older reports or tickets labelled with 2025 numbers, always write the year next to the code, because LLM03 meant Supply Chain in 2025 but means Excessive Agency in 2026.

Lesson 4 – How the list works in practice

The central design principle

The project leads open the 2026 edition with a clear message: stop trying to build a model that cannot be fooled, and instead build the system around it so that nothing important breaks when it is fooled. This principle explains most of the defences in the list. Filters and carefully worded system prompts reduce how often an attack works, but against a determined, adaptive attacker they eventually fail. The controls that survive are the ones that limit consequences: what data the model can see, what actions its output can trigger, how much it can spend and where its output is allowed to go.

Think of the model as a very capable new employee who will believe anything written in any document handed to them. You would not give such a person the keys to every system, let them send payments without a second signature, or paste their drafts straight onto your public website. You would still let them do useful work, but inside a structure that catches their mistakes.

Three practical checks for agents

The prompt injection entry cites two compact tests that help teams decide how much risk an agent carries. Simon Willison's "lethal trifecta" notes that an agent becomes dangerous when it can, at the same time, read private data, take in untrusted content and communicate externally; remove any one of the three and the most serious exfiltration paths close. Meta's "Rule of Two" turns this into a design budget: an agent that combines untrusted input, sensitive data and the ability to change state or communicate externally should require human approval for each action, and agents that combine untrusted input with one of the other two need an explicit assessment of the remaining risk. Both tests are quick to apply during design review, and both push teams towards splitting one powerful agent into narrower pieces.

A third check comes from the excessive agency entry: complete mediation. Every request from a tool to a downstream system should be checked against policy by deterministic code, either in the tool, in a separate policy decision point or in the downstream system itself, never by asking the model whether the action is allowed. A graduated policy can let easily reversible, low-value actions through automatically while sending irreversible ones, such as an external payment, to a person.

A repeatable way to apply the list

The list does not prescribe a process, but teams that use it well tend to follow a loop like the one in Figure 5. It fits into an existing secure development lifecycle rather than replacing it.

Figure 5 – A practical loop for applying the list: inventory, model the threats, choose controls, test adversarially, monitor and revisit.

Step 1 – Inventory. List every place an LLM is used, including third-party products. For each, record the model, what data reaches the context window, which tools it can call, who the users are and where outputs go.

Step 2 – Data flows and trust boundaries. Draw a diagram like Figure 1 for each feature. Mark every source of untrusted content, every store of sensitive data and every action the system can take. Appendix B of the 2026 document gives architecture and threat-modelling guidance for exactly this step.

Step 3 – Map the entries. Walk through the ten entries against the diagram. Where can injected text enter? Which outputs reach a browser, shell or database? Which tools are broader than the task? Is there a vector store, and is it shared between tenants? Where do models, adapters and packages come from? Record each applicable entry as a threat with its likely impact.

Step 4 – Agency budget. Apply the trifecta and Rule of Two to every agent. If an agent has all three properties, either remove one or add per-action approval.

Step 5 – Controls. Prefer controls in deterministic code over instructions to the model. Typical choices are scoped credentials per user, read-only tools where reading is enough, authorisation inside retrieval queries, output encoding and schema validation, token and cost limits, signed and pinned model artifacts, and approval steps for irreversible actions. Use filters and prompt hardening as extra layers, not as the main wall.

Step 6 – Test. Test with people who know your defences and actively try to get around them. Lesson 5 covers this in more detail.

Step 7 – Release and monitor. Log tool calls, retrieval results and cost per user or session; scrub sensitive data from those logs; alert on unusual patterns such as sudden spikes in token use, repeated attempts to reveal the system prompt, or tools being called in loops.

Step 8 – Learn. Feed incidents and near misses back into the threat model, and review the design again whenever the list is revised, a new tool is added or a model is swapped.

Roles and artefacts

No single role owns the list. Product owners decide how much autonomy a feature really needs. Architects own the trust boundaries and the agency budget. Developers implement output handling, scoped credentials and limits. Data and machine-learning engineers own corpus hygiene, provenance and model evaluation. Platform teams own serving infrastructure, cost caps and logging. Security teams run threat modelling and adversarial testing and keep the mapping current. Useful artefacts include the LLM feature inventory, data-flow diagrams, an AI bill of materials that lists models, adapters and datasets, a threat register with entries tagged by their LLMxx:2026 codes, and test reports from red teaming.

Lesson 5 – Assessment, certification and compliance

No certification exists

There is no official certification against the OWASP Top 10 for LLM Applications, and OWASP does not accredit auditors or issue compliance badges for it. A vendor statement such as "covers the OWASP LLM Top 10" means only that the vendor believes its product or test addresses those risk themes; it is a claim to verify, not a credential. Because the list names risks rather than precise requirements, "passing" it is not a meaningful idea. What you can do is show, with evidence, that each applicable risk has been considered, controlled and tested.

How applications are assessed against it

Assessments typically combine four activities. Design review and threat modelling look for the structural causes, such as overbroad tools, secrets in prompts or shared indexes, which are cheap to fix early. Code and configuration review checks output handling, credentials, retrieval filters, logging and limits. Adversarial testing, often called AI red teaming, tries direct and indirect injection, data extraction, hidden context extraction, cost exhaustion and unsafe tool use against the running system. Supply-chain review examines where models, adapters, datasets and packages come from and how they are verified.

The 2026 edition is firm about one testing mistake. Many defences look excellent against a fixed set of known attack prompts and collapse when testers who have read the defence adapt their attacks. The prompt injection entry cites research in which attack success against a dozen recent defences was close to zero with static attacks but above 90 % for most of them under adaptive attack. Public benchmarks such as AgentDojo and JailbreakBench are useful baselines, but a meaningful assessment gives red teamers the full description of the defences and lets them iterate.

Rating severity

Severity depends on context, not on the entry number. A prompt injection in a chatbot with no tools and no private data is usually low impact; the same injection in an assistant that can read a mailbox and send email can be critical. The Hidden Context Exposure entry gives a good model for thinking about this: severity tracks what was placed in the hidden context and how much the application relies on it staying secret, rising from informational to critical when disclosure leads to credentials, privilege escalation or remote code execution. For a more formal score, Appendix A maps the entries to the OWASP AI Vulnerability Scoring System (AIVSS), a scoring approach for AI-specific and agentic risks that was still a pre-1.0 version at the time of the 2026 release.

Using the list for compliance work

Although the list is not a regulation, it helps with compliance because it is mapped to frameworks that regulators and auditors know. Appendix A links every entry to NIST AI 600-1 (the Generative AI Profile of the NIST AI Risk Management Framework), the NIST AI RMF itself, MITRE ATLAS, CWE and the Cloud Security Alliance AI Controls Matrix. A team preparing for an ISO/IEC 42001 AI management system audit, or documenting risk controls under privacy and AI laws, can use the list as the technical layer that shows how specific security risks of LLM features are handled. Procurement teams also use it: asking a supplier how its product handles each of the ten entries, with evidence, is a quick way to separate mature products from immature ones.

Lesson 6 – Worked example: a claims assistant at an insurer

Harbourline Insurance, a fictional mid-sized insurer, wants to launch an assistant for its claims handlers. A handler opens a claim, and the assistant summarises the customer's emails and attachments, answers questions from the internal policy manual using RAG, drafts a reply to the customer and can approve small payouts. The team decides to review the design against the 2026 list before building it.

Step 1 – Inventory and data flows

The security architect draws the flows. Untrusted content enters from customer emails and attachments (text, PDFs, photos of damage). Sensitive data includes customer personal data, medical notes on injury claims and the internal fraud-detection rules. The model is a hosted LLM reached through an API key. Tools in the first draft are: a general "query claims database" tool with a service account, an "email customer" tool and a "payout" tool. The policy manual and all past claim notes sit together in one vector store. Model output appears in a web-based claims console.

Step 2 – Mapping the entries

LLM01 Prompt Injection. Customer emails and attachments are a perfect indirect injection channel. A fraudulent claimant could hide a line in a PDF telling the model to describe the claim as verified and recommend immediate payment. The team accepts that injection cannot be fully prevented and focuses on limiting what a successful injection can do.

LLM03 Excessive Agency. The first draft has all three root causes. The database tool can read every claim and also update records (too much functionality and permission); the payout tool can pay without a human check (too much autonomy). Applying the Rule of Two, the assistant combines untrusted input (customer emails), sensitive data (all claims) and state change (payouts and email). That combination is not acceptable without per-action approval.

LLM02 Sensitive Information Disclosure and LLM09 Vector and Embedding Weaknesses. Because the shared vector store holds past claim notes, a question about one claim could retrieve another customer's medical details. Filtering results after retrieval would be too late, since the passages would already be in the context window.

LLM08 Hidden Context Exposure. The first draft system prompt includes the fraud-scoring thresholds "so the model can flag suspicious claims" and the API key for the address-lookup service. Both would help an attacker if extracted.

LLM10 Improper Output Handling. The console renders Markdown from the model, including images, so a crafted email could make the model output an image link that sends claim details to an outside server when the console loads it.

LLM07 Misinformation. Handlers might trust a confident summary that leaves out an exclusion clause from the policy manual.

LLM06 Unbounded Consumption. Some claims arrive with hundreds of pages of attachments and many photos, and a long conversation re-sends the whole context each turn.

LLM04 Supply Chain and LLM05 Data and Model Poisoning. The team plans to fine-tune a small open-weight model later for classification, downloaded from a public hub, and the policy manual corpus is edited by many staff.

Step 3 – Redesign

The database tool is replaced with a read-only tool that returns only the currently open claim, using the handler's own identity, so a fooled model cannot browse other claims.
The payout tool stays, but every payout goes through a deterministic policy service that checks the amount, the claim status and the policy limits, and then shows the handler the exact payout for approval. The model can only propose.
The email tool creates drafts only; the handler presses send.
Past claim notes move out of the shared index. The vector store keeps only the policy manual, and access filtering happens inside the index query. Document changes to the manual go through review, and each vector records its source document and version.
Fraud thresholds and the API key are removed from the system prompt. Fraud scoring runs in a separate service; the key is held by the application, which calls the address service itself.
The console stops auto-loading images and links in model output, encodes all output as text, and validates the structured summary against a schema with mandatory fields for exclusions and deductibles, so omissions are visible.
Per-claim and per-handler token budgets and a hard monthly spending cap are configured; attachments over a size limit are summarised in batches.
For the future fine-tuned model, the team will record it in the AI bill of materials, pin it by digest, verify its signature where available and evaluate it with trigger probing before use.
Logs of prompts and outputs are scrubbed of personal data before they reach the observability platform.

Step 4 – Testing and result

Before launch, an internal red team receives the full design and tries to break it: hidden instructions in PDFs and photos, requests to reveal the system prompt, attempts to make the model propose large payouts, and very long attachments. Some injections still change the model's summaries, which the team records as residual risk and addresses with handler training and the mandatory-field schema. None of the attacks leads to a payout, a sent email, a cross-customer data leak or an outbound request, because those outcomes are controlled outside the model. Harbourline records each finding against its LLMxx:2026 code, adds the review to its threat register and schedules a re-review when the next edition of the list appears or a new tool is added.

Notice what made the difference. The team did not try to make the model perfectly obedient. It narrowed what the model could reach, kept decisions in code, put a person in front of irreversible actions and treated every output as untrusted. That is the 2026 list's core message in practice.

Lesson 7 – Relationship to other standards and frameworks

The LLM Top 10 is one piece of a growing set of AI security and governance references. Knowing how they fit together saves effort: you can use the LLM list for orientation and the others for depth, testing or management-system requirements.

Framework	Owner	What it is	How it relates to the LLM Top 10
OWASP Top 10:2025 (web applications)	OWASP	Ranked list of the most important web application security risks	Still applies to every LLM application's web layer; LLM10 output handling leads straight into classic web flaws such as cross-site scripting and injection
OWASP Top 10 for Agentic Applications (2026)	OWASP GenAI Security Project	Ten risks for autonomous agents with tools, memory and multi-agent interaction (ASI01–ASI10)	Takes over when the model acts rather than answers; for example excessive agency maps to tool misuse, identity and privilege abuse, and cascading failures
MITRE ATLAS	MITRE	Knowledge base of adversary tactics and techniques against AI systems, modelled on ATT&CK	Describes the attacker's techniques behind the risks; useful for red-team planning and detection engineering
NIST AI 600-1 (Generative AI Profile)	NIST	Profile of the NIST AI Risk Management Framework listing generative AI risks and suggested actions	Broader scope (including societal and content risks); the LLM list gives the application-security detail for several of its risks
NIST AI RMF 1.0 (AI 100-1)	NIST	Voluntary framework for managing AI risk through Govern, Map, Measure and Manage functions	Supplies the organisational risk process; the LLM list supplies concrete technical risks to map, measure and manage
ISO/IEC 42001	ISO/IEC	Certifiable management system standard for organisations that develop or use AI	Requires an organisation to assess and treat AI risks; the LLM list is a practical input to that risk assessment, but is not itself certifiable
OWASP ASVS	OWASP	Detailed, testable security requirements for web applications	The LLM10 entry points to ASVS for input validation and output encoding requirements
CSA AI Controls Matrix (AICM)	Cloud Security Alliance	Control framework for secure and responsible AI in cloud environments	Provides control objectives that Appendix A maps each LLM risk to, helpful for audits and supplier questionnaires

A simple way to remember the division of labour: the LLM Top 10 tells you what commonly goes wrong in LLM applications; ATLAS tells you how attackers do it; ASVS and the AICM tell you which requirements or controls to check; the NIST frameworks and ISO/IEC 42001 tell you how the organisation should manage AI risk overall; and the Agentic Top 10 extends the picture once the model starts acting on its own.

Common pitfalls and best practices

Common pitfalls

Relying on the system prompt to enforce security ("never reveal customer data", "only admins may delete") instead of enforcing access in code.
Putting credentials, connection strings or internal decision rules into hidden context on the assumption that users cannot see it.
Giving an agent a general-purpose tool (run any shell command, fetch any URL, full database access) because it was quicker to build.
Filtering retrieved documents by user permission only after the search, when the sensitive text has already reached the model.
Rendering model output as HTML or Markdown with automatic image loading, or passing it to eval, a shell or a raw SQL string.
Judging guardrails only by static test sets and declaring injection "solved".
Limiting requests per second but not tokens, cost or agent steps, so one long session or loop runs up a large bill.
Treating a leaked backup of embeddings as harmless because "it is just numbers".
Mixing up codes between editions, for example reading an old LLM03 finding as excessive agency.

Best practices

Design on the assumption that the model will be fooled; place authorisation, validation and limits in deterministic code around it.
Give every tool the narrowest function and permission it needs, run it in the end user's security context, and require human approval for irreversible or external actions.
Authorise before retrieval, separate indexes by tenant and trust level, and record provenance for every document and vector.
Treat all model output as untrusted input to the next component: validate against a schema, encode for the destination and block automatic outbound fetches.
Keep an AI bill of materials, pin and verify model artifacts, and evaluate models and adapters before and after adoption.
Set token budgets, hard spending caps and agent circuit breakers, and monitor cost per user and per session.
Red-team with testers who know your defences, repeat after every significant change, and tag findings with edition-specific codes.
Read the agentic list alongside this one as soon as your model can call tools or keep memory.

Summary and key takeaways

The OWASP Top 10 for LLM Applications 2026 is a free awareness and design guide from the OWASP GenAI Security Project, not a certifiable standard.
Its ten entries, from LLM01 Prompt Injection to LLM10 Improper Output Handling, each come with a description, examples, mitigations and attack scenarios.
The 2026 ranking blends a practitioner vote (75 %) with classified incident data (25 %); excessive agency rose to third and system prompt leakage became hidden context exposure.
Prompt injection cannot be reliably prevented today, so defences must limit what a fooled model can reach, do and spend.
The model is not a trust boundary; checks belong in application code before retrieval and after output.
Excessive agency comes from too much functionality, permission or autonomy, and each has a matching fix.
Assess with threat modelling, code review, supply-chain review and adaptive red teaming, and rate severity by context.
Use the list with the Agentic Top 10, MITRE ATLAS, NIST AI 600-1, the NIST AI RMF and ISO/IEC 42001 for depth and governance.

Reflection questions

Pick an LLM feature you use or build. Draw its context window sources and its output destinations. Where are the real trust boundaries, and which ones are missing a check today?
For one agent in your organisation, apply the lethal trifecta and the Rule of Two. Which leg could you remove without losing the feature's value?
Your system prompt contains several business rules. Which of them would cause harm if a competitor or attacker read them, and how could you move their enforcement into code?
How would you design a red-team exercise for a RAG assistant so that its results are meaningful against an adaptive attacker rather than a fixed list of prompts?
A supplier says its product "is compliant with the OWASP LLM Top 10". What questions and evidence would you ask for, entry by entry?