The Vilkas Wire
The OWASP Top 10 for LLM Applications (2025): What Security Teams Need to Know
Sep 2, 2025 · By Ben Rollin
Large Language Models (LLMs) are no longer just experiments in research labs. They sit in customer service portals, assist developers with coding, analyze business documents, and even connect to live systems through plugins and agents. These capabilities create tremendous opportunity, but they also introduce new and often misunderstood security risks.
Attackers have been and are constantly finding new ways to exploit poorly secured LLMs. We’ve seen cases where hidden instructions inside user input bypass controls, where sensitive data is leaked through casual queries, and where unbounded requests drain cloud budgets overnight.
The first OWASP Top 10 for Large Language Model Applications was released in 2023. As LLMs are becoming more embedded across enterprises, OWASP released an update: Top 10 for LLM Applications for 2025. This project is the result of broad community collaboration, involving security researchers, industry practitioners, and engineers who have seen first-hand how LLM applications fail. Just like the classic OWASP Top 10 for web applications, this list is meant to provide a practical baseline for understanding the most important risks.
📄 Download the full OWASP Top 10 for LLM Applications 2025 PDF here
Top 10 LLM Risks – Quick Reference
Before diving into details, here is a high-level summary of the top risks.
| Rank | Category | Plain-Language Summary |
|---|---|---|
| 1 | Prompt Injection | Attackers hide or craft instructions that cause the model to ignore safeguards or perform unintended actions. |
| 2 | Sensitive Information Disclosure | The model exposes private data such as training content, user prompts, credentials, or internal documents. |
| 3 | Supply Chain Vulnerabilities | Third-party models, adapters, datasets, or tooling are compromised and introduce risk into your stack. |
| 4 | Data and Model Poisoning | Malicious or low-quality data corrupts training or fine-tuning and changes model behavior in harmful ways. |
| 5 | Improper Output Handling | Treating LLM output as trusted input leads to injection flaws, code execution, or unsafe rendering. |
| 6 | Excessive Agency | Agents with broad permissions take damaging actions without human oversight or least-privilege controls. |
| 7 | System Prompt Leakage | Hidden instructions that steer the model are exposed, enabling tailored bypasses. |
| 8 | Vector and Embedding Weaknesses | Retrieval and embedding pipelines can be manipulated to insert or surface untrusted or malicious content. |
| 9 | Misinformation | The model confidently produces false or misleading content that users act upon. |
| 10 | Unbounded Consumption | Abuse of resource-intensive operations drives up cost or degrades availability. |
From Quick Reference to Deep Dive
Now that you have the overview, the sections below expand each risk with concrete scenarios and practical mitigations.
1. Prompt Injection
The risk: Attackers craft inputs (or plant content in external sources) that redirect the model’s behavior, bypass guardrails, or trigger actions the system did not intend. This includes jailbreaks, indirect prompt injection through web pages or documents, and prompt blending that confuses instruction boundaries.
Example scenario: A helpdesk bot that can browse links is sent a URL with hidden HTML comments instructing it to reveal conversation history and exfiltrate environment variables via a webhook. The bot follows the injected instructions because it treats retrieved content as trusted.
Mitigation: Treat all retrieved or user-supplied content as untrusted. Segment system, developer, and user instructions. Use input and retrieval allow/deny-lists, escape and neutralize control tokens where feasible, constrain tool use with strict schemas and least privilege, and require human approval for sensitive actions. Perform regular red teaming and adversarial testing.
2. Sensitive Information Disclosure
The risk: LLM applications leak secrets or private data through training exposure, prompt logs, conversation memory, or unfiltered outputs. Data may include PII, credentials, internal code, or customer documents.
Example scenario: A user asks for a “working example” and the assistant returns a snippet that includes a hard-coded API key copied from prior tickets. In another case, an attacker uses prompt-inversion techniques to extract names and emails from the model’s training corpus.
Mitigation: Apply data minimization and strong access controls on logs, prompts, and memories. Mask or tokenize sensitive fields, scrub inputs and outputs, disable verbatim training retention where possible, and use privacy-preserving techniques for training and analytics. Limit who can view raw prompts and chat histories. Educate users on the dangers of inputting sensitive data. Allow users to opt out of having their data used for training the model.
3. Supply Chain Vulnerabilities
The risk: The LLM stack depends on external models, adapters, datasets, vector DBs, and orchestration libraries. If any upstream component is malicious or compromised, your application inherits that risk.
Example scenario: A third-party software library dependency is compromised with malware. Developers download this compromised dependency and a remote attacker is able to leverage this compromise library to compromise the LLM app.
Mitigation: Maintain a software bill of materials for models and data. Pin and verify artifacts with hashes and signatures. Use private registries and approval workflows. Vet training data provenance. Scan containers and libraries. Continuously monitor for updated advisories and rotate compromised components quickly.
4. Data and Model Poisoning
The risk: Poisoned or low-quality data inserted during pretraining, fine-tuning, or RAG indexing shifts model behavior. The result ranges from subtle misclassification to targeted instructions that activate only under certain prompts.
Example scenario: An attacker submits many “user guides” to a public docs portal that your RAG pipeline ingests. The injected pages instruct the assistant to always recommend a rogue extension when the prompt includes certain brand names.
Mitigation: Track data origins, vet data vendors, and validate model outputs against trusted sources. Use strict sandboxing to limit model exposure to untrusted data sources. Employ infrastructure controls to prevent the model from accessing unintended data sources. Employ data version control (DVC).
5. Improper Output Handling
The risk: Treating model output as safe leads to classic injection and execution bugs. Generated code, SQL, HTML, or shell snippets that are executed or rendered without validation create direct exploit paths.
Example scenario: An internal tool takes model-generated Python and executes it with eval() to automate tasks. A crafted prompt causes the model to produce a payload that downloads and runs arbitrary code. Another team renders model HTML directly into a page, enabling stored XSS.
Mitigation: Apply the same secure coding practices used for untrusted input: encode and sanitize outputs, validate against strict schemas, and avoid dynamic execution. Sandbox any code execution and enforce allow-lists for commands or APIs. Add output filters and security reviews before deployment.
6. Excessive Agency
The risk: Agents or assistants with broad tool access can perform destructive actions when prompts are misleading, injected, or simply wrong. Lack of strong guardrails and human-in-the-loop controls amplifies impact.
Example scenario: A finance bot with email and ticketing access receives an injected instruction to refund multiple invoices. It files change requests and emails vendors without any manual approval.
Mitigation: Follow least privilege for tools and data. Bind agent actions to explicit, typed plans and require approvals for sensitive steps. Add rate limits, budgets, and scopes per action. Log all tool calls and provide easy rollbacks. Prefer read-only defaults and elevate only as needed.
7. System Prompt Leakage
The risk: If hidden system instructions are exposed, attackers can tailor prompts to bypass rules or craft more effective jailbreaks. Leakage can occur through direct questioning, debugging endpoints, or verbose error messages.
Example scenario: A developer mode endpoint returns the entire system prompt for troubleshooting. Attackers copy it and design targeted obfuscations that defeat safety rules.
Mitigation: Avoid storing any sensitive information directly in system prompts. Avoid allowing system prompts to control the model. Implement a guardrail system to inspect output. Ensure that security controls such as privilege separation, authorization bound checks, and others are not delegated to the LLM.
8. Vector and Embedding Weaknesses
The risk: Some AI systems use “memory” tools that turn documents or text into numbers (called embeddings) so the model can quickly look things up later. If attackers sneak bad or manipulated data into that memory, or if the system doesn’t control who can add or read from it, the model may pull in harmful or misleading information.
Example scenario: An attacker uploads a document whose embedding is engineered to rank first for common queries. The RAG system consistently retrieves this item and the assistant follows its injected guidance.
Mitigation: Enforce per-tenant namespaces and access controls in vector stores. Validate and sanitize documents before indexing. Use hybrid retrieval with filters and metadata checks. Monitor retrieval quality, add content integrity checks, and periodically re-embed with updated models. Employ proper, immutable, logging of retrieval activities.
9. Misinformation
The risk: Models may hallucinate facts or present outdated or biased information. If users or downstream systems act on false outputs, the damage can be significant.
Example scenario: A compliance assistant produces a summary of a regulation with fabricated clauses. A team updates controls based on the false summary and fails an audit.
Mitigation: Calibrate user expectations and UX. Use retrieval to ground answers in verifiable sources and show citations. Implement verification workflows for high-impact tasks. Track model performance with evaluations and feedback loops. Clearly communicate the risk and possible harms associated with LLM-generate content to users. Train users on the limitations of LLMs.
10. Unbounded Consumption
The risk: LLM operations are costly and resource-heavy. Attackers or faulty agents can trigger excessive token usage, long tool chains, or large file processing that drives up cost or causes outages.
Example scenario: A public endpoint accepts unbounded file uploads for summarization. Attackers submit multi-hundred-megabyte PDFs that trigger long, expensive runs that take considerable resources and make the service unavailable to legitimate users.
Mitigation: Enforce quotas, per-user budgets, and rate limits. Bound input sizes and step counts. Add circuit breakers and timeouts. Monitor spend and latency with alerts. Provide graceful degradation paths when limits are reached.
Why This Matters
LLM applications are not just toys or research projects. They are already integrated into enterprise workflows and exposed to customers. That means they are also in scope for attackers. Over the years, company's overall attack surface has decreased, or shifted largely to web applications and no longer considerable exposed services that nowadays are typically only accessible from the internal network. However, with the introduction of LLM applications, many companies are opening up a massive new attack surface that they may not be fully aware of. This introduces considerable risk of sensitive data exposure, unauthorized access, and full-scale breaches.
The OWASP Top 10 for LLM Applications provides a practical baseline to understand these risks. None of these issues are purely theoretical. Each has already been demonstrated in the wild, and each can cause real damage if left unaddressed. The Zscaler data breach that occurred in late August of 2025 is a perfect example. Malicious actors compromised an AI chat agent that integrates with Salesforce and stole authentication information that allowed for unauthorized access to Salesforce environments.
Final Thoughts
LLMs deliver enormous value, but they also create entirely new attack surfaces. The organizations that succeed with AI will be those that take security seriously from day one.
At Vilkas Cybersecurity, we test and harden AI deployments with the same rigor we apply to penetration testing and red team engagements. If your business is deploying chatbots, copilots, or other LLM-based tools, we can help identify the risks before attackers do.
Have a question about this article or a security challenge of your own?
Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones. Fill out the form and we’ll get back to you shortly.