OWASP Top 10 for LLM Applications 2026, Mapped to Controls

The current OWASP Top 10 for LLM Applications is the 2026 edition, and it is not the list most security programs mapped their findings to. Prompt injection still holds the top spot. Excessive agency jumped from sixth to third. System prompt leakage was renamed Hidden Context Exposure and broadened, and improper output handling fell from fifth to tenth.

If your risk register, pentest reports, or vendor questionnaires still cite LLM06 for excessive agency, that ID now points at a different risk. The risk names, numbers, and scope below come from OWASP's own documents. The explanations are mine, and so are the controls, owners, and tests. Those come from a career spent building identity and access infrastructure, where most of the LLM controls end up living anyway.

Verified as of 29 October 2026 against the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026, both published by the OWASP GenAI Security Project.

Which edition is current, and why two lists are floating around

OWASP published the 2026 edition in early August 2026. The resource page is dated 3 August 2026 and the document's cover reads 4 August 2026. Earlier releases were version 1.0 in August 2023, version 1.1 in October 2023, and the 2025 edition in November 2024.

One trap is worth knowing about. When I checked on 29 October 2026, OWASP's main LLM Top 10 landing page still listed the 2025 entries. The legacy owasp.org project page still pointed to "Version 2025". The 2026 document lives on its own resource page. Search for the list and you will find both, numbered differently.

The 2026 edition is also the first one built partly on evidence rather than on opinion alone. The project collected 7,714 incidents from public vulnerability databases and an AI-harm database, then classified the 6,639 that carried enough detail. The practitioner vote carried three-quarters of the weight in the final ranking, and the incident data carried the remaining quarter.

The disagreements between the two are the interesting part. Ranked by raw incident count, prompt injection falls out of the top ten entirely. OWASP keeps it at number one and calls the gap a "defense effect": teams fight injection hard, so fewer clean exploits reach public databases. Misinformation runs the other way. Voters placed it near the bottom, while the incident record placed it near the top.

The 2025 to 2026 renumbering

Use this to translate old findings and questionnaires. Eight of the ten entries changed position.

2026 ID	Risk	2025 ID
LLM01:2026	Prompt Injection	LLM01:2025
LLM02:2026	Sensitive Information Disclosure	LLM02:2025
LLM03:2026	Excessive Agency	LLM06:2025
LLM04:2026	Supply Chain	LLM03:2025
LLM05:2026	Data and Model Poisoning	LLM04:2025
LLM06:2026	Unbounded Consumption	LLM10:2025
LLM07:2026	Misinformation	LLM09:2025
LLM08:2026	Hidden Context Exposure	LLM07:2025 (System Prompt Leakage, renamed and broadened)
LLM09:2026	Vector and Embedding Weaknesses	LLM08:2025
LLM10:2026	Improper Output Handling	LLM05:2025

Several entries also grew. Prompt injection now covers cross-modal attacks hidden in images or audio. Supply chain now covers a promoted model artifact that is not what it claims to be. Data and model poisoning absorbs fine-tuning subversion. Improper output handling now spans the insecure code that coding assistants generate.

The idea that runs through all ten

The project leads open the 2026 document with a line worth pinning above your desk: "Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks."

That has a practical consequence for who does the work. Very few of the controls below live inside the model. They live in application code, in the identity layer, in the retrieval layer, in CI/CD, and in the gateway in front of the model. That is why ownership splits three ways.

Throughout this post, the owners mean the following. These assignments are my recommendation, not OWASP's.

• App team. The engineers building the LLM feature: prompts, tool definitions, the code that acts on model output.
• Platform. Whoever runs the shared pieces: the AI gateway, model hosting, vector stores, the model and package registry, CI/CD, secrets, and workload identity.
• Security. Threat modeling, policy, red teaming, monitoring, and incident response.

The ten risks, mapped to controls

LLM01:2026 Prompt Injection

What it is. A language model cannot tell instructions apart from data, because both arrive as tokens in the same stream. Anything the model reads can redirect it: a user message, a retrieved document, a tool response, an image, or a memory entry from last week. The dangerous version is indirect. The attacker never talks to your model; they plant text somewhere your model will read while it holds your user's permissions. OWASP's 2026 entry is blunt that no reliable prevention mechanism exists today, so the defense has to be architectural.

A researcher's write-up shows what that looks like in production. In August 2024, Johann Rehberger documented a Microsoft 365 Copilot chain in which instructions hidden in an email made Copilot search the user's other mail. Copilot then encoded the contents as invisible Unicode characters inside a normal-looking link. His proof of concept demonstrated theft of sales figures and Slack MFA codes. He reports that the original exploits later stopped working and that Copilot no longer renders the links.

Control. Hold credentials and state-changing power in application code, not in the model, and route every privileged call through a deterministic policy check at execution time. Budget capabilities using Meta's Agents Rule of Two, which OWASP adopts as a floor. Treat any agent that combines untrusted input, sensitive data, and the ability to change state or communicate externally as needing per-action human approval. Strip invisible Unicode at every ingest and render boundary: the tag block (U+E0000 to U+E007F), variation selectors (U+FE00 to U+FE0F), and zero-width characters (U+200B, U+200C, U+200D, U+2060).

Owner. App team for tool scoping and approval steps. Platform for Unicode stripping at the gateway. Security for the test program.

Test. Plant an injection in every content source the model reads: a document in the RAG index, a support ticket, a tool response, an image. Then assert that no privileged tool call fires without approval. OWASP's specific guidance is to test against adaptive attackers who have read your defenses, and to reject results from static attack sets alone. The practical first pass at red-teaming an LLM covers how to build that probe set.

LLM02:2026 Sensitive Information Disclosure

What it is. Confidential or regulated data leaves through a channel nobody authorized. The 2026 entry is explicit that the final answer is only one channel. Tool-call arguments, reasoning traces, retrieved chunks, logs, telemetry, embeddings, and even response timing can all leak. OWASP names two structural drivers. The first is oversharing upstream, where RAG is pointed at drives with legacy permissions and retrieves exactly what it was designed to. The second is persistence: data that shaped weights or embeddings stays extractable after the source is deleted.

Control. Authorize before retrieval. Enforce document and chunk permissions inside the index query, not as a filter after results come back, because a chunk already handed to the model cannot be taken back. Keep secrets and regulated data out of system prompts. Scrub logs and traces before they reach your observability platform, since OWASP notes those platforms log full prompts and completions by default. Send providers only the fields the task needs; what each provider then keeps is a separate question, covered in my breakdown of zero data retention.

Owner. Platform for retrieval-layer authorization and log scrubbing. App team for context minimization. Security for data classification and DLP rules.

Test. Seed the index with canary documents that user A can read and user B cannot. Query as user B with direct requests, paraphrases, and summarization tasks. The canary text must never appear in an answer, a tool argument, or a trace. Then search your observability store for the canary string, because that is where it usually turns up.

LLM03:2026 Excessive Agency

What it is. Damage happens when model output, whatever made it go wrong, reaches a tool with more power than the task needs. The cause might be an injection, a hallucination, or a compromised peer agent. Excessive agency is about what that bad output can then do. OWASP names three root causes: excessive functionality, excessive permissions, and excessive autonomy. It moved up to third because, in OWASP's words, the vote and the incident record agree that "agentic deployments are where the damage is landing."

Control. Offer the fewest tools possible, and the fewest functions per tool. An email summarizer needs read, not send or delete. Replace open-ended tools such as "run shell command" or "fetch URL" with narrow ones that take a strict schema. Give each tool's downstream identity only the permissions the feature needs. Execute actions in the user's own context, for example through OAuth with minimal scope, and preserve that user context across chained calls. Decide authorization in code, never by asking the model. OWASP's graduated example is useful here: a refund as store credit can auto-approve because it is recoverable, while an external payout goes to a human.

Owner. App team for tool design. Platform and the identity team for delegated authorization and scoped credentials. Security for the approval policy.

Test. List every tool, every function, and every permission each tool's identity holds, then diff that against what the feature actually needs. Use an injected prompt to try forcing each destructive function. The call should fail at the policy layer, not because the model happened to decline. Then check whether your logs can name the human who authorized each action, which is the gap I wrote about in why your AI agent has no idea who authorized it.

LLM04:2026 Supply Chain

What it is. Every model, dataset, LoRA adapter, conversion tool, serving framework, and package you did not build yourself is an attack surface. OWASP points out that a model card documents a model but does not prove where it came from. The 2026 entry also covers "slopsquatting": coding assistants suggest plausible package names that do not exist, and attackers register those names in advance.

The classic software incidents carry straight over. In December 2022, PyTorch disclosed that a malicious torchtriton package on PyPI was installed in place of its own nightly dependency. The binary read SSH keys, .gitconfig, and up to the first 1,000 files in the home directory, and uploaded them over DNS. In December 2024, PyPI's analysis of the Ultralytics compromise found the attack targeted the GitHub Actions cache used during the build. A second round used an unrevoked PyPI API token. Four versions were removed.

