The OWASP Top 10 for Large Language Model Applications is a standard awareness document that represents the most critical security vulnerabilities and risks for applications using large language models. You can read the full, current details through the OWASP GenAI LLM Top 10 Guide.
The top 10 LLM security risks:
This is part of a series of articles about agentic AI Security
In this article:
The OWASP LLM Top 10 is maintained by the OWASP GenAI Security Project, an open-source initiative within the Open Worldwide Application Security Project (OWASP). The project brings together security researchers, developers, AI practitioners, and other contributors who work on security guidance for generative AI systems.
Contributors update the guidance as LLM architectures, application patterns, and attack techniques evolve. The work is community-driven rather than controlled by a single vendor, which allows findings and mitigation guidance to incorporate experience from researchers and practitioners across the industry.
Prompt injection occurs when input changes an LLM’s behavior in a way the application developer did not intend. The input can come directly from a user or indirectly from retrieved documents, websites, emails, tool responses, images, audio, or persistent memory. Because instructions and data enter the model through the same context, malicious content can influence both model responses and connected tools.
For example, an attacker can place hidden instructions on a web page that an LLM is asked to summarize. When the page is retrieved, those instructions can make the model generate a request that sends private conversation data to an attacker-controlled server.
Mitigation:
Sensitive information disclosure occurs when an LLM system exposes confidential, regulated, privileged, or proprietary information without authorization. Disclosure can happen through normal responses, retrieved RAG content, reasoning traces, tool arguments, logs, embeddings, or even observable properties such as response timing and token length.
For example, an LLM connected to a shared legal RAG index could retrieve information belonging to one client and include that client’s privileged strategy in an answer generated for another client.
Mitigation:
Excessive agency occurs when an LLM is given more functionality, permissions, or autonomy than it needs. If the model produces an unexpected or manipulated output, those capabilities can turn a model error or prompt injection into a real action against files, databases, email systems, or other connected services.
For example, an email assistant only needs to read messages to summarize them, but its email tool also supports sending messages. An indirect prompt injection inside an incoming email could tell the assistant to find sensitive information and forward it to an attacker.
Mitigation:
Supply chain risks arise from third-party models, datasets, adapters, libraries, model formats, conversion services, and deployment platforms used to build and operate LLM applications. Attackers can compromise these components or replace trusted artifacts with malicious versions, introducing backdoors, code execution, data leakage, or manipulated model behavior.
For example, an organization might reference a public model using only its mutable name. If the original namespace becomes available, an attacker can publish a malicious model under that name, causing automated deployment pipelines to download the attacker’s artifact instead.
Mitigation:
Data and model poisoning occurs when an attacker or unsafe process modifies training data, fine-tuning data, embeddings, model artifacts, or other persistent inputs so that an AI system learns harmful behavior. Poisoning can create bias, hidden triggers, backdoors, inaccurate outputs, or other behavior that remains embedded in the system.
For example, an attacker could insert manipulated documents into an organization’s knowledge repository. When those documents are later retrieved, they can cause the system to produce incorrect recommendations and influence business decisions.
Mitigation:
Unbounded consumption occurs when an LLM application lacks adequate controls over resource use. Attackers can exploit this to exhaust compute resources, make a service unavailable, create large cloud bills, or collect enough model outputs to build a functional copy. Reasoning models, multimodal inputs, long contexts, and recursive agent workflows can increase the impact.
For example, an attacker could keep an agentic session open and continually add content. Each new inference processes an increasingly large context, causing the cost of individual turns to grow while each request remains within normal request limits.
Mitigation:
Misinformation occurs when an LLM produces incorrect, incomplete, unsupported, or misleading information that appears credible enough for a person or system to act on it. The problem becomes more serious when LLM output automatically controls tools, generates code, determines system state, or provides input to other agents.
For example, a security agent could incorrectly classify normal network traffic as an attack. If the system automatically trusts the result, it might block a production network segment and cause an outage.
Mitigation:
Hidden context exposure occurs when users can extract, infer, or reconstruct system instructions or other internal context that was not intended to be visible. Hidden context can include system prompts, developer instructions, tool schemas, RAG policies, roles, workflow rules, and other internal configuration.
For example, an attacker could extract a system prompt containing credentials for a connected tool. The attacker could then reuse those credentials outside the LLM application.
Mitigation:
Vector and embedding weaknesses affect systems that convert content into numerical representations and use similarity search to determine what an LLM receives. This includes RAG systems, vector-backed memory, semantic caches, and deduplication systems. Attackers can exploit embedding geometry to poison retrieval, infer other users’ data, reconstruct source information, or disrupt retrieval.
For example, an attacker can publish content engineered so that its embedding is very similar to a target query. When the organization’s RAG system indexes that content, a later user query can retrieve the attacker’s document instead of the intended information.
Mitigation:
Improper output handling occurs when an application passes LLM-generated content to another component without adequate validation, sanitization, or encoding. Because attackers can influence model output, downstream systems must treat that output as untrusted input. Otherwise, generated content can lead to attacks such as cross-site scripting, SQL injection, server-side request forgery, privilege escalation, or remote code execution.
For example, an application might take a command generated by an LLM and pass it directly to a system shell. Maliciously influenced output could then execute attacker-controlled commands on the server.
Mitigation:
Related content: Read our article about application control in modern enterprises
Protecting LLM applications requires multiple security controls around the model rather than relying on the model to consistently recognize and reject malicious activity. The OWASP guidance recommends defense in depth across permissions, input and output boundaries, resource consumption, human oversight, monitoring, and security testing. These controls help contain failures when a model is manipulated, produces incorrect information, or behaves unexpectedly.
This approach is particularly important when LLMs can access sensitive data or interact with external systems. Prompt injection or an incorrect model response should not automatically result in database changes, data disclosure, tool execution, or other privileged actions. Applications should therefore assume that model safeguards can fail and limit what can happen when they do.
Give LLM applications only the tools, functionality, and permissions required for their intended tasks. For example, an agent that only needs to retrieve product information should have read access to the required database tables, not permission to insert, modify, or delete records. Tools should also expose narrow functions instead of broad capabilities such as unrestricted shell execution or arbitrary URL fetching.
Permissions should remain limited throughout multi-step and multi-agent workflows. When an agent performs an operation for a user, the system should preserve that user's authorization context rather than using a generic privileged account. Authorization decisions should also be enforced by deterministic application logic or downstream systems instead of relying on the LLM to decide whether an action is allowed.
Treat all LLM-generated output as untrusted before another application component processes it. Output that reaches databases, browsers, shells, APIs, file systems, or other interpreters should be validated and handled according to the requirements of that destination. This reduces the chance that manipulated model output becomes SQL injection, command execution, cross-site scripting, or another downstream vulnerability.
Applications can also require responses to follow strict schemas and reject output that does not match the expected structure. However, structural validation is only one layer of protection because a correctly formatted response can still contain a malicious SQL statement, URL, command, or other dangerous value. Validation should therefore happen in trusted application code, with additional checks on the actual values before they are executed or passed downstream.
LLM applications should limit more than the number of requests a user can make. Controls can include input-size limits, tokens per minute or day, estimated cost per request, total queued actions, and the number of operations an agent can perform. Pre-flight token estimation can identify unusually expensive requests and reject them before inference consumes significant resources.
Hard spending limits should also be applied to API keys, users, teams, and cloud accounts. Agentic applications need additional controls because a single request can trigger many model and tool calls. Step limits, recursion-depth limits, execution timeouts, per-run cost ceilings, and circuit breakers can stop recursive or unexpectedly expensive workflows before they cause service disruption or excessive costs.
Require explicit human approval before an LLM performs privileged, irreversible, or externally visible actions. Examples include deleting files, changing important records, sending messages, publishing content, or performing other operations that could cause significant damage if the model has misunderstood a request or been manipulated by prompt injection.
Approval mechanisms should show the reviewer the exact action that will be executed rather than only an LLM-generated description of it. Controls can also reflect the potential impact of an action. Low-consequence and easily reversible operations may be automatically approved, while irreversible or high-impact actions should be escalated to a person before execution. This limits the autonomy available to a compromised or malfunctioning model.
Log and monitor model-related activity so unexpected behavior can be detected and investigated. Monitoring should cover tool calls and relevant downstream actions, particularly when an LLM can access sensitive information or modify external systems. Teams can establish normal usage patterns and look for anomalies such as repeated tool calls, unusual access patterns, unexpected state changes, or sudden increases in token consumption.
Monitoring can also support automatic containment. Systems can use thresholds and circuit breakers to stop, rate-limit, or escalate activity when an agent exceeds expected limits. At the same time, prompts, completions, retrieved chunks, reasoning traces, and tool arguments may themselves contain sensitive information, so observability systems should restrict access to logs and sanitize sensitive content before storing it.
Security testing should cover attacks that are specific to LLM applications rather than focusing only on traditional application vulnerabilities. This includes direct and indirect prompt injection, malicious retrieved content, poisoned training or RAG data, sensitive information extraction, hidden backdoors, misinformation, resource-exhaustion attacks, and attempts to manipulate connected tools.
Testing should also account for attackers adapting their techniques after learning how a defense works. OWASP notes that defenses that perform well against static attacks can become much less effective against adaptive attackers. Teams should therefore red-team models and complete LLM workflows regularly, including after changes to models, prompts, training data, retrieval sources, tools, permissions, or infrastructure. Testing should verify not only whether an attack changes model behavior, but also whether surrounding controls prevent that behavior from causing a security impact.
Airlock Digital Agentic Steering extends application control to agentic agent activity at the endpoint. It applies company-defined security policies to the commands agentic agents attempt, evaluating each one before execution so organizations can control what agents are allowed to do and steer them to operate within approved boundaries. Security and IT teams can define command rules, provide policy context or approved alternatives when actions are denied, and centrally review agent sessions, commands, policy decisions, and outcomes.
Key capabilities of Airlock Digital Agentic Steering: