OWASP Top 10 for LLM Applications: What Every Security Team Needs to Know

Ready to Close the SaaS Security Gap?

Key Takeaways

Prompt injection and excessive agency compound AI risk: LLMs can’t reliably separate trusted instructions from untrusted data, while excessive permissions can turn manipulated outputs into unauthorized actions.
Agentic AI introduces additional risks: Tool access, persistent memory, privileged identities, code execution, and multi-agent communication create risks addressed by OWASP’s Agentic AI Top 10.
OWASP requires continuous controls: Teams should inventory deployments, control permissions and tools, validate outputs, monitor behavior, and align controls with frameworks like NIST AI RMF and ISO 42001.
Reco Graph connects OWASP risks to enterprise context: Reco discovers LLM apps and agents, maps permissions and sensitive-data access, monitors anomalies, and supports frameworks including ISO 42001 and the EU AI Act.

‍

Large language models are now embedded in customer support platforms, coding assistants, and enterprise knowledge systems. These deployments create attack surfaces that conventional application security controls were not designed to protect. Prompt injection, insecure model outputs, data poisoning, and excessive agency require a security approach built specifically for generative AI.

‍

What Is the OWASP Top 10 for LLM Applications?

‍

Published by the OWASP GenAI Security Project, the OWASP Top 10 for LLM Applications is a community-developed framework covering the most significant vulnerabilities in LLM-powered systems. It explains how each vulnerability arises, presents common attack scenarios, and recommends practical mitigation measures. Organizations can use this guidance throughout the development and deployment lifecycle to strengthen the security of their generative AI applications.

‍

What Are the OWASP Top 10 Risks for LLM Applications?

‍

The 2026 OWASP Top 10 for LLM Applications ranks the most significant risks using practitioner consensus and evidence drawn from thousands of real-world AI security incidents.

‍

LLM01: Prompt Injection

‍

Prompt injection occurs when direct user input or externally retrieved content causes an LLM to behave in ways the application developer did not intend. Because models process instructions and data within the same context, they lack a reliable trust boundary between the two. Successful attacks can manipulate responses, expose sensitive information, or trigger unauthorized actions through connected tools.

‍

LLM02: Sensitive Information Disclosure

‍

Sensitive information disclosure occurs when an LLM application exposes confidential, regulated, privileged, or proprietary data through an unauthorized channel. Disclosure can happen through final responses, retrieved content, tool arguments, logs, reasoning traces, embeddings, and other observable system behavior. Sensitive data should therefore be protected throughout the entire LLM workflow, not only at the user interface.

‍

LLM03: Excessive Agency

‍

Excessive agency occurs when an LLM application is given more functionality, permissions, or autonomy than its task requires. A manipulated or incorrect model output becomes far more dangerous when the system can access sensitive data, execute code, modify records, or communicate with external services without effective controls.

‍

LLM04: Supply Chain

‍

LLM supply chain risks extend beyond conventional software dependencies. They include pretrained models, training and fine-tuning datasets, adapters, model repositories, conversion pipelines, and third-party tools. Attackers can compromise any of these components through tampering, poisoning, malicious code, or artifact replacement before they reach production.

‍

LLM05: Data and Model Poisoning

‍

Data and model poisoning occurs when training data, fine-tuning data, embeddings, model weights, or retrieval sources are deliberately manipulated. Poisoning can introduce bias, degrade performance, produce attacker-selected responses, or create backdoors that activate only under particular conditions. Remediation can be difficult because the malicious behavior may be embedded in the model or its supporting data.

‍

LLM06: Unbounded Consumption

‍

Unbounded consumption occurs when an LLM application consumes excessive computational, financial, or operational resources. Attackers can deliberately trigger this behavior, but it can also result from inadequate resource controls. Long contexts, multimodal inputs, repeated tool calls, and extended agentic workflows can make a single request disproportionately expensive. Effective protection requires limits on tokens, execution time, tool use, concurrency, and total cost, rather than request rate limits alone.

‍

LLM07: Misinformation

‍

Misinformation occurs when an LLM produces incorrect, incomplete, unsupported, or misleading information that users or connected systems treat as reliable. The risk becomes more serious in agentic applications because false output can directly influence decisions, tool calls, and automated workflows without human review.

‍

LLM08: Hidden Context Exposure

‍

Hidden context exposure occurs when an application reveals non-public instructions or contextual information supplied to the model. This can include system prompts, internal rules, tool definitions, workflow details, and retrieved context. Developers should assume that information placed in an LLM context may become discoverable and should never store credentials or rely on secrecy alone as a security control.

‍

LLM09: Vector and Embedding Weaknesses

‍

