OWASP Top 10 for LLM Applications Guide

The OWASP Top 10 for LLM Applications is the list most security teams, auditors and AI vendors use to describe what can go wrong in a generative AI application, yet it is often cited by number without anyone checking which edition, or what each entry actually asks you to do. This guide walks through the ten 2025 entries, LLM01 Prompt Injection to LLM10 Unbounded Consumption: what each risk is, typical scenarios, OWASP's prevention measures and how to test. It also covers changes since 2023/24, the August 2026 renumbering, the separate Top 10 for Agentic Applications, and mappings to MITRE ATLAS and NIST AI 600-1. It is for application security engineers, AI platform teams, assessors and buyers, and contains no attack prompts or payloads.

Key takeaways

• Check the edition before you cite a number. LLM03 means Training Data Poisoning in 2023/24, Supply Chain in 2025 and Excessive Agency in 2026; always write the suffix, for example LLM06:2025.
• Most entries are fixed outside the model. OWASP states that no method is confirmed to fully prevent prompt injection, so least privilege, authorisation in downstream systems, output encoding and spend limits carry the weight.
• Excessive Agency is the entry that turns a bad answer into an incident. Its three root causes, excessive functionality, permissions and autonomy, are identity and access problems, and the 2026 edition moved it up to third.
• The system prompt is not a control. LLM07:2025 (renamed Hidden Context Exposure in 2026) exists because applications kept secrets and authorisation rules in prompts that attackers could extract.
• Agents need the second list. Risks where the model acts autonomously belong to the OWASP Top 10 for Agentic Applications for 2026 (ASI01 to ASI10), which covers goal hijack, tool misuse, identity and privilege abuse and rogue agents.

What the list is and which edition to use

The OWASP Gen AI Security Project, which "started in 2023 as a community-driven effort", ranks risks; the list is not a standard or certification and defines no test procedures. Three editions circulate, plus an agentic companion.

• New policies and threat models: use 2026 IDs, with a 2025 column while tools and suppliers catch up.
• Supplier questionnaires: require the edition; "covers LLM01 to LLM10" without one cannot be compared.
• Agents with tools: assess against both lists; the 2026 edition assigns autonomous behaviour to the agentic list.

The ten risks at a glance

Input and context risks: LLM01, LLM02, LLM07

LLM01:2025 Prompt Injection

OWASP defines it as user prompts that "alter the LLM's behavior or output in unintended ways", including input humans cannot see. Direct injection comes from the user; indirect injection arrives in pages, files, emails or tool results; multimodal injection hides instructions in images. OWASP treats jailbreaking as "a form of prompt injection". Scenario families include payload splitting, adversarial suffixes and obfuscated or multilingual input.

• Prevention: constrain model behaviour, define and validate output formats, filter input and output, enforce least privilege, require human approval for high-risk actions, segregate and label external content, and run adversarial testing. OWASP says none of these fully prevents the attack.
• Testing: seed test documents, emails and pages with benign canary instructions and confirm the application neither follows them nor reaches tools or data because of them. The EchoLeak Copilot flaw and the Gemini calendar invite injection show indirect channels in production assistants.

See the Prompt Injection Guide for channels, hiding techniques and architectural patterns.

LLM02:2025 Sensitive Information Disclosure

Personal data, credentials, business data or proprietary logic exposed through output, from training data, retrieved context or user input. OWASP warns that system prompt restrictions on what to return "may not always be honored and could be bypassed via prompt injection or other methods".

• Prevention: sanitise and minimise training and fine-tuning data, apply strict access control to data sources, tokenise or redact sensitive fields before they reach the context window, and set clear data use and retention terms with providers.
• Testing: two-account tests for cross-user leakage, extraction probes against fine-tuned models before release, and scans of prompt and completion logs for personal data and secrets. The Samsung ChatGPT source code leak is the user-input variant.

LLM07:2025 System Prompt Leakage

Added in 2025 because real exploits showed prompts are not confidential. Disclosure itself "does not present the real risk", says OWASP; the risk is credentials, roles or limits such as transaction thresholds kept in the prompt, or authorisation delegated to the model. The 2026 edition broadens it as LLM08:2026 Hidden Context Exposure.

• Prevention: keep secrets out of prompts, enforce limits and permissions in deterministic code, and use guardrails outside the model.
• Testing: assume the prompt is public. Review prompt templates in source control for keys, internal URLs and business rules, and confirm every rule the prompt states is also enforced server-side.

Data and supply chain risks: LLM03, LLM04, LLM08

LLM03:2025 Supply Chain

Third-party models, LoRA adapters, merged models, datasets, packages and on-device models can carry vulnerabilities or backdoors. OWASP notes that model cards "offer no guarantees on the origin of the model".

• Prevention: use models only from verifiable sources, check integrity with signatures and file hashes, keep an AI bill of materials (CycloneDX supports ML-BOM), prefer weight formats that do not execute code on load, and red team third-party models before use.
• Testing: confirm the pipeline rejects unsigned or hash-mismatched artefacts and that registries need scoped write access. The Hugging Face API token exposure and the Ultralytics PyPI compromise show how publishing credentials become supply chain risk. See the AI Supply Chain and AI-BOM Guide.

LLM04:2025 Data and Model Poisoning

Pre-training, fine-tuning or embedding data is manipulated to add vulnerabilities, backdoors or bias; OWASP calls it "an integrity attack". A backdoor can leave normal behaviour unchanged until a trigger activates it, turning the model into a "sleeper agent", which ordinary functional testing will not reveal.

• Prevention: track provenance and transformations, vet data suppliers, sandbox and anomaly-check incoming data, use data version control, restrict the data sources a model can reach, and ground answers with retrieval from verified sources.
• Testing: monitor training loss against thresholds, compare outputs on a held-out trusted set after every fine-tune, and red team for trigger-dependent behaviour.

LLM08:2025 Vector and Embedding Weaknesses

New in 2025 for retrieval augmented generation (RAG): weaknesses in how vectors and embeddings "are generated, stored, or retrieved". OWASP lists unauthorised access, cross-context leaks, embedding inversion, poisoning and behaviour alteration. Its example is a CV carrying hidden instructions that steer a RAG-based screening tool.

• Prevention: permission-aware retrieval with logical partitioning per tenant and user, validation and source authentication for ingested documents, classification review before combining data sets, and immutable retrieval logs.
• Testing: query as users with different entitlements and confirm retrieved chunks respect source permissions; plant a labelled test document and confirm ingestion controls flag it. See the Permission-Aware RAG Guide.

Output, action and resource risks: LLM05, LLM06, LLM09, LLM10

LLM05:2025 Improper Output Handling

OWASP describes "insufficient validation, sanitization, and handling of the outputs" before they reach downstream components, leading to XSS, CSRF, SSRF, privilege escalation or remote code execution. Whoever influences the prompt reaches whatever consumes the output.

• Prevention: treat the model as an untrusted user, apply OWASP ASVS input validation, use context-aware output encoding, parameterised queries for any database operation, a strict Content Security Policy, and no exec or eval on output.
• Testing: unit tests asserting that markup, SQL fragments and path sequences in output are encoded or rejected; SAST rules flagging output flowing into interpreters. See the LLM Security Guide for a sink-by-sink control table.

LLM06:2025 Excessive Agency

Damaging actions performed in response to unexpected, ambiguous or manipulated output, whether from hallucination or injection. OWASP names three root causes: "excessive functionality", "excessive permissions" and "excessive autonomy". Its example is an email summariser that also holds a send capability and is manipulated by a crafted email into forwarding sensitive mail.

• Prevention: minimise extensions and their functions, avoid open-ended extensions such as raw shell or URL fetch, minimise permissions, execute extensions "in the context of that specific user" with the narrowest OAuth scope, require user approval for high-impact actions, and apply complete mediation: authorise every request in the downstream system, not in the model.
• Testing: list every tool and the identity it runs as, attempt out-of-scope actions through each, and confirm the downstream system, not the prompt, refuses. The ForcedLeak Agentforce flaw and the PocketOS database deletion show injected and unprompted agency respectively.

LLM09:2025 Misinformation

Output that is "false or misleading information that appears credible", caused by hallucination and made harmful by overreliance. Examples include fabricated legal cases, unsafe or nonexistent code libraries and the Air Canada chatbot ruling. Package hallucination is the security variant: attackers register package names assistants invent.

• Prevention: retrieval from verified sources, automatic validation of key outputs, trained human reviewers, clear labelling of AI-generated content and stated limits of use.
• Testing: golden question sets with known answers per use case, groundedness scoring on sampled production answers, and package allowlists that block installs of names not in an internal mirror.

LLM10:2025 Unbounded Consumption

An application that "allows users to conduct excessive and uncontrolled inferences": input floods, denial of wallet, context window overflow, resource-heavy queries, model extraction through the API and functional replication by training on outputs.

• Prevention: input size and output token limits, rate limits and quotas per identity, timeouts, caps on queued actions, restricted logprobs and logit_bias, and a central model inventory.
• Testing: load tests at quota boundaries, spend alert checks and authentication checks on every endpoint. Stolen keys make this a credential problem, as the LLMjacking campaigns showed. See the LLMjacking Guide.

What changed between editions

The 2026 ranking weights the practitioner vote at 75% and incident data at 25%, from 7,714 incidents of which 6,639 could be classified. Where Insecure Plugin Design and Model Theft went in 2025 is our reading of the definitions; OWASP's change notes cover the other moves.

Beyond the LLM list: agentic outputs

The Agentic Security Initiative published Agentic AI Threats and Mitigations (17 February 2025), then the Top 10 for Agentic Applications for 2026 alongside A Practical Guide to Securing Agentic Applications and the FinBot CTF reference application. In September 2026 the project took in the Agent Control Standard for runtime enforcement.

The nearest-entry column is our alignment for extending LLM threat models, not an official OWASP crosswalk.

Where identity fits

Several entries are, underneath, about non-human identities. Excessive permissions in LLM06 are the scopes held by the API keys, service accounts and OAuth grants that tools use; LLM02 and LLM08 leak data because retrieval connectors run as a broad service account instead of the caller; LLM10 abuse usually starts with a stolen provider key. OWASP's own fixes, running extensions in the user's context with the narrowest OAuth scope and authorising in the downstream system, are identity controls. Give each tool and agent its own identity, keep keys in a secrets manager and record the owner of each. See the Agentic AI Identity Guide and the API Key Management Guide.

Using the Top 10 in a security programme

1. Inventory: list every LLM application with its model, provider, data sources, tools, keys and owner.
2. Threat model per application: walk all ten entries (and the agentic ten where tools exist), record which apply, and write down what a fully manipulated model could reach.
3. Fix the deterministic layer first: secrets out of prompts, authorisation in code, output encoding, tool scopes and quotas. These close parts of LLM02, LLM05, LLM06, LLM07 and LLM10 without any AI-specific product.
4. Add guardrails in monitor mode: run input and output classifiers in log-only mode on real traffic for a few weeks, measure false positives, then enforce. See the AI Guardrails and AI Firewalls Guide.
5. Build a regression suite mapped to the IDs: open-source scanners such as garak, PyRIT and promptfoo can generate probes; tag each test with its 2025 and 2026 ID and run it in CI on every model, prompt or tool change.
6. Gate releases: no production release with an open critical finding against LLM01, LLM05 or LLM06 for applications that hold write tools.
7. Roll out in rings with a rollback path: internal pilot, limited users, then general availability, behind a flag that disables tools or reverts the model and prompt version.

• Small teams: a managed model with provider filters and spend caps, read-only use cases, focus on LLM02, LLM05 and LLM10.
• Large organisations: a central LLM gateway owning keys, quotas, logging and guardrail policy, with Top 10 IDs as fields in threat models and the risk register.

Detection and measurement

Log caller identity, model and prompt versions, token counts, guardrail verdicts, retrieved document IDs and tool calls with arguments. Alert on spend spikes per identity, repeated guardrail hits, unusual tool calls and output linking to unknown domains.

• Coverage: share of LLM applications with a threat model that addresses all ten entries; target 100% for applications in production.
• Attack success rate: per entry and per release from the regression suite, with denominators.
• Tools running as a shared identity: count of tools or agents not using their own identity or the user's delegated context; target zero.
• Prompt templates holding secrets or authorisation rules: target zero, checked by scanning source control.
• Endpoints without authentication or quotas: target zero.
• Time to revoke a leaked model provider key: from detection to replacement.

Framework mapping

ATLAS IDs for LLM01, LLM04 and LLM09 are those OWASP lists; the rest come from the ATLAS data file, so check them against the current matrix. The NIST column is our high-level alignment to the twelve AI 600-1 risks, not a NIST crosswalk. Most entries sit under CIS Controls v8.1 Control 16 and ISO/IEC 27001:2022 A.8.28, A.8.29 and A.5.21.

Common failure patterns

• Citing numbers without an edition: a questionnaire answer of "we cover LLM03" that means poisoning to one reader and agency to another.
• Treating the list as a model problem: a prompt filter for LLM01 while tools still run with an administrator token.
• Authorisation in the prompt: limits written as instructions and never enforced in code, the exact pattern LLM07 describes.
• Testing once: never re-running tests after a model upgrade, new tool or new retrieval source.
• Ignoring the AI tooling's own supply chain: the Amazon Q Developer extension compromise shipped a destructive prompt through a trusted release channel.
• Stopping at the LLM list for agents: agents with memory, delegation and other agents need the agentic ten as well.

Practitioner checklist

• State the edition (2025 or 2026) in every policy, threat model and supplier questionnaire that cites the list.
• Threat model each LLM application against all ten entries, and against ASI01 to ASI10 where it has tools or autonomy.
• Remove secrets and authorisation rules from prompts and enforce them in code.
• Filter retrieval by the caller's permissions and partition vector stores per tenant.
• Encode model output for its destination, use parameterised queries and never execute output directly.
• Give each tool and agent its own scoped identity or the user's delegated context, with approval for high-impact actions.
• Verify model and adapter provenance and keep an AI bill of materials.
• Set per-identity token limits, quotas and spend alerts on every inference endpoint.
• Run a regression suite tagged by OWASP ID in CI on every model, prompt or tool change.

Standards and references

• OWASP Gen AI Security Project: Top 10 for LLM Applications 2025
• OWASP Gen AI Security Project: GenAI LLM Top 10 2026
• OWASP Gen AI Security Project: LLM Top 10 for 2023/24
• OWASP: LLM06:2025 Excessive Agency
• OWASP: LLM08:2025 Vector and Embedding Weaknesses
• OWASP: Top 10 for Agentic Applications for 2026
• OWASP: Agentic AI Threats and Mitigations
• NIST: AI 600-1 Generative Artificial Intelligence Profile

Related NHI Mgmt Group resources: LLM Security Guide · Prompt Injection Guide · AI Guardrails and AI Firewalls Guide · Top 10 Agentic AI Identity Issues · Agentic AI Security Guide