Control. Keep a signed inventory of every model, adapter, and dataset in production, using an SBOM extended to AI components (OWASP points to CycloneDX ML-BOM and its own AIBOM project). Reference artifacts by immutable digest, never by a mutable tag or a bare author and model name. Sign models and verify signatures at load, for example with the OpenSSF Model Signing project and Sigstore. Treat model conversion and merge steps as high-risk promotion points. Verify that every AI-suggested dependency exists and is the package you meant. OWASP's caveat matters: signing proves origin, not safety.

Owner. Platform for the registry, pinning, and signature checks in CI. Security for supplier vetting. App team for dependency hygiene.

Test. Try to deploy a model referenced by name instead of digest; the pipeline should refuse. Alter one byte of a signed artifact; loading should fail. Reconcile the inventory against what is actually running, and treat anything missing from it as an incident.

LLM05:2026 Data and Model Poisoning

What it is. Someone corrupts what the model learns or relies on, at pre-training, fine-tuning, embedding creation, or through a feedback loop. The result can look normal until a trigger fires. Poisoning is expensive because the fix is rarely a patch. It means revalidating data, retraining, or replacing the model. OWASP's 2026 entry cites research finding that as few as 250 poisoned documents compromised models from 600 million to 13 billion parameters, regardless of dataset size.

Control. Track dataset and model lineage, and keep data under version control so you can roll back and investigate. Validate incoming data and vet third-party sources. Put human review and rate limits on any automated retraining or feedback loop, since OWASP notes an attacker needs only normal user access to push one. Treat chat templates, tokenizer configs, and adapters as code: sign them, hash them, and diff them before deployment.

Owner. Platform, or the ML platform team where one exists. App team for any user feedback loop. Security for trigger probing.

Test. Run trigger-probing red-team passes after every fine-tune and alignment cycle; OWASP warns not to assume safety training removes backdoors. Diff the chat template and tokenizer config on every model update. Rehearse a rollback to the previous dataset version before you need it.

LLM06:2026 Unbounded Consumption

What it is. Uncontrolled inference causes an outage, a runaway bill, or a stolen model. OWASP calls out the cost asymmetry: an attacker can trigger expensive computation at almost no cost to themselves. The newer forms are subtle. Reasoning models can be pushed into long thinking loops by short prompts, and one agent task can fan out into hundreds of tool calls. Long sessions also re-process a growing context on every turn. OWASP's own example has per-turn cost climbing from about $0.001 on the first turn to about $0.50 by turn 100, with no single request tripping a rate limit.

Control. Rate-limit on tokens and estimated cost, not just requests per second, and estimate tokens before inference starts. Set hard spending caps per key, user, team, and account that halt inference rather than send an alert. Put circuit breakers on every agent run: step limits, recursion depth, time limits, and a per-run cost ceiling. Authenticate every inference endpoint, and keep serving frameworks patched.

Owner. Platform for the gateway, quotas, and caps. App team for agent step and depth limits. Security, with finance, for cost-anomaly monitoring.

Test. Send near-limit inputs and reasoning-heavy prompts under load. Point an agent at a test tool that always answers "call me again", and confirm the breaker trips. Exhaust a test budget and verify that inference actually stops.

LLM07:2026 Misinformation

What it is. The model produces something wrong, incomplete, or unsupported, and a person, workflow, or agent acts on it. OWASP frames the core risk as the wrong output being trusted. In agentic systems this shows up as false state. An agent decides a condition is met when it is not, or reports a task complete when it never ran. This is the entry with the widest gap between the vote and the evidence, and the project leads' opening letter singles it out as the one to slow down on.

Control. Use what OWASP calls a claim-check-act pattern: separate generation from execution, and verify the claim against an authoritative source or the real system state before acting. Validate tool-call preconditions against current state, not against what the model says the state is. Require structured outputs with mandatory fields, which catches omissions. Route high-impact actions through approval.

Owner. App team, with the product owner deciding which decisions need verification. Security for adversarial test cases.

Test. Build an evaluation set where the correct answer is "not met" or "not verified", and assert the workflow stops. Make a tool fail silently and see whether the agent still reports success. OWASP's scenario of a nightly backup reported as complete when it never ran is a good one to copy.

LLM08:2026 Hidden Context Exposure

What it is. This was System Prompt Leakage in 2025. The 2026 version covers everything a user is not meant to see but the model can: the system prompt, developer instructions, retrieved policy text, and tool and function schemas. OWASP's design assumption is the right one. Treat hidden context as discoverable, and make sure discovering it has little or no security impact. Severity depends on what you put in there and how much you rely on it staying secret.

Control. Never put credentials, connection strings, or tokens in hidden context. Enforce authorization, privilege separation, and content policy in deterministic systems outside the model, not through instructions the model is asked to follow. Where tasks need different access levels, split them by authorization context.