Vector and embedding weaknesses affect systems that use numerical representations and similarity search to retrieve information. Poor access controls, cross-tenant data leakage, poisoned embeddings, and manipulated retrieval results can expose sensitive information or place attacker-controlled content into the model's context. This risk applies to RAG systems, semantic caches, vector-backed memory, and similar architectures.

‍

LLM10: Improper Output Handling

‍

Improper output handling occurs when an application passes LLM-generated content to another component without appropriate validation, sanitization, or encoding. If that output reaches a browser, database, shell, API, or code interpreter, attackers may exploit it to cause cross-site scripting, SQL injection, privilege escalation, or remote code execution. Applications should treat all model output as untrusted input.

‍

OWASP Top 10 for LLM Applications at a Glance

‍

The table summarizes the 10 risks in the 2026 OWASP Top 10 for LLM Applications, with an example and a primary mitigation for each. Use it as a quick reference before examining their enterprise impact and the controls needed to address them.

‍

Risk	Representative Example	Key Mitigation
LLM01: Prompt Injection	Hidden instructions in a retrieved webpage or email cause the model to leak data or invoke unauthorized tools	Restrict tool permissions and require human approval for high-impact actions
LLM02: Sensitive Information Disclosure	A model exposes personal data or credentials through retrieved content, tool arguments, logs, or reasoning traces	Minimize sensitive context and enforce authorization before information is retrieved
LLM03: Excessive Agency	A compromised email assistant uses unnecessary send or delete permissions to expose sensitive messages	Grant only the tools, permissions, and autonomy required for each task
LLM04: Supply Chain	A tampered model or malicious package published under a trusted name reaches production undetected	Verify provenance and require signed, hash-pinned artifacts for models and dependencies
LLM05: Data and Model Poisoning	Poisoned training or retrieval data introduces a backdoor that activates when the model encounters a specific trigger	Validate data provenance, monitor changes, and test models and retrieval systems for hidden behavior
LLM06: Unbounded Consumption	Resource-intensive requests generate excessive cloud costs or degrade service availability	Enforce token budgets, execution limits, usage quotas, and hard spending caps
LLM07: Misinformation	A coding assistant recommends a nonexistent package that an attacker has registered with malicious code	Ground important claims in trusted sources and verify outputs before acting on them
LLM08: Hidden Context Exposure	An attacker extracts a system prompt containing credentials, internal rules, or operational details	Keep secrets out of model context and enforce security controls outside the LLM
LLM09: Vector and Embedding Weaknesses	Weak isolation in a shared vector index allows one tenant to retrieve another tenant’s data	Enforce tenant isolation and authorization within every retrieval query
LLM10: Improper Output Handling	A downstream system executes a malicious script or SQL query contained in unvalidated model output	Treat model output as untrusted input and apply validation and context-specific encoding before use

‍

What the OWASP LLM Top 10 Means for Enterprise AI Security

‍

Several risks in the 2026 list fall outside the scope of traditional security controls. The five below have the greatest impact on how enterprises monitor, govern, and secure LLM deployments.

‍

Prompt Injection Creates a New Attack Surface

‍

LLMs process system instructions, user input, retrieved documents, and tool output within the same context, without a reliable boundary between trusted instructions and untrusted data. The attack surface therefore includes every source the model can read, not only conventional interfaces such as login pages and APIs. The risk becomes critical when an agent can access private data, process untrusted content, and communicate externally. Input validation alone cannot eliminate this architectural weakness.

‍

Excessive Agency Magnifies the Impact of an Attack

‍

Excessive Agency rose to third place in 2026 as enterprises connected LLMs to shells, databases, and external APIs. A hallucination or prompt injection becomes significantly more dangerous when the affected model can execute code, modify data, or use standing credentials. Every unnecessary permission increases the potential impact of a compromised output.

‍

RAG Expands the Data Exposure Surface

‍

RAG places internal documents and databases directly within the model's reach. Weak permissions, poorly scoped retrieval, or shared vector indexes can expose sensitive information across users or tenants. Embeddings can also reveal information through inversion and inference attacks. Enterprises must therefore treat retrieval as a security boundary, with authorization enforced before data enters the model's context.

‍

Supply Chain Risk Now Includes Models and Tools

‍

The LLM supply chain includes pretrained models, datasets, adapters, model services, MCP servers, and third-party tools. Attackers can tamper with any of these components before deployment. In one documented incident, the malicious postmark-mcp npm package secretly copied outgoing emails to an attacker, with researchers estimating exposure across roughly 300 organizations, an incident OWASP catalogs under its Prompt Injection entry as an example of compromised MCP tooling. Enterprises must apply the same provenance, integrity, and review controls to AI components that they already apply to software dependencies.

‍

Unbounded Consumption Threatens Availability and Cost

‍

