The OWASP Top 10 for Large Language Model Applications started as a small project in 2023.
A handful of security professionals saw a gap — LLMs were being deployed everywhere, and nobody had mapped the attack surface.
Two years later, that project is now the OWASP GenAI Security Project, backed by over 600 contributors from 18 countries and nearly 8,000 community members. The 2025 edition of the Top 10 looks different from what came before — not because the old risks disappeared, but because deployment moved faster than anyone expected.
What is the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLMs is a community-driven awareness document that catalogues the most critical security risks specific to systems built on generative AI and large language models. Think of it as a map of where attackers are focusing, written by the people who see those attacks first.
The 2025 list covers risks across the development, deployment, and management lifecycle. It lives under the OWASP GenAI Security Project, which has grown to include cheat sheets, whitepapers, tools, an AI security solutions landscape, and an AI SBOM generator.
Here is the list:
| # | Risk | Change from 2023 |
|---|---|---|
| LLM01 | Prompt Injection | Unchanged (#1 both editions) |
| LLM02 | Sensitive Information Disclosure | Moved up from #6 |
| LLM03 | Supply Chain | Moved up from #5, scope broadened |
| LLM04 | Data and Model Poisoning | Broadened from “Training Data Poisoning” |
| LLM05 | Improper Output Handling | Moved down from #2 |
| LLM06 | Excessive Agency | New for 2025 |
| LLM07 | System Prompt Leakage | New for 2025 |
| LLM08 | Vector and Embedding Weaknesses | New for 2025 |
| LLM09 | Misinformation | New for 2025 (absorbed Overreliance) |
| LLM10 | Unbounded Consumption | New for 2025 (absorbed Model Theft, DoS) |
Five categories are brand new. The rest were reshuffled, broadened, or consolidated.
What is new in the 2025 edition
The biggest signal: the threat model shifted from “how do I protect the model” to “how do I protect the systems the model touches.”
Several 2023 risks got folded into broader categories. Insecure Plugin Design was absorbed into Excessive Agency and Supply Chain — because a plugin is not the risk; unchecked access is. Model Theft and Model Denial of Service were folded into Unbounded Consumption. Overreliance merged into Misinformation.
The five new categories reflect problems that did not exist at scale in 2023:
- Excessive Agency — LLMs are now agents. They call APIs, write to databases, send emails. When permissions exceed what is actually needed, the blast radius gets wide fast.
- System Prompt Leakage — System prompts started carrying secrets, API keys, and internal logic. Prompt injection proved they could be extracted. The fix is not better hiding; it is not putting secrets there in the first place.
- Vector and Embedding Weaknesses — RAG went mainstream. So did embedding inversion attacks, vector store poisoning, and cross-tenant data leakage in shared vector databases.
- Misinformation — LLMs generate content that sounds right but is not. Air Canada’s chatbot made up a refund policy. A lawyer filed briefs with fake ChatGPT-generated cases. These are not edge cases anymore.
- Unbounded Consumption — Denial-of-wallet attacks, recursive agent loops, functional model replication through API abuse. The economics of LLM inference made resource consumption a first-class security concern.
The ranking shifts are instructive. Sensitive Information Disclosure moved from #6 to #2 — enterprises are leaking PII and credentials through model outputs at scale. Supply Chain moved from #5 to #3 — Hugging Face model poisoning, malicious LoRA adapters, and compromised PyPi packages all happened in the wild.
LLM01: Prompt injection
Still number one. Still the hardest to fully prevent.
Prompt injection happens when user input alters the LLM’s behavior in unintended ways. Direct injection: someone tells the model “ignore all previous instructions.” Indirect injection: the model reads an external document containing hidden instructions and follows them without the user knowing. Multimodal models add a third dimension — instructions hidden in images that accompany benign text.
Neither RAG nor fine-tuning fully mitigates this. The stochastic nature of how models process input means deterministic prevention is not currently possible.
Real attacks show prompt injection can escalate to remote code execution. CVE-2024-5184 documented an LLM-powered email assistant being exploited to access sensitive information and manipulate email content through injected prompts. The EmailGPT service allowed a malicious user to inject a direct prompt and take over the service logic.
What you can do:
- Constrain model behavior through explicit system prompt boundaries
- Validate output formats with deterministic code
- Filter inputs and outputs against defined sensitive categories
- Enforce least-privilege access for any tools the model can call
- Require human approval for high-risk actions
- Run adversarial testing that treats the model as an untrusted user
For a deeper look at how prompt injection works and how to test for it, see our guide to prompt injection attacks.
LLM02: Sensitive information disclosure
This jumped to #2 for a reason. LLMs memorize training data. They regurgitate PII, financial details, health records, business secrets, and API keys. And they do not know they should not.
The Samsung chat leak in 2023 was the warning shot. An engineer pasted proprietary source code into ChatGPT. Samsung subsequently banned the use of generative AI tools among employees. WIRED documented how researchers from Google DeepMind and multiple universities found ChatGPT could be prompted to repeat the word “poem” endlessly — it would eventually trail off into verbatim training data, including names, email addresses, and phone numbers. The Proof Pudding vulnerability (CVE-2019-20634) showed how disclosed training data enables model inversion attacks that bypass security controls.
Proprietary models carry additional risk. Their training methods, architectures, and source code are sensitive. If those leak, attackers gain a blueprint for exploitation.
What you can do:
- Sanitize data before it enters training pipelines
- Apply strict input validation
- Enforce access controls on a least-privilege basis
- Use federated learning to avoid centralized data collection
- Apply differential privacy techniques
- Tokenize and redact sensitive content before processing
- Educate users: the chat box is not a safe place for secrets
For more on protecting data in AI systems, see our coverage on AI data security and AI privacy risks.
LLM03: Supply chain
LLM supply chains are more complex than traditional software supply chains. You are not just managing dependencies. You are managing datasets, pre-trained model weights, fine-tuning adapters, embedding models, and inference infrastructure. Every one of those is a potential attack vector.
The 2025 list calls out attack patterns demonstrated in the wild:
- Malicious LoRA adapters: A popular fine-tuning method on Hugging Face. A compromised adapter injects backdoors into an otherwise trusted base model.
- Model provenance attacks: After WizardLM was removed from Hugging Face, someone published a fake version with the same name containing malware and backdoors.
- PyPi package compromise: The first OpenAI data breach involved a compromised PyTorch dependency. The Shadow Ray attack exploited five vulnerabilities in the Ray AI framework, compromising thousands of servers, as reported by CSO Online.
- Collaborative development exploitation: Model merging services and format conversion bots on Hugging Face have been exploited to inject malicious code.
What you can do:
- Vet every data source and supplier; review terms and privacy policies regularly
- Maintain an SBOM for AI components — OWASP CycloneDX is the emerging standard
- Use model signing and file hashes to verify provenance
- Run comprehensive AI red teaming before adopting any third-party model
- Implement anomaly detection on supplied models and data
- Encrypt models deployed at the edge with integrity checks
See our piece on AI runtime security for more on protecting deployed models.
LLM04: Data and model poisoning
Data poisoning manipulates training data, fine-tuning data, or embeddings to introduce backdoors, biases, or degraded performance. The 2025 edition broadened this from “Training Data Poisoning” to “Data and Model Poisoning” because the attack surface extends beyond pre-training.
Poisoning can be targeted. An attacker inserts triggers that leave model behavior unchanged until a specific input activates the backdoor. Anthropic’s January 2024 paper on “Sleeper Agents” demonstrated that LLMs can be trained to behave deceptively and that this behavior persists through standard safety training, including supervised fine-tuning and reinforcement learning. JFrog documented malicious Hugging Face models with silent backdoors targeting data scientists.
Poisoning also happens through RAG pipelines. If an attacker can insert documents into the knowledge base a model retrieves from, they control the context the model uses to generate answers.
What you can do:
- Track data origins and transformations with OWASP CycloneDX or ML-BOM
- Vet data vendors rigorously
- Sandbox the model from unverified data sources
- Use data version control to detect manipulation
- Monitor training loss for anomalies
- Run red team campaigns targeting poisoning scenarios
- Use RAG and grounding techniques during inference to reduce hallucination risk
This connects directly to AI drift — models that degrade or change behavior over time — and the detection mechanisms needed to catch it.
LLM05: Improper output handling
LLM output is untrusted input. Period.
If your application takes what the model generates and passes it directly to a SQL query, a shell command, an HTML renderer, or an email template, you have created a remote code execution path.
The vulnerability is conceptually simple: LLM output can contain anything. JavaScript. SQL injection payloads. Shell commands. Malicious markdown. If you do not validate and sanitize it before it reaches downstream systems, you are giving users indirect access to whatever those systems can do.
Improper Output Handling differs from Overreliance (absorbed into Misinformation). Output Handling is about the technical pipeline — what happens after generation. Overreliance was about trusting the content.
What you can do:
- Treat the model as an untrusted user
- Apply zero-trust input validation on all responses before they reach backend functions
- Use context-aware output encoding: HTML encoding for web content, SQL escaping for database queries, shell escaping for command execution
- Use parameterized queries
- Implement Content Security Policy headers
- Log and monitor for unusual output patterns
LLM06: Excessive agency
This is the risk that changes fastest as agentic AI adoption grows.
An LLM-based system is granted the ability to call functions, access APIs, or interface with other systems. When those permissions exceed what is actually needed, or when the model can chain actions without oversight, the result is Excessive Agency.
The root causes fall into three buckets:
| Cause | Example |
|---|---|
| Excessive functionality | An extension for reading documents also includes modify and delete capabilities |
| Excessive permissions | A database connection uses a full admin account instead of read-only |
| Excessive autonomy | No human checkpoint before high-impact actions like deleting records |
A real attack vector: Slack AI was shown to exfiltrate data from private channels through prompt injection. The AI assistant read messages it was not supposed to and forwarded them because it had permissions it did not need.
What you can do:
- Minimize extensions to only what is necessary
- Limit extension permissions to the minimum
- Avoid open-ended extensions like “run shell command”
- Execute extensions in the user’s security context, not with a privileged service account
- Require human approval for high-impact actions
- Implement authorization in downstream systems rather than delegating access decisions to the LLM
- Rate-limit agent actions and log everything
For more on agentic AI security, see our deep dive on securing agentic AI systems.
LLM07: System prompt leakage
The system prompt tells the model how to behave. In 2023, a common pattern was to put everything in it: role definitions, safety rules, internal logic, and sometimes — catastrophically — API keys and database credentials.
The 2025 list makes a sharp point: the system prompt should not be treated as a secret, and it should never be used as a security control. It will leak. Attackers extract it through prompt injection, meta-questions, or repeated probing. If your security depends on them not knowing what the system prompt says, your security was already broken.
The real risk is not that someone reads your system prompt. The real risk is that your system prompt contains credentials, connection strings, internal role structures, or filtering logic that becomes a blueprint for bypass.
What you can do:
- Separate sensitive data from system prompts entirely
- Do not use system prompts to enforce security controls — enforce those in external, deterministic systems
- Implement output guardrails that inspect responses independently of the model
- Ensure privilege separation and authorization happen outside the LLM
LLM08: Vector and embedding weaknesses
RAG systems depend on vector embeddings to retrieve relevant context. Those embeddings can be attacked.
Embedding inversion attacks can reconstruct significant portions of source documents from stored embeddings. A 2023 paper from researchers at multiple institutions demonstrated that generative inversion can recover entire sentences from their embeddings. If your vector store contains sensitive documents, the embeddings themselves are a data exposure risk.
Vector poisoning is the RAG equivalent of data poisoning. An attacker inserts documents whose embeddings are engineered to dominate retrieval results for specific queries. When the model retrieves those documents, it acts on corrupted context. One demonstrated attack used white-text-on-white-background instructions in resumes to manipulate an LLM-powered job screening system.
Cross-context leakage happens in multi-tenant vector databases where different user groups share the same store. Without proper access partitioning, embeddings from one tenant surface in another tenant’s queries.
What you can do:
- Implement fine-grained access controls and permission-aware vector stores
- Validate and sanitize all data before it is embedded
- Combine semantic similarity with rule-based filtering
- Encrypt embeddings at rest
- Audit retrieval logs
- Monitor for documents that appear disproportionately often across unrelated queries
For teams building RAG pipelines, our multimodal RAG implementation guide covers practical security considerations.
LLM09: Misinformation
LLMs hallucinate. They generate content that is factually wrong but sounds authoritative. In a chat interface, this is annoying. In a system that generates SQL queries, legal documents, medical advice, or financial recommendations, it is dangerous.
The Air Canada chatbot case is a canonical example. The chatbot told a customer they could get a bereavement discount after booking. They could not. The British Columbia Civil Resolution Tribunal rejected the airline’s argument that the chatbot was a “separate legal entity” and ordered Air Canada to pay $812.02 in damages.
ChatGPT fabricated legal cases that lawyers then cited in court filings. Coding assistants hallucinate package names, and attackers have published malware under those hallucinated names to catch developers who trust the suggestions.
What you can do:
- Ground responses in retrieved, verified sources through RAG
- Implement fact-checking workflows with human oversight for high-stakes outputs
- Use automatic validation mechanisms
- Communicate risks clearly to users
- Train users on LLM limitations
- Require verification of suggested libraries and packages before integration
LLM10: Unbounded consumption
Inference costs money — per token, per request. Without limits, an attacker can run up bills, exhaust resources, or extract enough model behavior to create a functional clone.
Attack patterns include:
- Variable-length input floods that exploit processing inefficiencies
- Denial-of-wallet attacks that exploit pay-per-use pricing models
- Functional model replication through synthetic training data — Stanford’s Alpaca was fine-tuned on 52K outputs from another model, creating a capable equivalent for under $600
- Side-channel attacks that harvest model weights and architectural information
- Recursive agent loops that consume tokens without bound
The LeftoverLocals vulnerability (CVE-2023-4969) showed that leaked GPU local memory could recover sensitive data from LLM inference, including full model responses reconstructed from ~181 MB of leaked memory per query.
What you can do:
- Implement rate limiting and user quotas
- Set hard token limits and response caps
- Monitor for unusual consumption patterns
- Apply timeouts and throttling
- Sandbox the model from unnecessary network resources
- Implement watermarking to detect unauthorized use
- Require human confirmation for high-cost operations
For practical guidance on controlling LLM costs, see our guide to stopping token waste and our LLM token pricing breakdown.
How compliance frameworks map to the Top 10
The OWASP Top 10 does not exist in isolation. Several regulatory frameworks align with specific entries:
| OWASP Risk | Regulatory Frameworks |
|---|---|
| LLM02: Sensitive Information Disclosure | GDPR, HIPAA, CCPA |
| LLM09: Misinformation, LLM06: Excessive Agency | EU AI Act risk classification |
| LLM04: Data Poisoning, LLM03: Supply Chain | NIST AI Risk Management Framework |
| LLM10: Unbounded Consumption | OWASP API4:2023, MITRE CWE-400 |
For organizations in regulated industries, mapping the Top 10 to compliance obligations is not optional — it is how you demonstrate reasonable security practices during an audit. Our guide to AI governance frameworks covers the regulatory landscape in detail.
How Do Enterprises Use the OWASP LLM Top 10 to Evaluate Third-Party AI Components Before Adoption?
Most enterprises don’t build their LLM stack from scratch. They buy it — a vendor chatbot, a RAG platform, a model API, an agent framework, a plugin. The OWASP Top 10 gives procurement and security teams a shared checklist for that decision, turning “is this vendor safe?” into ten specific questions you can actually put in a questionnaire.
What you can do:
- Turn the list into vendor due diligence. Ask how the vendor handles each risk, not whether they’ve heard of it. Answers like “we filter prompts” tell you less than a description of where filtering happens and what it misses. Our comparison of AI security solutions covers what a serious answer looks like.
- Anchor on Supply Chain. Ask for a model and dataset provenance trail — base model, fine-tuning data, third-party adapters, and the open-source packages underneath. An AI bill of materials is a fair thing to request.
- Probe the risks you inherit but can’t see. Sensitive Information Disclosure, Data and Model Poisoning, and Hidden Context Exposure all live inside the vendor’s boundary. Ask about tenant isolation, whether your prompts train their models, and retention windows.
- Map the shared responsibility line. For each of the ten, write down who owns the control: you, the vendor, or nobody. The “nobody” rows are your findings, and they belong in your AI governance program rather than in a one-off spreadsheet.
- Weight by what you’re granting. A component with tool access, write permissions, or autonomy raises Excessive Agency and Improper Output Handling well above the rest. Scope the review to the permissions you plan to give it.
- Ask for evidence, not attestations. Red team reports, third-party pentest summaries, and results from adversarial testing against these categories carry more weight than a filled-out form.
- Reassess on model updates. Vendors swap base models and change system prompts without telling you. Build a trigger for re-review into the contract.
Used this way, the Top 10 is an effective way to make the risk you’re accepting explicit and to write it into the contract before it becomes an incident.
Where to start
If your team is looking at this list for the first time, here is a practical order of operations:
- Audit what you have connected. Every API key, every tool, every permission you have given to an LLM. You will find things you forgot about.
- Fix prompt injection first. It is #1 because it enables everything else. If someone can control what your model does, every other control is downstream of that.
- Separate secrets from prompts. This is a one-time cleanup that closes an entire category of exposure.
- Implement output validation. Treat model output the way you would treat user-submitted form data. Because in a prompt injection scenario, that is exactly what it is.
- Set resource limits. Token caps, rate limits, spend alerts. You cannot budget for what you do not measure.
- Run a red team exercise. Simulate injection, extraction, and poisoning against your own systems. Most teams find at least one exploitable path in the first round.
The OWASP Top 10 for LLM Applications is not a finish line. It is a starting point. The attack surface is still being mapped. New categories will emerge. But using this framework to structure your security program gives you common language, a shared threat model, and a clear prioritization path. In a space where things shift monthly, that baseline is worth a lot.
For a broader view of the AI security threat landscape, see our overview of AI security risks and our AI security best practices guide.
The agentic extension of this list, ASI01 through ASI10, maps to 12 verifiable AI agent security controls.