What organizations should do: Verify the origin and Supplier of Models, Datasets, and Components. Maintain an SBOM, AIBOM, or ML-BOM, use Hashes and Digital Signatures to verify Artifacts, and evaluate Model behavior before deployment into Production.

However, Digital Signatures confirm the origin and Integrity of an Artifact but do not guarantee that the Model is secure or free from Backdoors. They should therefore be combined with behavioral testing and Model evaluation before production use.

5. LLM05:2026 Data and Model Poisoning

Data and Model Poisoning occurs when data or Model Artifacts are inserted, modified, or contaminated in ways that cause an AI system to learn or behave incorrectly, potentially introducing Bias, Backdoors, or vulnerabilities that can be exploited.

This risk may occur throughout multiple stages of an AI system, including Pre-training, Fine-tuning, Embedding generation, RAG, Model Distribution, Continuous Learning, and Feedback Loops. It may result either from deliberate attacks or inappropriate data management.

One reason Poisoning is particularly concerning is that the system may continue to appear normal while containing a hidden Backdoor or Trigger that changes its behavior only under specific conditions. As a result, standard testing may fail to identify the issue.

What organizations should do: Maintain the history and origin of Datasets and Models (Lineage), validate information before ingestion, implement Version Control, separate Trusted and Untrusted Data, and continuously test Models for hidden Triggers or Backdoors.

6. LLM06:2026 Unbounded Consumption

Unbounded Consumption is a risk that occurs when an LLM system does not sufficiently control resource usage, allowing requests or Workflows to consume excessive amounts of Tokens, Compute, Memory, or Tool Calls, potentially affecting both system availability and organizational costs.

The risk becomes more significant with Reasoning Models, Multimodal Models, and AI Agents because a single request may trigger multiple rounds of processing, use large Context windows, or continuously and recursively call Tools, rapidly increasing resource consumption.

The impact may include Denial of Service (DoS), making systems slow or unavailable, and Denial of Wallet (DoW), where Cloud or AI service costs increase beyond control. OWASP also includes the risk of submitting large numbers of Queries to perform Model Extraction or create imitation models.

What organizations should do: Controls should not be limited to the number of Requests. Organizations should also implement Token Limits, Spending Caps, Step Limits, Recursion Limits, and Time Limits, together with Circuit Breakers to stop Agent Workflows that loop continuously or consume abnormal amounts of resources.

7. LLM07:2026 Misinformation

Misinformation is the risk that an LLM generates information that is incorrect, incomplete, unsupported by evidence, or misleading, while presenting it in a convincing manner. The risk becomes significant when users or other systems rely on that information to make decisions or perform further actions. Examples include incorrectly interpreting a Policy, recommending a Package that does not exist, summarizing information while omitting important details, or reporting that a task has been completed when no action was actually performed. These situations may lead to financial, Security, or operational damage.

What organizations should do: Apply the Claim–Check–Act concept by separating response generation from execution. Verify information against trusted sources and the actual state of the system before acting on it. Model confidence alone should never be treated as evidence that information is correct.

8. LLM08:2026 Hidden Context Exposure

Hidden Context Exposure is the risk that internal information not intended to be visible to users is disclosed, inferred, or reconstructed through interactions with an LLM.

In 2026, OWASP renamed System Prompt Leakage to Hidden Context Exposure to expand its scope beyond System Prompts to include internal information such as:

• System Prompt
• Developer Instructions
• Tool and Function Schema
• Internal Policy
• User Role and Permission
• Workflow Logic
• Refusal and Filtering Rules

This information may help attackers understand the architecture, behavior, and restrictions of a system and use that knowledge to plan Prompt Injection or subsequent attacks.

A key OWASP principle is that systems should be designed under the assumption that anything placed within the LLM Context may eventually be discovered or exposed. Therefore, system security should not depend solely on keeping this Context secret.

What organizations should do: Do not place Passwords, API Keys, Tokens, or Connection Strings in the Context. System Prompts should also not be used as the primary mechanism for enforcing permissions or Security Policies. Instead, Authorization and Access Control should be enforced by external systems that can be explicitly controlled and audited.

9. LLM09:2026 Vector and Embedding Weaknesses

Vector and Embedding Weaknesses are risks found in systems that convert text, images, code, or audio into Embeddings and use Similarity Search to identify relevant information before passing it to an LLM. RAG (Retrieval-Augmented Generation) is one of the most common examples.

If Embedding storage and retrieval processes are poorly designed, risks may include Cross-Tenant Leakage, Embedding Inversion, Retrieval Poisoning, Retrieval Jamming, Membership Inference, and Semantic Cache Poisoning, which can result in data leakage, manipulated information, or malfunctioning retrieval systems.

For example, in a multi-Tenant system using a Shared Vector Index, if Similarity Search is performed across all data before permissions are checked, an attacker may use the number of returned results, similarity scores, or response timing to infer whether another Tenant’s information exists, as well as its approximate topic or volume, even without directly viewing the document.

Another significant risk is Embedding Inversion, which may allow leaked Embeddings to be used to reconstruct original content. Therefore, Vector Databases and Backups containing Embeddings should be protected at the same level as the original information.

What organizations should do: Enforce Tenant Scope and Permissions during the Retrieval process rather than filtering results afterward. Apply Access Control at the Chunk level, separate Indexes according to Tenant or data sensitivity, and protect Vector Databases and Backups using appropriate encryption, access controls, and Monitoring.

10. LLM10:2026 Improper Output Handling

Improper Output Handling is the risk that output generated by an LLM is passed to another system without proper validation, filtering, or handling. This may include passing AI output to a Browser, SQL Database, Shell, File System, Email, IDE, or API.

If the receiving system directly processes or Executes AI-generated Output, it may introduce vulnerabilities such as XSS, SQL Injection, Path Traversal, Remote Code Execution, or Data Exfiltration. For example, an AI may generate an SQL Query that the application immediately executes, or generate JavaScript/Markdown that is rendered by a Browser without proper filtering.

The key principle is that Output generated by an LLM should be treated as Untrusted Input and validated before being passed to another system. Even if the Output conforms to the expected Schema, this does not mean that the content itself is safe.