Unbounded Consumption moved from tenth to sixth place in 2026. Long contexts, extended reasoning, repeated tool calls, and agent loops can make a single request unexpectedly expensive. Attackers can exploit this imbalance to exhaust compute resources or inflate cloud costs. Enterprises need limits on tokens, execution time, tool calls, concurrency, and spending because request rate limits alone are no longer sufficient.

‍

How the OWASP Agentic AI Top 10 Extends the LLM Top 10

‍

Once an LLM can act autonomously (calling tools, holding memory, coordinating with other agents), several LLM Top 10 risks extend into the separate 2026 OWASP Top 10 for Agentic Applications (ASI).

‍

Security Area	LLM Top 10 Focus	Agentic AI Extension	Key Enterprise Controls
Goal manipulation	LLM01: Prompt Injection alters model behavior through malicious input	ASI01: Agent Goal Hijack redirects an agent’s objectives or decision path through malicious content	Goal and intent validation, deterministic policy checks, human confirmation before privileged actions
Tool access	LLM03: Excessive Agency grants more functionality or permissions than a task requires	ASI02: Tool Misuse and Exploitation covers legitimate tools used unsafely, including parameter pollution and tool-chain manipulation	Tool allowlists, argument validation, execution monitoring
Identity and permissions	LLM03: Excessive Agency covers permissions and standing credentials	ASI03: Identity and Privilege Abuse covers agents that inherit or escalate high-privilege credentials across systems	Least privilege, short-lived scoped credentials, per-action authorization
Supply chain and memory	LLM04: Supply Chain and LLM05: Data and Model Poisoning protect models, adapters, and training data	ASI04: Agentic Supply Chain Vulnerabilities and ASI06: Memory and Context Poisoning extend protection to tools, MCP servers, and persistent memory	Provenance checks, signed artifacts, privileged controls for memory writes
Code execution and autonomy	LLM10: Improper Output Handling and LLM03: Excessive Agency cover unsafe output execution and excessive capabilities	ASI05: Unexpected Code Execution and ASI10: Rogue Agents address unauthorized execution and agents acting outside intended control	Sandboxing, execution allowlists, behavioral monitoring, emergency shutdown controls
Multi-agent operations	No dedicated LLM Top 10 category	ASI07: Insecure Inter-Agent Communication and ASI08: Cascading Failures cover spoofed messages and failures propagating across agents	Agent authentication, message integrity checks, failure isolation
Human oversight	LLM07: Misinformation covers false or misleading output	ASI09: Human-Agent Trust Exploitation covers misplaced trust in agent recommendations and social engineering	Clear action previews, independent verification, required approval for high-impact actions

‍

How to Operationalize the OWASP LLM Top 10

‍

Knowing the risks is not the same as controlling them. The five steps below turn the OWASP list into a practical rollout plan for security teams.

Map Every LLM Application to Its Most Relevant Risks: Inventory every LLM application, agent, and integration in use, then score each against the 10 risks based on its actual architecture, not a generic checklist. A closed internal chatbot with no tool access carries a different risk profile than an agent with database write access and external API calls.
Prioritize Prompt Injection and Excessive Agency Controls First: These two risks compound each other, and incident data shows this is where the damage concentrates. Fix the permission and tool access layer before investing heavily in content filtering, since bounding what a compromised model can do matters more than trying to stop every injection attempt.
Validate LLM Outputs Before They Reach Downstream Systems: Treat every model output as untrusted input to whatever receives it. Apply structural validation, output encoding, and parameterized queries before output reaches a shell, database, or browser, regardless of how trustworthy the model has been so far.
Monitor LLM Behavior Continuously, Not Just at Deployment: Log prompts, tool calls, and outputs, and watch for behavioral drift, not just uptime. Static red teaming misses adaptive attackers, so ongoing monitoring and periodic adversarial testing need to run against production traffic, not just pre-launch.
Align Controls With NIST AI RMF and ISO 42001: Map your OWASP-based controls to NIST AI RMF's govern, map, measure, and manage functions and to ISO 42001's AI management system requirements. This gives security work a governance framing that satisfies auditors and regulators without duplicating effort.

‍

How Reco Graph Surfaces OWASP Risk Across Every LLM and Agent

‍

OWASP risks become actionable when security teams can locate them within their own environment. Reco Graph connects applications, agents, identities, permissions, and data flows to provide the context needed to monitor and reduce AI risk.