Owner. App team. Security reviews prompts and tool descriptions the way it reviews configuration.

Test. Scan prompts and tool descriptions for secret patterns in CI. Then run the thought experiment as a review gate: if this system prompt were posted publicly tomorrow, would anything need rotating or redesigning? If the answer is yes, the control has failed.

LLM09:2026 Vector and Embedding Weaknesses

What it is. Once similarity search decides what the model sees, the embedding layer is part of your trust boundary. OWASP's one-line framing is the clearest summary on the list: "poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate". Tenant filtering applied after similarity search can still reveal what other tenants hold through result counts, scores, and timing. Leaked embeddings can be inverted back into much of their source text. A single "blocker" document can make a RAG system refuse to answer a target query.

Control. Enforce tenant scope inside the index query and validate it server-side; a client-supplied scope is a suggestion. Use separate indexes per tenant or trust tier for sensitive workloads, and apply access control at the chunk level. Strip zero-width characters and hidden text before embedding, and record provenance for every vector. Do not return raw similarity scores to clients. Delete embeddings when their source is deleted, and treat vector backups as sensitive as the source documents.

Owner. Platform for the vector store. Security for an incident playbook that treats an "embeddings only" leak as a source-data leak.

Test. Run cross-tenant probe queries and compare result counts and latency for content that should be invisible. Delete a source document and confirm its vectors are gone within your stated window. Check every retrieval API response for score or distance fields.

LLM10:2026 Improper Output Handling

What it is. Model output flows into a browser, shell, database, file path, terminal, or email template without validation. Because prompt input can steer that output, this effectively hands users, and anyone who can inject into the model, indirect access to every downstream system. The results are familiar: XSS, SQL injection, SSRF, path traversal, and remote code execution. The 2026 entry adds ANSI escape sequences written to terminals and Markdown images that exfiltrate data through their URL. It also adds generated code shipped without review.

Control. Treat the model as an untrusted user and apply normal input validation to everything it sends downstream, following OWASP ASVS. Use context-aware output encoding, parameterized queries, and a strict Content Security Policy. Strip control characters before output reaches a terminal or log viewer. Disable automatic rendering of Markdown images and link previews, or restrict fetches to an allowlist. Put generated code through the same review and static analysis gates as human code. A low rank is not permission to skip this one; it is the most familiar application security work on the list.

Owner. App team. Platform for any shared chat renderer. Security for scanning generated code.

Test. Run ordinary application security tests with the model as the input source. Make it emit a script tag, SQL metacharacters, a ../ path, an ANSI escape sequence, and a Markdown image pointing at an external host. Assert that every one is neutralized before it reaches its sink.

Summary table: risk, control, owner, test

Risk	Core control	Owner	How to test it
LLM01 Prompt Injection	Privilege and credentials in code, deterministic policy check, Rule of Two, strip invisible Unicode	App team, platform, security	Plant injections in every source; adaptive red team; no privileged call without approval
LLM02 Sensitive Information Disclosure	Authorize inside the retrieval query; no secrets in prompts; scrub logs and traces	Platform, app team, security	Canary documents queried by an unauthorized user; search traces for the canary
LLM03 Excessive Agency	Minimal tools, functions, and permissions; act in user context; authorization in code; approval for high impact	App team, platform and identity, security	Diff permissions against need; force destructive calls; confirm human attribution in logs
LLM04 Supply Chain	Signed AI inventory; pin by digest; model signing; verify suggested packages	Platform, security, app team	Deploy by name should fail; tampered artifact should fail to load; reconcile inventory
LLM05 Data and Model Poisoning	Lineage and data version control; gated retraining; sign templates and configs	Platform, app team, security	Trigger probing after each training cycle; template diffs; rollback drill
LLM06 Unbounded Consumption	Token and cost quotas; hard caps that halt; agent circuit breakers	Platform, app team, security with finance	Load with heavy prompts; looping tool trips the breaker; exhausted budget stops inference
LLM07 Misinformation	Claim-check-act; verify state before action; mandatory output fields	App team, product, security	"Not met" eval cases must stop the workflow; silent tool failure must not report success
LLM08 Hidden Context Exposure	No secrets in hidden context; enforce policy outside the model	App team, security	Secret scanning in CI; "published tomorrow" review gate
LLM09 Vector and Embedding Weaknesses	Tenant scope inside the query; per-tenant indexes; provenance; no raw scores; deletion sync	Platform, security	Cross-tenant probes; deletion reconciliation; check APIs for score fields
LLM10 Improper Output Handling	Model as untrusted user; context-aware encoding; parameterized queries; no auto-rendered images	App team, platform, security	Emit XSS, SQL, path, ANSI, and image payloads and confirm each is neutralized

