OWASP Top 10 for LLM Applications: What You Need to Know

Your engineering, security, and product teams ship an LLM feature fastest when all three describe its risks in the same terms. The OWASP Top 10 for LLM Applications gives them that shared reference, and its 2025 edition extends the list from a design-time checklist into something you can monitor once an AI feature reaches production.

This guide covers all ten risks in the 2025 OWASP list, how each shows up in your running application, and what to mitigate at design time versus track at runtime. Two entries are new this round: System Prompt Leakage and Vector and Embedding Weaknesses.

What Is the OWASP Top 10 for LLM Applications?

OWASP is the Open Worldwide Application Security Project, a nonprofit foundation that has published open application security standards since 2001, including the original web application Top 10. Its GenAI Security Project maintains the OWASP Top 10 for LLM Applications, a community-built catalog of the most critical security risks in applications that use large language models.

The project launched in May 2023 to document critical LLM risks, delivered its first release in August 2023, and has grown into a broad international contributor community. That growth gives teams a broader risk model for LLM applications, which now combines prompts, tools, data retrieval, model providers, and downstream actions in ways older application security lists did not cover.

The list became the shared AI vocabulary because a platform engineer in one company and a regulator in another can point to “LLM01” and mean the same thing. The current edition is the canonical 2025 list, with the full breakdown in the official 2025 PDF. Teams use it for threat modeling and control mapping, then carry it into runtime monitoring, because these production LLM risks often show up only once the application is live.

What Changed in the 2025 Update

The 2025 edition, also called v2.0, arrived as a direct response to production AI systems shifting toward agentic, tool-calling, retrieval-augmented generation (RAG) applications. OWASP folded older entries into broader categories and reordered several risks to reflect incident data, and it added two entirely new entries: System Prompt Leakage and Vector and Embedding Weaknesses.

2023/24 Entry	2025 Entry	Change
LLM01 Prompt Injection	LLM01 Prompt Injection	Retained at #1
LLM02 Insecure Output Handling	LLM05 Improper Output Handling	Renamed, moved down
LLM03 Training Data Poisoning	LLM04 Data and Model Poisoning	Scope broadened
LLM04 Model Denial of Service	LLM10 Unbounded Consumption	Broadened to cost attacks
LLM05 Supply Chain Vulnerabilities	LLM03 Supply Chain	Broadened, moved up
LLM06 Sensitive Information Disclosure	LLM02 Sensitive Information Disclosure	Moved up
LLM07 Insecure Plugin Design	LLM07 System Prompt Leakage	New entry replaces it
LLM08 Excessive Agency	LLM06 Excessive Agency	Expanded
LLM09 Overreliance	LLM09 Misinformation	Renamed and refocused
LLM10 Model Theft	LLM08 Vector and Embedding Weaknesses	New entry replaces it

The two new entries reflect where production risk moved. OWASP added System Prompt Leakage because developers cannot safely assume system prompt contents stay secret, and Vector and Embedding Weaknesses gives teams specific guidance for securing RAG systems. The scope expansions change what you monitor too: LLM10 now covers token-flood attacks and runaway application programming interface (API) costs, not only availability.

