Prompt injection and supply chain vulnerabilities remain the main LLM vulnerabilities as concerns grow about agentic tools security risks.
Enterprise adoption of generative AI technologies has exploded due to the rapid evolution of the technology and the emergence of a variety of business use cases.
But large language models (LLMs) can accidentally produce harmful results, leak information, or become exposed to threat actors. These vulnerabilities are changing as the technology evolves and as attackers find new ways to compromise systems. For enterprises, this means the risk of bad publicity, compliance or cybersecurity exposure, legal liability, or even class-action lawsuits.
To keep up with the latest in LLM risks, the Open Worldwide Application Security Project (OWASP) has updated its list of the top 10 most critical vulnerabilities of LLM applications. For the first time, the list is influenced by real-world incident data alongside expert voting on classes of AI security risk.
Prompt injection and sensitive information disclosure remain the two most severe threats, with excessive agency (agentic actions outside permitted bounds) rising to OWASP’s No. 3 spot, a change reflecting the evolution from chatbots to agentic systems that call APIs and run code.
Issues such as unbounded consumption of AI resources have grown in prominence while risks from improper output handling have dropped to the bottom of the list thanks to more widespread use of output sanitization.
The changes reflect how fast the generative AI sector is evolving — and the list is likely to change again soon as new technologies hit the market.
The list brings together the judgment of the security practitioners who attack and defend these systems along with the record of what has actually gone wrong in the field, each cross-referenced against each other, according to OWASP. The list intends not only to educate developers and organizations about potential security risks but also to suggest remediation strategies for improving the security posture of LLM applications.
Organizations should work on all 10 categories, starting at the top.
1. Prompt injection
Prompt injection has topped OWASP’s list since it was first released in early 2023. The attack technique involves maliciously crafted inputs meant to manipulate an LLM to unknowingly execute an attacker’s intentions. This can include direct “jailbreaking” or the manipulation of external inputs such as files or websites, potentially resulting in data exfiltration, social engineering, or other issues.
For example, a user can write a prompt to trick a company chatbot into revealing proprietary information the user doesn’t have access to or upload a text, image, or audio file with hidden instructions to cause the application to misbehave. Prompt injection also includes cross-modal attacks aimed at manipulating tool output, intermediate reasoning, or persistent memory to nefarious ends.
To reduce the risk of prompt injection, OWASP recommends the following:
- Constrain the model’s role and capabilities in the system prompt.
- Add a human in the loop for the most sensitive operations, requiring an extra approval step to check for unauthorized actions.
- Define a strict output schema, validating every response with trusted application code.
- Scan inputs and outputs (text, image, audio, and structured data) for harmful content and block sensitive or unauthorized content before it reaches the model or is returned to users.
- Hold credentials and state-change capability in application code, not the model, and grant least privilege per operation.
2. Sensitive information disclosure
Also referred to as “data leakage,” sensitive information disclosure involves an LLM revealing protected data, proprietary algorithms, or other confidential details on output, which can result in unauthorized access, privacy violations, and other security breaches.
Sensitive data can get into an LLM through multiple routes, including initial training, during fine-tuning or embedding, or when entered by a user’s prompt. Once the model has access to this information, there’s the potential for other, unauthorized users to see it.
Preventative measures include:
- Use data sanitization and scrubbing to prevent LLMs from getting access to sensitive data during training or inference.
- Apply filters to user inputs to prevent sensitive data from being uploaded or to identify and remove or mask confidential information.
- Use strict access controls and the principle of least privilege when LLMs need to access data sources during inference.
3. Excessive agency
This vulnerability has moved up from sixth place as agentic systems have become more commonplace in the enterprise.
Excessive agency involves an LLM with too much power to perform actions and typically stems from excessive functionality, excessive permissions, and insufficient oversight. Damaging actions could be performed when an LLM hallucinates, when it falls victim to a prompt injection, a malicious plugin, poorly written prompts, or just because it’s a badly performing model, OWASP says.
Excessive agency’s jump on OWASP’s list — due to both expert votes and incident data — is evidence that the industry’s concern with agentic risk is justified, according to Crystal Morin, a senior cybersecurity strategist at AI cloud security vendor Sysdig.
“LLMs have evolved from generating text to executing actions with real permissions, tool access, and an impactful blast radius,” says Morin. “OWASP’s updated Top 10 list is built on real-world evidence organizations can use to prioritize better application security today.”
Daniel Bechenea, security manager at Pentest-Tools.com, says that enough organizations now run agents with production credentials that it shows up in the incident record.
“The two examples that back this up are the April 2026 situation in which a Cursor coding agent working a staging task at PocketOS hit a credential mismatch, reached outside the scope of that task to find a root-level API token in an unrelated file, and used it to delete a Railway [MCP] volume,” Bechenea explains. “That happened because Railway stored volume-level backups inside the same volume, the backups went with the data, and the most recent recoverable copy was three months old.”
In another high-profile case, a Replit agent deleted SaaStr’s production database during a declared code freeze before falsely claiming recovery was impossible.
“Neither case involved an attacker,” says Bechenea. “Both involved credentials scoped wider than the task and no enforced gate on a destructive, irreversible action. In both, written guardrails existed and didn’t hold. These situations are a strong reminder that a rule in a prompt is not a control.”
Organizations should test what the agent can reach through connected tools, and whether anything intervenes when it gets there to stay ahead of the risk, Bechenea advises.
Preventative measures for this vulnerability include:
- Limit the plugins and tools the LLM can call, and the functions implemented in those plugins and tools, to the minimum.
- Avoid open-ended functions such as running a shell command or fetching a URL, using more granular functionality instead.
- Limit the permissions that LLMs, plugins, and tools are granted to systems to the minimum.
- Track user authorization and security scope to ensure actions taken on behalf of a user are executed on downstream systems in the context of that specific user, and with the minimum privileges necessary.
4. Supply chain vulnerabilities
Supply chain vulnerabilities, previously in third place, involve third-party components, poisoned or outdated pre-trained models, or corrupted training data sets. The category now includes Model Context Protocol (MCP) servers and model artefacts as an emphasis.
The rise of open-access LLMs and new fine-tuning techniques has introduced additional supply chain risks, particularly when models are sourced from public repositories or collaborative platforms. This vulnerability also covers cases where the creator of the original model did not properly vet the training data, leading to privacy, software licensing, or copyright violations. According to OWASP, this can lead to biased outcomes, security breaches, or system failures.
Preventative measures include:
- Vet data sources and suppliers carefully.
- Use only reputable plug-ins and ensure they’ve been tested for your requirements, and use model and code signing when using external models and suppliers.
- Scan environments for unauthorized plugins and out-of-date components, including the model and its artefacts and have a patching policy to remediate issues.
- Use comprehensive AI red teaming and evaluation processes when selecting third-party models to identify potential vulnerabilities, biases, or malicious features before deployment.
5. Data and model poisoning
Data and model poisoning refers to manipulation of pretraining data or data involved with the fine-tuning or embedding processes to introduce vulnerabilities, backdoors, or biases that could compromise the model, according to OWASP.
For example, a malicious attacker or insider who gains access to a training data set can change the data to make the model give incorrect instructions or recommendations to damage the company or benefit the attacker.
Preventative measures include:
- Verify your training data’s supply chain, especially when sourced externally.
- Craft different models via separate training data or fine-tuning for different use-cases to create a more granular and accurate generative AI output.
- Ensure sufficient sandboxing to prevent the model from scraping unintended data sources.
- Use strict vetting or input filters for specific training data or categories of data sources to control volume of falsified data.
6. Unbounded consumption
Previously called a model denial of service, unbounded consumption involves an attacker causing an LLM to use an exceptionally high number of resources, resulting in a decline in the quality of service for other users, as well as potentially high resource costs.
This issue is becoming more critical due to LLMs’ intensive resource utilization, the unpredictability of user input, and a general lack of awareness among developers regarding this vulnerability, OWASP says. For example, an attacker could use automation to flood a company’s chatbot with complicated queries, each of which takes time — and costs money (aka “denial of wallet”) — to answer.
Unbounded consumption also includes model theft, where an attacker is able to ask so many questions that they can effectively reverse engineer the original model or use it to generate synthetic data to build new models.
Preventative measures include:
- Implement input validation and sanitization to ensure user input adheres to defined limits and filters out malicious content.
- Cap resource use per request or step, so that requests involving complex parts execute slowly; enforce API rate limits per individual user or IP address; or limit the number of queued actions or total actions in a system reacting to LLM responses.
- Continuously monitor resource utilization to identify abnormal spikes or patterns.
- Design systems for graceful degradation under heavy load, maintaining partial functionality rather than complete failure.
7. Misinformation
LLMs are prone to occasionally generating content that is factually incorrect, inappropriate, or unsafe.
Such “hallucinations” can be dangerous, for example, if the LLM is used by a company’s security analysts, says Rik Turner, a senior principal analyst for cybersecurity at Omdia: “If it comes back talking rubbish and the analyst can easily identify it as such, he or she can slap it down and help train the algorithm further. But what if the hallucination is highly plausible and looks like the real thing?”
Hallucinations are an even bigger risk when companies deploy LLMs directly to the public, such as with customer service chatbots. When the information provided is dangerous, illegal, or inaccurate, it can cost a company money, reputation loss, or legal risk.
The impact of misinformation is amplified by overreliance, where users place excessive trust in LLM-generated content without adequate verification.
Key preventative measures include:
- Require outputs to be grounded in authoritative sources and verify claims before acting.
- Introduce approval workflows and system checks.
- Log claims, evidence, and outcomes, and test adversarial scenarios. Regularly test workflows against misleading scenarios.
- Apply least privilege, sandboxing, and rate limits to limit the potential impact of any incident.
8. Hidden context exposure
Hidden prompt exposure expands the previous category of system prompt leakage to include hidden-context scope problems.
System prompts are starting instructions given to LLMs to guide their conversations, and can contain sensitive instructions, operational parameters, security controls, business logic, and private corporate information. Enterprises may incorrectly assume these system prompts are kept confidential, but they could be exposed.
According to OWASP, the problem isn’t that attackers can get their hands on this system prompt — the problem is that companies are putting sensitive information into this prompt to begin with, including API keys and authentication details.
Developers should operate under the assumption that hidden context is potentially discoverable.
Key preventative measures include:
- Store sensitive information such as API keys, authentication details, and database information separate from system prompts, in systems the model cannot directly access.
- Avoid relying on system prompts for model behavior control; instead implement these controls, such as detecting harmful content, in external systems.
- Deploy guardrails outside the LLM to inspect model outputs to ensure the model acts as expectated.
- Implement critical security controls such as privilege separation and authorization checks independently from the LLM in a deterministic, auditable manner.
- If a workflow involves multiple tasks requiring different levels of access, use multiple agents instead, each configured with the least privileges necessary.
9. Vector and embedding weaknesses
Companies often augment LLMs with vector databases and retrieval-augmented generation (RAG) systems, pulling relevant, up-to-date information from corporate data stores before prompts are sent off to the LLMs.
In such context, attackers may be able to trick the system into retrieving information they should not have access to, or go after these data sources directly, poisoning the model and making it give incorrect information.
According to OWASP, vector and embedding weaknesses are failures in the retrieval substrate of RAG-style systems rather than in the LLM or prompt itself. Embeddings and vector stores offer a distinct attack surface, OWASP says, because they often lack the same access controls and auditability as traditional data stores.
For example, multi-tenant or poorly filtered vector stores can return documents across tenants or beyond a user’s authorization, potentially leaking data to attackers.
Key preventative measures include:
- Implement fine-grained access controls and permission-aware vector and embedding stores with strict partitioning of datasets to prevent users from leveraging the LLM to get access to information they shouldn’t.
- Create strong data validation pipelines that only accept and process information from trusted, verified sources. For user-submitted content, such as resumes, use text extraction tools that detect and flag hidden text.
- Thoroughly review and classify combined datasets to prevent data mismatch errors and control access levels.
10. Improper output handling
Improper output handling refers to insufficient validation, sanitization, and handling of the outputs generated by LLMs before they are passed downstream to other components and systems. Because LLM-generated content can be controlled by prompt input, this behavior is similar to providing users indirect access to additional functionality.
For example, if the LLM’s output is sent directly into a system shell or similar function, it can result in remote code execution.
The category has been expanded to include insecure code that assistants generate at scale.
Preventative measures include:
- Treat the model as any other user, adopting a zero-trust approach, and apply proper input validation on responses coming from the model to backend functions.
- Follow the OWASP ASVS (Application Security Verification Standard) guidelines to ensure effective input validation and sanitization and encode the output to mitigate undesired code execution.