Where the agentic list takes over

The LLM Top 10 is not the whole picture once your model starts taking actions. The 2026 document draws the boundary itself: "This list owns the risk when the model is a component inside your application". Once the model has tools it can call, memory it carries between sessions, and consequences downstream, OWASP says the risk moves to its agentic list. It recommends reading the two together, "because neither one covers that ground alone."

That second list is the OWASP Top 10 for Agentic Applications 2026, published in December 2025 by the project's Agentic Security Initiative. Its entries are:

1. ASI01 Agent Goal Hijack
2. ASI02 Tool Misuse and Exploitation
3. ASI03 Identity and Privilege Abuse
4. ASI04 Agentic Supply Chain Vulnerabilities
5. ASI05 Unexpected Code Execution (RCE)
6. ASI06 Memory and Context Poisoning
7. ASI07 Insecure Inter-Agent Communication
8. ASI08 Cascading Failures
9. ASI09 Human-Agent Trust Exploitation
10. ASI10 Rogue Agents

The 2026 LLM document maps its entries onto these explicitly. Excessive agency, for example, shows up in agentic systems as ASI02 tool misuse, ASI03 identity and privilege abuse, and ASI08 cascading failures. The LLM supply chain entry hands MCP servers and tool registries to ASI04. The vector and embedding entry hands memory attacks that do not depend on embedding geometry to ASI06.

In practice: if your feature is a model answering questions over your data, the LLM list is enough. If it calls tools, keeps memory, or talks to other agents, use both lists. The identity work is where most teams are thinnest. The Agent Security Map tracks which vendors claim which agent identity controls. The guide to securing an MCP server and the guide to egress control for AI agents walk through two of the controls step by step.

Where to start if you have one week

Ten risks is a lot to work in parallel. If I had a week and a production LLM feature, I would do these five, in this order, because each is cheap and closes a path that several risks share.

1. Inventory every tool and the permissions behind it. This covers LLM03 and caps the blast radius of LLM01.
2. Move every secret out of prompts and tool descriptions. This closes the worst case of LLM08 and part of LLM02.
3. Push authorization into the retrieval query. One change addresses both LLM02 and LLM09.
4. Set hard spending caps and agent step limits. LLM06 is the risk most likely to show up as a bill before it shows up as a breach.
5. Encode model output for every sink, and stop auto-rendering images. LLM10 is standard application security work your team already knows how to do.

Frequently asked questions

What is the latest version of the OWASP Top 10 for LLM Applications?

The 2026 edition, published by the OWASP GenAI Security Project in early August 2026. As of 29 October 2026, OWASP's main LLM Top 10 landing page still showed the 2025 list, so check the ID suffix. Entries in the current edition carry ":2026", for example LLM03:2026 Excessive Agency.

What changed between the 2025 and 2026 OWASP LLM Top 10?

Eight of the ten entries moved. Excessive Agency rose from sixth to third, Unbounded Consumption rose from tenth to sixth, and Improper Output Handling fell from fifth to tenth. System Prompt Leakage became Hidden Context Exposure with a broader scope. The ranking also used incident data for the first time, weighted at a quarter against the practitioner vote.

Can prompt injection be fully prevented?

Not today, according to OWASP's 2026 entry, which states that no reliable prevention mechanism exists because models do not separate instructions from data. The workable goal is to make a successful injection harmless. Keep privileges in code, require approval for high-impact actions, and never let one agent combine untrusted input, sensitive data, and external actions without a human check.

Is the OWASP LLM Top 10 a compliance standard?

No. It is a risk awareness document, and OWASP states it does not constitute legal advice. It is useful as a shared taxonomy for findings, and the 2026 edition includes an appendix mapping each entry to MITRE ATLAS, NIST AI 600-1, the NIST AI RMF, and the CSA AI Controls Matrix. For a certifiable AI management system, look at ISO 42001, which I cover in what ISO 42001 actually certifies.

Does the OWASP LLM Top 10 cover AI agents?

Partly. It covers the model as a component, including excessive agency. Once the model acts on its own with tools, memory, and downstream consequences, OWASP points to the separate Top 10 for Agentic Applications 2026. It advises using both together.

Who should own OWASP LLM Top 10 controls?

No single team. In most organizations the app team owns tool design, prompts, and output handling. The platform team owns the gateway, retrieval layer, registries, and spending caps. Security owns threat modeling, red teaming, and incident response. Put the owner for each risk in writing, because the controls that fall between teams are the ones that never get built.