Discovers Every LLM App, Agent, and Integration: Reco's application discovery capability identifies sanctioned and unsanctioned AI applications, agents, OAuth integrations, and shadow AI tools, giving security teams a current inventory of the components that shape their LLM and agent attack surface.
Surfaces Overpermissioned Agents and Excessive Agency Risk: Reco's identity and access governance maps human and non-human identities to their permissions and access paths, so teams can quickly identify agents with excessive privileges and reduce exposure related to LLM03 Excessive Agency and ASI03 Identity and Privilege Abuse.
Identifies Sensitive Data Accessible to LLM Applications: Reco's data exposure management classifies sensitive information and shows which applications, agents, and identities can access it, helping teams find overshared data before an LLM or connected agent exposes it through retrieval, output, or tool use.
Monitors Agent Behavior in Real Time: Reco's threat detection and response uses behavioral baselines and prebuilt rules to detect anomalous activity, account compromise, and privilege escalation, with investigation-ready alerts integrating into existing SIEM and SOAR workflows.
Maps Risk to OWASP, ISO 42001, and EU AI Act: Reco connects AI activity, access, data exposure, and configuration findings to requirements across OWASP, ISO 42001, and the EU AI Act, giving security teams a continuous view of compliance gaps and an audit trail for demonstrating how AI risks are governed. Reco Factory extends that coverage to emerging LLM and agent platforms in days rather than quarters.

‍

Conclusion

‍

The speed of enterprise AI adoption has created a widening gap between where LLM applications operate and what security teams can actually see. Risks such as prompt injection, excessive agency, sensitive information disclosure, and unbounded consumption become more serious when agents have broad permissions, persistent access, and connections to critical systems.

‍

The OWASP LLM and Agentic AI Top 10 frameworks give organizations a practical foundation for identifying these risks, but a framework alone cannot secure an environment. That requires continuous visibility into every application, agent, identity, permission, and data flow involved. As AI systems become more autonomous and deeply integrated into business operations, security teams must govern them with the same rigor applied to identities, cloud infrastructure, and software supply chains. The organizations that build this visibility now will be better prepared to adopt AI without losing control of the risks it introduces.

FAQs

What is the most exploited OWASP LLM vulnerability in production?

Prompt injection holds the top spot in the 2026 OWASP ranking, and real incidents back that up.

Documented production exploits include the Amazon Q VS Code extension compromise, the Microsoft 365 Copilot zero-click exfiltration (EchoLeak), and MCP-based attacks like the malicious postmark-mcp package.
Indirect injection through retrieved web content, email, and tool output is the most common delivery method in these incidents.
OWASP notes a nuance worth knowing: raw incident counts alone would actually rank it lower, since mature teams already invest heavily in defenses, so fewer successful exploits reach public databases in the first place.

How does the OWASP LLM Top 10 differ from the OWASP Agentic AI Top 10?

The LLM Top 10 covers risk where the model acts as a component inside an application. The Agentic AI Top 10 (ASI) covers risk once that model becomes an actor, calling tools, holding memory, and coordinating with other agents. Read the LLM entry for the input or output level failure, and pair it with the matching ASI entry once an agent can act on that failure repeatedly and autonomously.

Which OWASP LLM risks matter most for enterprises deploying AI agents?

Prompt Injection and Excessive Agency should come first, since incident data shows this is where the damage concentrates once an agent has tool access and standing credentials.

Prompt Injection, because it is the input-side compromise that triggers everything downstream.
Excessive Agency, because it determines how much damage that compromise can actually cause.
Sensitive Information Disclosure, Data and Model Poisoning, and Unbounded Consumption also carry significant weight once tool access and RAG pipelines are involved.

How does Reco map AI agent risk to the OWASP LLM Top 10?

Reco Graph connects every app, agent, identity, and data flow into a single map, so each OWASP risk has a corresponding view in the platform rather than staying theoretical.

New LLM apps, agents, and integrations get surfaced the moment they connect through application discovery, closing the supply chain visibility gap behind LLM04.
Overpermissioned agents tied to LLM03 Excessive Agency get flagged automatically once identity and access governance maps what each identity can actually reach.
Anomalous agent behavior tied to LLM01 Prompt Injection is caught in real time through threat detection and response, with alerts feeding straight into existing SIEM and SOAR workflows.

Findings across all of these feed into posture management and compliance, which gives security teams the full risk breakdown in one place.

How can Reco help enforce least-privilege access across LLM deployments?

Reco's identity and access governance maps every human and non-human identity to the permissions and access paths it actually holds, then flags standing privileges that exceed what an agent's task requires.

Identifies over-permissioned agents and stale or excessive access automatically.
Enforces least-privilege continuously rather than through periodic manual review.
Reduces excessive permissions by 60-90% within 90 days, per Reco's published customer data.

Tal Shapira

ABOUT THE AUTHOR

Tal is the Cofounder & CTO of Reco. Tal has a Ph.D. from the school of Electrical Engineering at Tel Aviv University, where his research focused on deep learning, computer networks, and cybersecurity. Tal is a graduate of the Talpiot Excellence Program, and a former head of a cybersecurity R&D group within the Israeli Prime Minister's Office. In addition to serving as the CTO, Tal is a member of the AI Controls Security Working Group with the Cloud Security Alliance.

Technical Review by:

Gal Nakash

Technical Review by:

Tal Shapira