OWASP LLM Top 10 2025: Risks and Controls for AI Applications

The OWASP LLM Top 10 2025 is an awareness document for security risks in applications that use large language models. The ten categories cover prompt injection, information disclosure, supply chains, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption.

The official OWASP Top 10 for LLM Applications 2025 replaced the original 2023 list. The 2025 edition adds System Prompt Leakage and Vector and Embedding Weaknesses, and it broadens resource denial into Unbounded Consumption to include financial and operational cost.

The list applies to the application around the model, not solely to model training. Retrieval, prompts, tools, identity, storage, output processing, APIs, and user interfaces determine whether uncertain model behavior becomes a security event.

Key Takeaways

• Treat prompts, retrieved content, model output, embeddings, memory, and external data as untrusted inputs with separate provenance.
• Keep credentials, authorization, validation, and high-impact actions outside the model’s control.
• Assume prompt injection cannot be eliminated completely and reduce its reach through isolation, least privilege, and approval.
• Test the whole LLM application under hostile input, model error, upstream compromise, resource pressure, and downstream failure.

What Changed in the 2025 LLM Top 10

OWASP retained Prompt Injection at LLM01 and added more attention to indirect and multimodal inputs. A malicious instruction may live in a web page, file, image, email, retrieved passage, or tool result rather than the user’s visible prompt. Retrieval-augmented generation and fine-tuning do not remove that underlying problem.

System Prompt Leakage now has its own category because applications often store secrets, credentials, or authorization logic in a prompt that users can influence. Vector and Embedding Weaknesses addresses access, poisoning, and isolation problems in retrieval systems. Unbounded Consumption expands the older denial-of-service framing to cover token usage, model extraction, and unexpected cost.

The category called Excessive Agency predates the separate 2026 Agentic Applications Top 10. LLM06 focuses on excessive functionality, permissions, or autonomy in an LLM application, while the agentic list examines wider multi-step and multi-agent risks.

OWASP LLM Top 10 2025 Risks Explained

LLM01: Prompt injection

Prompt injection occurs when input changes model behavior in an unintended way. Direct injection comes from the user, while indirect injection arrives through content the application supplies to the model. The model cannot reliably distinguish trusted instructions from hostile natural language based on placement alone.

Limit the model’s role, separate untrusted content, constrain tools, validate proposed actions, and require approval for high-impact operations. Do not treat a system prompt or retrieval step as a security boundary. Test injection through every supported modality and source.

LLM02: Sensitive information disclosure

An LLM application may reveal personal data, confidential documents, credentials, proprietary prompts, training data, or records retrieved for another user. Disclosure can appear in output, logs, traces, caches, embeddings, memory, or third-party model requests.

Minimize data before it reaches the model, apply access control before retrieval, and isolate tenants and sessions. Redact secrets from prompts and telemetry, define retention with providers, and filter outputs as a secondary safeguard. The source system must remain the authority for who may access a record.

LLM03: Supply chain

The LLM supply chain includes models, datasets, adapters, packages, frameworks, prompt assets, plugins, model repositories, hosted APIs, and deployment images. A compromised or mislabeled component can change behavior, execute code, or expose data.

Record provenance and version for every component, review licenses and source, verify artifacts, and restrict remote code loading. Pin dependencies and model revisions, scan packages, isolate model conversion and loading, and test updates before production. Maintain a replacement and rollback plan for external services.

LLM04: Data and model poisoning

Poisoning changes training, fine-tuning, retrieval, feedback, or model assets so later output follows an attacker’s goal. A small number of crafted records may insert false facts, hidden triggers, biased behavior, or malicious instructions into a system that trusts its data pipeline.

Control who can add or alter data, preserve provenance, review high-impact sources, and detect unusual changes. Separate untrusted feedback from automatic learning and validate retrieval collections before indexing. Evaluate models and datasets against known clean baselines after updates.

LLM05: Improper output handling

Improper output handling occurs when downstream code treats model text as safe. Generated content can become HTML, SQL, shell commands, source code, file paths, URLs, templates, or API arguments, creating injection and execution paths.

Treat output like user input and apply the control required by the receiving interpreter. Use parameterized APIs, contextual encoding, strict schemas, allowlisted operations, and sandboxes. A second model that reviews the first model’s response is not a deterministic security control.

LLM06: Excessive agency

Excessive agency gives an LLM application more functions, permissions, or autonomy than its task needs. A support assistant with access to delete accounts has a larger impact from prompt injection or model error than one limited to drafting a response.

Reduce tool count and split read from write operations. Use narrow service identities, transaction limits, scoped targets, short sessions, and approval for consequential actions. Enforce each decision in code at the tool boundary rather than asking the model whether its own action is safe.

LLM07: System prompt leakage