The OWASP Top 10 for LLM Applications (2025

The summary table shows where you primarily control each risk. Runtime-heavy programs need runtime telemetry, guardrails, and anomaly detection after deployment, while build-heavy risks need design reviews, component governance, and data controls before release.

Risk ID	Risk	One-Line Description	Primarily Controlled
LLM01	Prompt Injection	User or external input alters model behavior	Runtime
LLM02	Sensitive Information Disclosure	Model leaks PII, secrets, or business data	Build and runtime
LLM03	Supply Chain	Compromised third-party models, adapters, or datasets	Build
LLM04	Data and Model Poisoning	Manipulated training, fine-tuning, or RAG data	Build
LLM05	Improper Output Handling	Model output executed without validation	Build
LLM06	Excessive Agency	Agent takes damaging actions in connected systems	Build and runtime
LLM07	System Prompt Leakage	System prompt contents extracted by attackers	Build and runtime
LLM08	Vector and Embedding Weaknesses	RAG embedding poisoning and cross-tenant leakage	Build and runtime
LLM09	Misinformation	Model produces credible-sounding false output	Runtime
LLM10	Unbounded Consumption	Uncontrolled inference drives denial of service (DoS) and cost attacks	Runtime

LLM01: Prompt Injection

Prompt injection sits at the top of the list because the attack surface is the model’s own behavior. Crafted input, whether direct or hidden inside content the model retrieves, can push the model to ignore its instructions, hand data to the wrong place, or act outside its guardrails. RAG and fine-tuning narrow some failure modes but do not close the risk, because instructions and data still arrive through the same channel.

No prevention is foolproof, so the goal is to constrain the model and watch what it does. Core controls:

• Constrain model behavior: Define the model’s role in the system prompt and validate expected output formats.
• Treat external content as untrusted: Separate retrieved data and third-party content from instructions.
• Limit permissions: Give the model the least access it needs to do its job.
• Monitor the full interaction: The system prompt, user input, model response, and downstream actions belong in one view, because injection turns dangerous at the model-to-system boundary.

Detection is where a design-time checklist runs out of room, since prompt injection does its real damage when it crosses from what the model says into what the system does. 

Coralogix, a full-stack observability platform, treats that whole path as one view: a prompt-injection evaluator flags manipulated inputs inline, and LLM Tracekit records the system prompt, user input, model response, and downstream action together, so a flagged attempt connects to the action it triggered instead of sitting in a separate log. See how prompt injection works for the attack patterns behind these controls.

In 2025, EchoLeak (Common Vulnerabilities and Exposures, CVE-2025-32711) put the stakes on display: a zero-click indirect injection in Microsoft 365 Copilot exfiltrated internal file contents from a single crafted email.

LLM02: Sensitive Information Disclosure

Models can reveal what they were never meant to share: personally identifiable information (PII), financial details, health records, credentials, and confidential business data. System-prompt restrictions do not reliably stop it, because the model may not honor them and attackers can bypass them through injection. In agentic workflows the exposure widens to every prompt, model response, connected data source, tool call, and outbound API response, and the damage compounds as sensitive data moves across those points.

Prevention starts with keeping sensitive data away from the model and validating what comes back out:

• Sanitize data: apply Data-loss controls and strict input validation.
• Least-privilege access: Limit what data sources the model can reach.
• Keep secrets out of prompts: Never embed API keys, database names, or permission structures in a system prompt.
• Independent output checks: Inspect responses for compliance outside the model itself.

PII exposure is a runtime problem, not something a test suite catches at design time. Coralogix’s AI Center brings this telemetry into the platform: AI Guardrails block PII and policy violations in real time, and its LLM Tracekit shows the system prompt, user input, and model response that a prompt-only scanner never sees. Putting guardrails outside the model keeps redaction, blocking, and policy enforcement testable when prompts, tools, or model providers change.

The Dify AI system is one illustration, where vulnerabilities in the open source project gave attackers a path to read private chats and preview other tenants’ documents.

LLM03: Supply Chain

Every third-party pre-trained model, Low-Rank Adaptation (LoRA) adapter, library, dataset, and piece of infrastructure you pull in carries its own risk, and in the 2025 mapping this moved from fifth to third. A compromised supplier account, a look-alike model repository, or a careless model merge can put a backdoor into production before your own code ever runs, and published models rarely come with strong provenance assurances.

Intake controls have to pair with ongoing monitoring:

• Vet components: Apply code signing and file hashes to third-party models and dependencies.
• Gate production: Keep unvetted artifacts out through an approved model registry.
• Watch after approval: Audit collaborative environments and run anomaly detection across machine learning operations (MLOps) and LLM pipelines to catch drift.

The scale is real: researchers found 100 malicious models on Hugging Face using altered initialization files that executed on load.

LLM04: Data and Model Poisoning

Poisoning corrupts the data a model learns from, whether pre-training sets, fine-tuning data, or the RAG knowledge base, to plant backdoors, biases, or silent failures. Knowledge bases are the softest target, because they are far easier to edit than model weights.

Defense spans provenance and detection across both the model and the retrieval layer:

• Track provenance: Use tooling such as OWASP CycloneDX or a machine learning bill of materials (ML-BOM), and vet data vendors.
• Version your data: Apply data version control so manipulation shows up.
• Cover retrieval: For RAG, filter poisoned keywords, enforce lifecycle access controls, and run anomaly checks on knowledge-base changes.

Anthropic’s research found that as few as 250 malicious documents can backdoor an LLM, with similar success across the model sizes tested.

LLM05: Improper Output Handling

When an application trusts model output and passes it to another component without validation, the model becomes an injection vector. It chains directly with prompt injection: the attacker plants instructions, the model emits malicious output, and the application runs it. OWASP moved this from second to fifth in 2025, and the impact climbs when the LLM holds privileges beyond an end user or downstream extensions skip validation.

Treat the model as untrusted and check its output at every trust boundary:

• Zero-trust the model: Validate responses, use parameterized queries, and enforce a strict Content Security Policy.
• Guard the boundaries: Cover every point where the application renders, executes, queries, or forwards model output.
• Log for detection: Capture prompts, outputs, tool calls, downstream actions, and validation results so unusual patterns stand out.

Validating model output before it reaches another component closes the most direct exploitation path. CVE-2025-52573 made that concrete: shell metacharacters in LLM-exposed arguments triggered arbitrary command execution in the iOS Simulator Model Context Protocol (MCP) Server.

LLM06: Excessive Agency

The danger here is not what the model says, it is what the model is allowed to do. Give an agent broad functionality or standing permissions, and a single manipulated, ambiguous, or hallucinated output can turn into a real action in a connected system, with consequences for confidentiality, integrity, and availability.

Limiting blast radius comes down to scope and oversight:

• Minimize extensions: Cut unnecessary tools and functionality.
• Least privilege downstream: Restrict what connected systems the agent can touch.
• Human in the loop: Require verification for high-impact actions, and rate-limit tool invocation.

Those controls only hold if you can see what the agent did. Coralogix records prompts, responses, tool calls, and decision paths as traces, and its code-agent observability extends that to the coding agents teams increasingly run in production, so abnormal action patterns raise an alert instead of surfacing after the fact.

The June 2026 AI AGENT Act draft responded to the risk of agents changing account settings without user consent.

LLM07: System Prompt Leakage

Treat the system prompt as public, because you cannot keep it secret. Direct requests, injection, and other extraction techniques can all pull it back out, and once it is out, any credentials, business logic, database details, or internal rules hidden there are exposed and can help an attacker tune the next attempt.

The fix is architectural, not a better secret: move sensitive data to systems the model does not access, and inspect output for compliance through an independent system. The control worth having is knowing when someone is trying to elicit the prompt in the first place. The same LLM Tracekit visibility into the system prompt that helps with disclosure applies here, since Coralogix cannot flag leakage of a prompt your monitoring never records.

Microsoft Bing Chat is an early case, where prompt injection disclosed confidential internal directives.

LLM08: Vector and Embedding Weaknesses

The second new 2025 entry targets RAG. Weaknesses in vector storage, embedding generation, retrieval, or access control let attackers slip poisoned data, hidden instructions, or another tenant’s information into the same prompt as the user’s query. Retrieved context can carry any of those into the model, and compromised embeddings can even be reverse-engineered to recover the source text they were built from.

Defense runs across ingestion, retrieval, and generation:

• Partition tenants: Use permission-aware vector stores with strict logical partitioning to prevent cross-tenant access.
• Treat data as sensitive: Handle documents and embeddings as protected assets with lifecycle access controls.
• Monitor the data layer: Validate continuously and run anomaly checks on retrieval logs and knowledge-base changes.

The ConfusedPilot RAG attack demonstrated this: documents in an AI-indexed folder could manipulate what Microsoft’s Copilot retrieved and summarized.

LLM09: Misinformation

Misinformation is the risk that a confident, well-formed answer is wrong. Hallucination is the main driver; overreliance makes it worse when users put unverified output ahead of accuracy checks; and package hallucination opens a path for attackers, who publish malicious packages under names models tend to invent.

Detection leans on tying answers back to trusted sources. RAG helps by retrieving verified information, and your application should request reasoning and source citations that deterministic code can validate against known failure cases. Coralogix’s groundedness and hallucination evaluators score each response in real time. score each response in real time and flag the ones that drift from their retrieved context before they reach a user.

Two cases show the range. Hallucinated citations have appeared in over 280 court filings since 2023, up sevenfold in 2025, and the Air Canada chatbot invented a bereavement fare policy that failed before the British Columbia tribunal.

LLM10: Unbounded Consumption

Unbounded consumption is what happens when nothing caps inference: variable-length input floods, model extraction through the API, and Denial of Wallet, where the target is your cloud bill instead of your uptime. The service can stay responsive while cost quietly spikes, which is why request-level infrastructure metrics can miss the economic half of the attack.

Controls pair hard limits with cost-aware detection:

• Cap usage: Apply input size limits, per-user rate limiting, resource quotas, and spending caps.
• Inventory models: Keep a centralized model inventory to contain extraction.
• Instrument cost: Track cost per request, user, session, tenant, and agent alongside ordinary service metrics.

Coralogix tracks cost per message, session, and agent, and flags cost-harvesting attempts, which is where a billing anomaly becomes a security signal. LLMjacking put a number on it: attackers used stolen cloud credentials to run LLM APIs at the victim’s expense, with a worst case of over $46,000 per day.

How to Apply the OWASP Top 10 to Your LLM Applications

The ten risks weigh differently depending on whether you run a read-only chatbot, a RAG pipeline, or an autonomous agent with write access to production, so the move is to start from the pattern closest to your deployment:

• Simple chatbot: LLM01, LLM02, LLM07, and LLM09 come first, because even a read-only bot can leak training data, expose its system prompt, or hallucinate facts into a customer-facing answer.
• RAG pipeline: Add LLM08, LLM04, and LLM10, since embedding poisoning, knowledge-base injection, and whole-document prompts all stack on the same pipeline.
• Autonomous agent: Elevate LLM06 and LLM05, which chain together when an agent generates and then executes malicious output.
• Fine-tuned model: Add LLM03 and LLM04 for the supply-chain and data-poisoning exposure that fine-tuning introduces.

That first pass tells you which risks dominate before you commit to fuller threat modeling. The next step is to make those risks measurable: security posture is something you watch over time, not a one-time audit, so define the signals that prove that each priority risk stays controlled. This includes drift in model behavior, retrieval context, tool calls, sensitive-data handling, and spend. You should also monitor AI workflows in the same place as the rest of your telemetry, and test against known failure cases before release.

How Coralogix Secures LLM Applications in Production

Several OWASP risks need runtime controls as well as design-time controls, which is why the detection capabilities referenced across these risks live together in one place. Coralogix’s AI Center is where AI signals sit alongside the rest of your stack: LLM Tracekit gives teams visibility into the system prompt, user input, and model response for each interaction, AI Guardrails block PII and policy violations in real time, and anomaly detection on token usage and cost can flag Denial of Wallet patterns that conventional infrastructure metrics may miss. 

These signals correlate with the logs, metrics, and traces from the rest of your application, so a flagged prompt injection or a runaway-cost session connects to the service and infrastructure context an investigation needs.

If your team is shipping LLM features into production and your monitoring only sees inputs and outputs, you are missing the system prompt, model response, and per-session cost that turn these risks into runtime signals. Start a 14-day free trial of Coralogix to bring that telemetry into the same view as the logs, metrics, and traces you already trust.

Frequently Asked Questions About the OWASP Top 10 for LLM Applications

How is the OWASP Top 10 for LLM Applications different from the OWASP Top 10 for web apps?

The web application Top 10 targets software logic flaws and misconfiguration that web application firewalls handle well, while the LLM list addresses statistical model behavior where natural-language attacks are difficult to enumerate with fixed signatures. Because an LLM processes instructions and data in the same channel, prompt injection has no direct equivalent on the web list.

How does the OWASP LLM Top 10 map to NIST AI RMF and the EU AI Act?

The OWASP risks map to control objectives in the National Institute of Standards and Technology (NIST) AI Risk Management Framework (RMF) and its Generative AI Profile, which cover risks common to LLM use. The European Union (EU) AI Act appears as a referenced framework in OWASP’s AIUC-1 crosswalk document.

Does the OWASP Top 10 for LLM Applications apply to AI agents?

Yes, primarily through LLM06 Excessive Agency, which OWASP expanded as agentic architectures spread. OWASP also released a dedicated Top 10 for Agentic Applications in 2026, and the LLM list keeps evolving with real-world incidents. If you are already running agents, the practical question is whether you can see what they do at runtime; to run that check against your own agent traffic, try Coralogix for free and watch prompts, tool calls, and responses in one place.

How often is the OWASP Top 10 for LLM Applications updated?

There is no fixed annual interval. The project has shipped multiple versions since its initial release, and OWASP refreshes the list to reflect real-world incidents and emerging attack techniques.