It didn’t take long for large language models to move beyond the chat window. Today’s deployments increasingly give them persistent memory, tool access, credentials, and connections to systems where companies keep their most valuable data. They can retrieve files, query databases, write code, send messages, and initiate business processes.
The recently released OWASP Top 10 for LLM Applications 2026 reflects how quickly that reach has expanded and the importance of agentic AI security.
OWASP’s list gives security leaders, developers, and technology buyers a shared way to identify important security failures affecting LLM applications and connect them to practical controls. It helps organizations focus engineering effort and decide how much authority an AI system should receive before it touches real operations. As LLM applications move deeper into the business, those decisions increasingly affect data exposure, fraud, service availability, regulatory obligations, and the integrity and reliability of automated work.
First published in 2023 and revised for 2025, the OWASP Top 10 has evolved alongside the technology it covers. The 2026 edition marks a shift from protecting the conversation to containing the consequences. Risks involving an application’s access and operational authority gained prominence, while several categories widened to account for reasoning models, multimodal inputs, persistent memory, generated code, and the context supplied to connected AI systems.
The 2026 iteration retains all 10 risk areas from 2025, although several have been renamed or materially reframed. The important changes lie in their ranking, scope, and the boundaries OWASP now draws between related failures.
Excessive agency rose from sixth to third, signaling OWASP’s increased focus on the consequences of granting models operational authority. Unbounded consumption climbed four places as a single request became capable of setting off costly model calls and tool invocations. System prompt leakage became hidden context exposure, covering tool schemas, policy logic, workflow rules, and other operational details beyond the prompt itself.
Prompt injection remains No. 1. The difference now is what may be waiting on the other side of a successful attack: A manipulated chatbot might produce a bad answer. A manipulated agent could reach private data, invoke an overprivileged tool, or take an irreversible action. That widening blast radius runs through OW
The OWASP Top 10 for LLM Applications 2026 at a Glance
| 2026 rank | Risk | 2025 rank | Change |
|---|---|---|---|
| LLM01 | Prompt Injection | 1 | No change; expanded scope |
| LLM02 | Sensitive Information Disclosure | 2 | No change; expanded scope |
| LLM03 | Excessive Agency | 6 | Up three places |
| LLM04 | Supply Chain | 3 | Down one place; expanded scope |
| LLM05 | Data and Model Poisoning | 4 | Down one place; expanded scope |
| LLM06 | Unbounded Consumption | 10 | Up four places |
| LLM07 | Misinformation | 9 | Up two places |
| LLM08 | Hidden Context Exposure | 7 | Renamed and broadened from System Prompt Leakage |
| LLM09 | Vector and Embedding Weaknesses | 8 | Down one place; refined scope |
| LLM10 | Improper Output Handling | 5 | Down five places; expanded scope |
What Is Different About the 2026 List?
Previous editions relied primarily on practitioner judgment. For 2026, OWASP compared that judgment with a corpus of 7,714 publicly documented incidents, 6,639 of which contained enough information to classify. The community vote received 75% of the final weight, with incident data accounting for the remaining 25%.
That comparison exposed gaps between what practitioners fear and what gets documented in the field. Prompt injection ranked first in the community vote but fell outside the top 10 when OWASP considered the incident record alone. In its methodology, the report describes this gap as a defense effect: Organizations invest heavily in preventing and containing prompt injection, while public incident records understate a risk that mature security teams are already spending considerable resources to manage.
Misinformation showed the opposite pattern. Practitioners placed it near the bottom, while the incident record put it near the top. OWASP ultimately moved it from ninth to seventh, reflecting the growing consequences of letting plausible but incorrect output influence people and automated processes.
This mixed methodology makes the list more useful, but it does not turn the rankings into a statistical measure of likelihood. Public incident data remains incomplete, reporting practices vary, and the categories sometimes overlap. The list is best read as a prioritized threat-modeling guide rather than a universal risk score for every LLM application.
OWASP also draws a sharper line between an LLM used as an application component and an agent that can use tools, retain memory, collaborate with other agents, or cause downstream effects. Once the model becomes an actor, OWASP recommends reading this list alongside its Top 10 for Agentic Applications. Most enterprise agent deployments will need both frameworks.
LLM01: Prompt Injection
Prompt injection remains the leading LLM application risk because models process trusted instructions and untrusted data in the same context. A malicious instruction may come directly from a user or arrive through a document, image, tool output, or persistent memory. In MCP-connected systems, content returned by a server can enter the model’s context and influence what it does next.
OWASP says prompting and filtering cannot reliably eliminate the risk on their own. Those measures may reduce exposure, but consequential operations still need authorization outside the model. Permissions should be limited to the request at hand, with human approval reserved for actions that are high-impact or difficult to reverse.
Our assessment: Prompt injection is usually the entry point rather than the entire failure. The damage depends on what the application allows the manipulated model to access or change. An agent without sensitive access presents a far smaller risk than one operating with long-lived administrator credentials.
LLM02: Sensitive Information Disclosure
Sensitive information can escape through the model’s answer, but it can also surface in tool-call records, logs, embeddings, or other artifacts created by the application. Disclosure may involve memorized training data, live information retrieved from connected systems, or derived data produced during fine-tuning and related processes.
The broader scope draws attention to authorization failures in RAG systems. If an application retrieves information that a user should not be able to access, the model may be operating as intended. The access problem occurred before the information entered its context.
Our assessment: Authentication at the application boundary is insufficient when retrieval occurs through a shared, overprivileged identity. Access should be evaluated using the agent’s identity and, when applicable, the identity and authority of the user it represents.
LLM03: Excessive Agency
Excessive agency rose from sixth to third as LLM applications gained more influence over external systems. The risk appears when erroneous or manipulated model output can trigger a damaging action. It applies to any LLM-enabled workflow with privileged capabilities, even if the application is not described as an agent.
OWASP traces the problem to excessive functionality, overly broad permissions, or too much autonomy. Limiting the tools available to the application reduces exposure, while narrow downstream permissions contain the damage when something goes wrong. Each action should also pass through authorization logic that does not depend on the model’s judgment.
Our assessment: A verified agent can still be overprivileged or act outside the conditions that made an earlier request acceptable. Access decisions need to account for the agent’s identity and requested action at runtime. If the agent is acting for a person, that user’s identity and authority must inform the decision as well.
LLM04: Supply Chain
The LLM supply chain includes models, datasets, adapters, repositories, and the systems used to move those components into production. The 2026 entry gives more attention to substituted weights, unsafe file formats, tampered templates, and weak artifact provenance. It also covers “slopsquatting,” in which attackers register package names invented by coding assistants.
Documentation can describe an artifact without proving that it is authentic or unchanged. Organizations need integrity verification and controlled promotion processes for model components, just as they do for software.
Our assessment: Supply chain reviews should also consider what a trusted model is connected to. Artifact verification does not govern which agents may access an MCP server or external resource, while access enforcement does not establish that a model or tool is safe. Organizations need both controls.
LLM05: Data and Model Poisoning
Data and model poisoning changes what an AI system learns, retains, or retrieves. It can occur during training, fine-tuning, or RAG ingestion, as well as through compromised adapters and other model components. The system may continue to behave normally until a particular trigger activates the poisoned behavior.
OWASP distinguishes durable poisoning from malicious instructions encountered during inference, which fall under prompt injection. Attacks that depend on the geometry of an embedding space are addressed separately under vector and embedding weaknesses.
Our assessment: Provenance establishes where a model or dataset came from, but organizations must also control which workloads can modify the repositories and data stores that shape model behavior. Identity-based access can restrict those operations and record who reached the affected resource. Detecting poisoned content and restoring trusted data require separate controls.
LLM06: Unbounded Consumption
Unbounded consumption rose from 10th to sixth as newer models made resource abuse more costly. Extended reasoning can consume large token budgets from a short prompt, while agentic workflows may turn one request into repeated model calls and tool activity. The category also includes denial of wallet, service disruption, and model extraction.
Traditional request limits cannot measure the full cost of these operations. Effective controls need to account for the resources consumed across the workflow and stop activity when it exceeds defined limits.
Our assessment: Consumption is partly an identity and attribution problem. Teams need to know which agent, user, or workload generated the activity before they can apply meaningful limits without disrupting unrelated services. The application and model platform remain responsible for token budgets and spending controls.
LLM07: Misinformation
Misinformation rose from ninth to seventh because incorrect model output increasingly influences human decisions and automated actions. The problem may take the form of fabricated evidence, an inaccurate summary, or a false assessment of system state. It becomes security-relevant when that output is trusted and used.
Independent verification should reflect the potential impact of the resulting action. An incorrect draft is an inconvenience, while a false conclusion that triggers a payment or changes production infrastructure can become a security incident.
Our assessment: A secure design assumes that an uncompromised model will still make mistakes. The system evaluating a proposed action should not rely on the same model to decide whether that action is safe.
LLM08: Hidden Context Exposure
Hidden context exposure replaces system prompt leakage and covers more than the prompt itself. Developer instructions, tool schemas, retrieved policy text, and workflow criteria may all become visible to an attacker. The disclosure matters when it reveals credentials or information that makes other attacks easier.
Anything placed in the model’s context should be treated as potentially discoverable. Security controls should therefore operate independently from instructions the model can reveal or disregard.
Our assessment: The new name better describes the underlying problem. A prompt can guide model behavior, but it cannot reliably enforce authorization or protect a secret placed inside the model’s context.
LLM09: Vector and Embedding Weaknesses
Embeddings support RAG, semantic caches, and vector-backed memory by converting source material into representations used for similarity search. The OWASP category covers risks that depend on that layer, including cross-tenant leakage, retrieval manipulation, and the possibility of inferring sensitive information from embeddings.
Authentication alone does not guarantee properly authorized retrieval. A shared index may expose information through search results, scores, or timing if access is evaluated only after the search occurs.
Our assessment: Retrieval authorization should occur before information enters the model’s context and, where possible, within the system that understands the underlying data entitlements. Identity controls can govern access to the retrieval service, while the application or data platform enforces document-level permissions. Embeddings should be protected as potentially sensitive derived data.
LLM10: Improper Output Handling
Improper output handling fell from fifth to 10th, although its scope expanded. The risk arises when model output reaches another component without the validation appropriate to its destination. Generated SQL may be passed to a database, for example, while model-produced code may reach a shell or unsafe markup may be rendered in a browser.
The 2026 version also addresses terminal control characters, automatic external resource fetching, and untrusted tool output that returns to the application. Each destination requires its own deterministic safeguards rather than trust in the model’s response.
Our assessment: Its No. 10 placement does not make this a low-impact risk for a particular deployment. Any application that executes or renders model output without appropriate controls remains directly exposed.
The Larger Lesson: Design for a Model That Will Fail
The 2026 list challenges a common AI security strategy: trying to build a model that never follows a hostile instruction, reveals hidden context, hallucinates, or produces unsafe output. Defenses against those failures remain valuable, but they do not provide a dependable security boundary.
A stronger architecture assumes the model will eventually fail and limits what can happen next. Credentials and security decisions remain outside the model, while each agent receives only the access required for its current task. When an agent acts on a person’s behalf, the user’s identity and authorization context should also inform the decision. Unattended agents and workflows should operate through their own narrowly scoped workload identities.
Authorization should be enforced on each request, including access to tools and resources exposed through MCP servers. High-impact or irreversible actions may require human approval when meaningful review is possible. Routine automation is better served by deterministic policy checks and appropriate limits, with a viable rollback path when automated actions go wrong.
Applications must also account for the varying trust levels of retrieved content, tool responses, memory, and model output. Activity should be attributed to the identities and workflows involved, with audit records showing who acted, which policy was applied, and what decision followed.
This is where the LLM and agentic risk frameworks meet. Prompt injection may compromise a model’s instructions, while misinformation can corrupt its conclusions. Excessive agency often determines whether those failures reach sensitive data or produce a consequential action.
For enterprises, the practical dividing line is enforcement. Prompts describe desired behavior, while identity, policy, and authorization constrain what the system can actually do.
Aembit provides identity- and policy-based access control for AI agents by verifying the agent’s identity and evaluating each access request at runtime. When an agent acts on someone’s behalf, Aembit uses a capability known as blended identity to combine the agent’s identity with the user’s identity in the access decision. The platform enforces the resulting policy, provides short-lived credentials for authorized access, and records the identities and context involved. r nonhuman identities and AI agents. It verifies the requesting workload, evaluates access at runtime, preserves user context where required, issues short-lived credentials, and records agent activity without relying on the LLM to enforce its own limits.
Related Reading
- The Cybersecurity Risks of Agentic AI: What Security Teams Need to Know
- Human vs. AI Identity: Why AI Agents Are Breaking Identity
- How AI Agents Are Creating a New Class of Identity Risk
- MCP Authentication and Authorization Patterns