System prompts may be exposed through direct requests, indirect attacks, model behavior, logs, client code, or debugging interfaces. Leakage matters most when developers place secrets, private data, or control logic in text that the model must read.

Assume users may learn the prompt. Keep credentials and security rules in protected services, minimize sensitive instructions, and avoid using prompt secrecy as authorization. Leakage testing can still find unnecessary internal details, but rewriting the prompt does not fix an architectural secret.

LLM08: Vector and embedding weaknesses

Retrieval systems can expose records across users, accept poisoned documents, return stale content, or leak meaning through embedding and metadata access. Similarity is not authorization, and a vector database filter is effective only if tenant and object attributes are accurate and enforced.

Authorize before retrieval and again before returning the source record. Partition collections where appropriate, verify ingestion sources, preserve document ownership and version, and remove data completely when access ends. Test adversarial queries, cross-tenant identifiers, poisoned documents, and deleted content.

LLM09: Misinformation

Models can produce false, unsupported, outdated, or fabricated claims with confident wording. Security impact grows when applications use those claims for medical, legal, financial, operational, or access decisions without verification.

Define which outputs require sources and which actions require authoritative confirmation. Show provenance, communicate uncertainty, compare claims with primary systems, and place human review where errors have material consequences. Retrieval may improve grounding, but retrieved content can also be wrong or hostile.

LLM10: Unbounded consumption

Attackers and ordinary use can trigger excessive tokens, compute, storage, API calls, tool loops, or paid third-party work. Abuse may cause denial of service, large bills, model extraction, or degraded capacity for other users.

Limit input and output size, requests, concurrency, steps, tool calls, retrieval depth, time, and spending by identity and task. Use hard ceilings and cancellation that stops downstream work. Detect distributed abuse and avoid exposing detailed model behavior that makes extraction easier.

LLM Security Controls Belong at Trust Boundaries

Prompt defenses operate inside an uncertain model. Security controls need to sit where data or authority crosses into a component with real effects. Examples include access checks before retrieval, schema validation before a tool call, and output encoding before generated text reaches a browser.

This architecture also lets teams replace models without redesigning every security rule. The model proposes a search, answer, or action, while ordinary application code resolves identity, permissions, data scope, and side effects. The AI identity infrastructure article describes how agent and workload identity fit this model.

Separate safety behavior from security enforcement. A model refusal can reduce harmful responses, but it should not guard a database row or production command. If bypassing a prompt reveals data or changes a system, the surrounding application granted too much authority.

How to Test an LLM Application

Inventory every input source, model, prompt, memory store, retrieval collection, tool, output destination, and provider. Mark the data classification, tenant, identity, and authority at each connection. This makes the test scope larger than the chat box.

Build test cases for direct and indirect injection, sensitive records, hostile files, manipulated tool results, malformed model output, cross-tenant retrieval, long requests, repeated tool loops, provider failure, and revoked access. Record the actual downstream effects and policy decisions, not simply whether the model said something undesirable.

Run regression tests after changes to models, prompts, retrieval data, tools, policies, and dependencies. Model updates can change which attacks succeed, while application updates can change the impact of the same output. Preserve test prompts and expected security outcomes without assuming identical generated wording.

LLM, Agentic, and MCP Lists Address Different Layers

The LLM Top 10 applies broadly to applications using large language models. The Agentic Applications Top 10 adds risks created by planning, memory, delegation, inter-agent communication, and autonomous action. The MCP Top 10 focuses on credentials, tools, context, and servers connected through Model Context Protocol.

An agentic application using MCP may need all three. For example, indirect prompt injection can hijack an agent goal, which then invokes an overprivileged MCP tool. Review the shared data flow once and map each list to the controls and tests at that boundary.

Frequently Asked Questions

What is the latest OWASP LLM Top 10 version?

The current released edition is the OWASP Top 10 for LLM Applications 2025. OWASP published it in November 2024 as the successor to the 2023 list. Reports should include the edition year because several categories changed.

Can prompt injection be prevented completely?

OWASP states that prompt injection follows from how generative models process instructions and content, so foolproof prevention is unclear. Teams should reduce impact with constrained tools, narrow permissions, input separation, validation, approval, and monitoring. A successful injection should still encounter ordinary authorization at every protected resource.

Is a system prompt a security control?

A system prompt can define model behavior, but users may influence the model or learn parts of the prompt. It should not contain credentials or act as the only access-control rule. Enforce sensitive decisions in code and protected policy services outside the model.

Does RAG solve LLM hallucination and prompt injection?

Retrieval can provide relevant source material, but it does not guarantee that the source is correct, authorized, or free from hostile instructions. The model may still misstate retrieved facts or follow injected content. RAG systems need ingestion security, access control, provenance, output verification, and injection testing.