The OWASP GenAI LLM Top 10 2026 is a risk-awareness and engineering guide for applications that use large language models as components. It identifies ten high-priority failure areas ranging from prompt injection and sensitive-data disclosure to excessive agency, supply-chain compromise, poisoned models, resource abuse, misinformation, hidden-context exposure, vector/embedding weaknesses, and unsafe use of model output.
The 2026 edition is more than a rename of the previous list. OWASP changed the ranking, broadened several categories, and introduced a methodology that combines practitioner voting with public incident data. For security teams, the practical lesson is to treat the model as one untrusted component inside a larger system and build controls around identity, tools, data, retrieval, APIs, downstream sinks, and runtime behavior.
What Is the OWASP GenAI LLM Top 10 2026?
The OWASP GenAI Security Project published the 2026 resource in August 2026. It focuses on vulnerabilities and failure modes in LLM-enabled applications. The list is not a compliance standard and it is not a guarantee that addressing ten categories makes an application secure. It is a prioritization framework for threat modeling, design review, testing, procurement, and runtime monitoring.
OWASP reports that the 2026 ranking combines 75% community-vote weight and 25% incident-data weight. The project assembled 7,714 public incidents and classified 6,639 that contained enough detail for categorization. That means the list still reflects practitioner consensus, but public evidence can meaningfully move a category when observed incidents diverge from perceived risk.
OWASP GenAI LLM Top 10 2026: The Complete List
| Rank | OWASP 2026 risk | Primary security concern |
|---|---|---|
| LLM01 | Prompt Injection | Untrusted input changes model behavior or instructions |
| LLM02 | Sensitive Information Disclosure | Model or application exposes confidential information |
| LLM03 | Excessive Agency | Model-enabled actions have too much functionality, privilege, or autonomy |
| LLM04 | Supply Chain | Models, dependencies, datasets, adapters, tools, or build pipelines are compromised |
| LLM05 | Data and Model Poisoning | Training, fine-tuning, retrieval, or model artifacts are manipulated |
| LLM06 | Unbounded Consumption | Uncontrolled inference or resource use causes cost, availability, or extraction risk |
| LLM07 | Misinformation | Incorrect or misleading outputs drive harmful decisions or actions |
| LLM08 | Hidden Context Exposure | Non-user-facing instructions or operational context are extracted or inferred |
| LLM09 | Vector and Embedding Weaknesses | Retrieval and embedding layers leak, corrupt, or expose data and context |
| LLM10 | Improper Output Handling | Unvalidated model output reaches a dangerous downstream sink |
The ordering matters as a prioritization signal, but organizations should not interpret a lower rank as permission to ignore a category. Risk depends on the specific architecture. For example, Improper Output Handling may be the dominant risk in a coding assistant that passes generated commands to a shell even though it appears at number ten.
What Changed From the 2025 OWASP LLM Top 10?
The 2026 list retains ten categories but changes both ordering and scope. The largest shifts are operationally meaningful:
| 2026 category | 2025 position | 2026 position | What changed |
|---|---|---|---|
| Prompt Injection | 1 | 1 | Still first; scope explicitly covers multimodal, retrieved, tool, memory, and indirect inputs |
| Sensitive Information Disclosure | 2 | 2 | Remains second |
| Excessive Agency | 6 | 3 | Moves up sharply as tool-enabled and agent-like applications increase impact |
| Supply Chain | 3 | 4 | Broadens around provenance and trust in models and artifacts |
| Data and Model Poisoning | 4 | 5 | Includes sharper treatment of fine-tuning subversion |
| Unbounded Consumption | 10 | 6 | Moves up as cost and resource exhaustion receive more weight |
| Misinformation | 9 | 7 | Moves up because incident evidence showed higher practical impact than voting alone |
| Hidden Context Exposure | 7, as System Prompt Leakage | 8 | Renamed and broadened beyond the system prompt to hidden operational context |
| Vector and Embedding Weaknesses | 8 | 9 | Moves down one position |
| Improper Output Handling | 5 | 10 | Moves down, while its scope includes unsafe generated code and other downstream uses |
One of the most important conceptual updates is Hidden Context Exposure. The category assumes that information placed in a model context can potentially be discovered. Credentials, tokens, connection strings, authorization rules, and security-critical policy should therefore not depend on secrecy of a system prompt or other hidden context.
The Ten OWASP LLM Risks Explained With Practical Controls
LLM01:2026 Prompt Injection
Prompt injection occurs when untrusted input changes model behavior in a way the application developer did not intend. The input may be typed directly by a user, embedded in a retrieved document, returned by a tool, hidden in an image or audio file, stored in memory, or introduced through another component. A model does not enforce a hard architectural boundary between instruction and data simply because application developers label one “trusted.”
Controls: separate trust zones, minimize exposed tools, restrict privileges, validate retrieval sources, isolate high-risk actions, require deterministic authorization outside the model, and assume some injections will bypass prompt-level defenses. Treat input filtering as one layer rather than the security boundary.
LLM02:2026 Sensitive Information Disclosure
This risk covers sensitive information revealed through model outputs or surrounding application behavior. Exposure may involve user data, proprietary information, credentials, private retrieved documents, model-related information, or sensitive intermediate content. The key question is not only what goes into the prompt, but what the application allows the model to retrieve, remember, infer, and return.
Controls: minimize sensitive data sent to models, enforce authorization before retrieval, mask or tokenize where practical, separate tenants, apply output inspection, limit logging of sensitive prompts/responses, and test for cross-user and cross-tenant leakage.
LLM03:2026 Excessive Agency
Excessive Agency is the ability of an LLM-enabled system to cause damaging actions because it has excessive functionality, excessive permissions, or excessive autonomy. The trigger may be prompt injection, a compromised tool, a misleading peer agent, or ordinary model error. The defining issue is that the system gives probabilistic model output too much authority over consequential actions.
Controls: expose only necessary tools, narrow each tool to the smallest required operation, use least-privilege identities, scope credentials to the user and task, add explicit approval for high-impact actions, put transaction limits around automation, and verify the result independently. Avoid generic “run anything” tools when a constrained API can perform the required task.
LLM04:2026 Supply Chain
GenAI applications depend on more than a base model. They may include open-source libraries, hosted models, adapters, datasets, prompt packages, tool servers, extensions, containers, model files, and CI/CD pipelines. A compromise or substitution anywhere in that chain can alter behavior or execute malicious code before application-level defenses have a chance to respond.
Controls: maintain an inventory of model and software components, verify provenance and signatures where available, pin versions, scan artifacts, restrict unsafe serialization, isolate model loading, monitor dependency and model-repository changes, and assess third-party tool permissions before production use.
LLM05:2026 Data and Model Poisoning
Poisoning changes model behavior by manipulating training data, fine-tuning data, model weights, adapters, retrieval corpora, or related artifacts. A poisoned source can create targeted backdoors or degrade output quality while remaining difficult to detect in normal testing.
Controls: track data lineage, control who can modify training and retrieval sources, validate ingestion, separate trusted and untrusted datasets, monitor for unusual corpus changes, test models for trigger behavior, and use approval/integrity controls around fine-tuning and model promotion.
LLM06:2026 Unbounded Consumption
LLM workloads can consume expensive compute, tokens, memory, external-tool calls, and downstream API capacity. Without limits, an attacker or runaway workflow can cause denial of service, denial of wallet, resource starvation, or repeated extraction attempts.
Controls: enforce request, token, concurrency, time, recursion, and tool-call budgets; use per-user and per-tenant quotas; cap context and output sizes; detect abnormal consumption; stop recursive or looping agent behavior; and define cost-aware circuit breakers.
LLM07:2026 Misinformation
Misinformation is incorrect, fabricated, misleading, or unsupported model output that a person or system treats as trustworthy. The security impact increases when generated facts drive code installation, financial decisions, medical or legal workflows, access changes, or automated tool calls.
Controls: ground high-stakes answers in authoritative data, preserve source provenance, require verification before consequential actions, distinguish generated claims from verified facts, test known failure modes, and prevent downstream systems from treating confidence or fluent wording as proof.
LLM08:2026 Hidden Context Exposure
Hidden Context Exposure is broader than leaking a system prompt. It covers extraction, inference, or reconstruction of non-user-facing system instructions and operational context such as developer instructions, retrieved policy text, tool schemas, workflow criteria, and other implementation details. The risk becomes severe when hidden context contains secrets or when secrecy itself is used as an authorization or policy boundary.
Controls: never store credentials or security-critical secrets in model-visible context, enforce authorization outside the model, keep sensitive tool configuration server-side, minimize hidden context, and design so disclosure of prompts or instructions does not grant additional privilege.
LLM09:2026 Vector and Embedding Weaknesses
Retrieval-augmented generation introduces databases, embedding models, vector indexes, document pipelines, metadata filters, and tenant boundaries. Weak isolation or poisoned retrieval can expose private content, manipulate the context supplied to the model, or allow inference from embeddings and nearest-neighbor behavior.
Controls: enforce tenant-aware access before retrieval, authenticate ingestion paths, validate source provenance, isolate indexes when needed, protect embedding backups as sensitive data, apply metadata filters server-side, and monitor unusual retrieval or corpus modification behavior.
LLM10:2026 Improper Output Handling
Improper Output Handling happens when model-generated content is trusted by a downstream component without appropriate validation, encoding, sanitization, or policy checks. A generated string can become dangerous when interpreted as shell commands, SQL, JavaScript, HTML, Markdown, code, configuration, or a privileged tool argument.
Controls: treat model output as untrusted, use typed interfaces and allowlists, apply context-specific output encoding, avoid eval and shell interpolation, validate structured output against schemas, separate generated content from executable instructions, and enforce authorization again at the downstream action point.
Where the LLM Top 10 Ends and Agentic Security Begins
OWASP draws an increasingly important boundary between model-as-component risk and model-as-actor risk. The LLM Top 10 addresses the model when it operates as a component inside an application. When the model gains tools, persistent memory, inter-agent communication, autonomous planning, and the ability to create real-world consequences, teams should pair this list with the OWASP Top 10 for Agentic Applications.
The two lists overlap by design. Prompt injection can become tool misuse. Hidden context can expose tool capabilities. Improper output handling can reach a privileged function. Excessive agency already sits at the boundary. The practical response is not to choose one taxonomy; it is to threat-model the actual system end to end.
For more on this transition, see Ammune’s guide to AI agent API security risks and API visibility for AI agents.
A Security Control Plan for the 2026 Top 10
Trying to buy one “LLM security” feature for each OWASP category usually creates gaps. A stronger approach is to build several independent control planes around the model.
1. Identity and authorization
Authenticate every actor, bind permissions to the real user and task, use least privilege, and re-check authorization at tool and API boundaries.
2. Data and context controls
Classify data, minimize model-visible secrets, isolate tenants, secure retrieval sources, and maintain provenance for training and RAG content.
3. Tool and action controls
Constrain tools, validate arguments, cap action budgets, add approvals for high-impact operations, and keep privileged execution outside the model.
4. Runtime detection
Observe model-facing APIs, tool calls, request/response data, resource consumption, abnormal sequences, and signs of exfiltration or abuse.
5. Output safety
Validate schemas and downstream values, encode for the target context, and prevent model output from becoming executable merely because it is well formed.
6. Supply-chain governance
Inventory models and dependencies, verify provenance, protect build and promotion workflows, and monitor changes to code, datasets, adapters, and tools.
The guiding principle is simple: do not ask the LLM to enforce the same security boundary that protects you from the LLM. Critical authorization, secrets management, quotas, validation, and enforcement should live in deterministic components around it.
Why API and Runtime Security Matter for LLM Applications
Most production GenAI applications are API systems. The model is called through an API; RAG services retrieve through APIs; agents invoke tools through APIs; sensitive data arrives and leaves through APIs; and model output is often translated into downstream API calls. That makes API boundaries useful points for independent observation and policy enforcement.
| Risk area | Useful runtime signal | Example control |
|---|---|---|
| Prompt Injection | Unexpected input sources, retrieval patterns, tool-call changes | Constrain downstream permissions and detect abnormal flows |
| Sensitive Information Disclosure | Sensitive fields in model/API responses | Response inspection, masking, authorization, egress policy |
| Excessive Agency | Unusual tool sequence, privileged action, high-impact endpoint | Least privilege, approval gates, action budgets |
| Unbounded Consumption | Token/request/tool-call spikes or loops | Rate, concurrency, cost, recursion, and timeout limits |
| Vector/Embedding Weaknesses | Cross-tenant retrieval or unusual corpus access | Tenant authorization and retrieval monitoring |
| Improper Output Handling | Model output reaches an executable or privileged sink | Typed validation and downstream policy enforcement |
This is where API runtime security can complement model-specific safeguards. Runtime visibility can help teams observe live endpoints, identities, requests, responses, data movement, automation patterns, and enforcement outcomes rather than relying only on pre-release tests.
OWASP LLM Top 10 2026 Implementation Checklist
- Map the architecture. Document model providers, prompt assembly, retrieval, vector stores, memory, tools, APIs, identities, downstream sinks, and trust boundaries.
- Inventory untrusted input. Include user prompts, files, web pages, RAG content, images, audio, tool results, messages, and persistent memory.
- Remove secrets from context. Do not place credentials, tokens, or security-critical authorization rules inside model-visible hidden context.
- Constrain agency. Give the model only the tools and permissions required for the current user and task; require approval for high-impact actions.
- Secure retrieval. Authenticate ingestion, enforce tenant authorization before retrieval, validate provenance, and monitor corpus changes.
- Budget resources. Set per-user and per-tenant limits for tokens, requests, tools, concurrency, recursion, time, and spend.
- Validate outputs at every sink. Use schemas, allowlists, encoding, parameterized interfaces, and explicit authorization for generated actions.
- Protect the supply chain. Track model, dependency, adapter, dataset, tool, and container versions with controlled promotion.
- Test realistic attack paths. Include direct and indirect prompt injection, multimodal inputs, poisoned retrieval, cross-tenant access, tool abuse, and unsafe output execution.
- Monitor runtime behavior. Correlate identities, endpoint activity, tool calls, sensitive responses, anomalous sequences, resource spikes, and enforcement actions.
- Prepare containment. Be able to disable a tool, revoke credentials, quarantine a retrieval source, reduce privileges, stop a workflow, and investigate the evidence quickly.
How Ammune Can Fit an OWASP GenAI Security Program
Ammune is most relevant where GenAI applications and agents depend on APIs at runtime. It can be evaluated for API discovery, request and response inspection, sensitive-data visibility, behavioral detection, policy enforcement, and SIEM-ready evidence around model-facing and tool-facing API traffic.
Those capabilities do not replace model evaluation, prompt-specific testing, secure model training, supply-chain controls, deterministic authorization, or dedicated AI guardrails. They provide an independent runtime layer for observing and protecting the API actions and data flows around the model.
Related implementation guidance includes API runtime security protection, AI agent API security risks, and API visibility for AI agents.
Frequently Asked Questions
What is the OWASP GenAI LLM Top 10 2026?
It is OWASP’s 2026 list of ten major security risks for applications that use large language models. It is intended for risk awareness, threat modeling, design review, testing, and security-program planning.
What is number one in the OWASP LLM Top 10 2026?
LLM01:2026 Prompt Injection remains number one. The 2026 scope includes direct and indirect input as well as retrieved content, tool output, multimodal content, and persistent memory that can alter model behavior.
What are the biggest changes from the 2025 list?
Excessive Agency moves from sixth to third, Unbounded Consumption rises from tenth to sixth, Misinformation rises from ninth to seventh, Improper Output Handling moves from fifth to tenth, and System Prompt Leakage is renamed and broadened to Hidden Context Exposure.
Why did OWASP change its 2026 ranking methodology?
The 2026 edition combines practitioner voting with public incident data. OWASP states that community voting carries 75% of the weight and incident data 25%, allowing evidence to adjust—but not replace—community judgment.
What is Hidden Context Exposure?
LLM08:2026 covers unauthorized extraction, inference, or reconstruction of non-user-facing instructions or operational context. Security-critical secrets and authorization rules should not depend on that context remaining hidden.
Is prompt injection fully preventable with input filtering?
No single input filter should be treated as a complete security boundary. A resilient design assumes some malicious instructions may reach the model and limits the consequences through least privilege, deterministic authorization, constrained tools, validation, and monitoring.
What is the difference between Excessive Agency and Improper Output Handling?
Excessive Agency is about giving an LLM-enabled system too much functionality, permission, or autonomy. Improper Output Handling is about trusting model-generated output at a downstream sink without appropriate validation, encoding, or control. The risks can combine in the same attack path.
Does the LLM Top 10 cover AI agents?
It covers risks that affect LLM-enabled applications, including Excessive Agency, but OWASP separates broader model-as-actor risks into the Top 10 for Agentic Applications. Tool-rich, stateful, autonomous systems should be assessed against both resources.
How should an enterprise use the OWASP LLM Top 10?
Start by mapping the GenAI architecture and trust boundaries, then map each risk to preventive, detective, and response controls with owners and test cases. Prioritize based on actual data access, permissions, tools, business impact, and exposure rather than rank alone.
Does addressing the OWASP LLM Top 10 make a system compliant?
No. The Top 10 is a security awareness and engineering resource, not a certification scheme. Organizations still need their own governance, legal, privacy, risk, and compliance controls.
Authoritative References
Protect the API layer around GenAI applications and agents
See how Ammune can help teams discover AI-facing APIs, inspect runtime requests and responses, detect abnormal behavior and sensitive-data exposure, and connect API security evidence to operational workflows.