Look at the whole AI application
The ten risks span the information, the model, and the actions around it.
What goes in
Prompts, retrieved records, datasets, and dependencies.
What is generated
Answers can be misleading, sensitive, or unsafe to use.
What can happen
Tools, permissions, downstream systems, and resource use.
Ask where each input comes from, who can change it, and who may access it. Prompt injection, poisoning, supply-chain issues, and retrieval weaknesses can start before an answer is generated.
Model output needs context-appropriate validation. An answer can contain sensitive details, incorrect claims, or content that becomes dangerous when another component treats it as code or a command.
Ask what the application can do with an answer. Limit agency, validate downstream use, and control resource consumption. The OWASP list is a starting map rather than a complete system-specific threat model.
An AI assistant is more than a model. It has instructions, user input, retrieved documents, software dependencies, permissions, and somewhere to display its answer. Each connection creates a question: what could go wrong here, and what would stop it?
The OWASP Top 10 for LLM Applications, 2025 edition gives builders a shared vocabulary for those questions. This guide uses that specific edition so the names and numbers stay clear as the field changes.
Treat it as a starting map for review. A list cannot certify your product, replace threat modeling, or prove that a defense works. Your application’s data, users, and capabilities determine which failures matter most.
Follow one simple application
Imagine a fictional assistant that reads product manuals, answers support questions, and drafts replies. Later, the team gives it a tool to send those replies.
The model stays the same, but the possible consequences change. An incorrect answer can now become a message delivered to a customer. This is why an AI security review follows the complete application, from incoming material to actual outcomes.
Use that assistant as a running example while reading the ten risks below. Each first defense is a starting action, not a complete fix.
The ten risks in plain language
LLM01:2025 — Prompt Injection
Outside text redirects the model away from the authorized task. A product manual might tell the assistant to change its instructions or send information elsewhere.
First defense: keep retrieved material separate from privileged instructions and independently authorize tool actions. A model’s decision to comply does not grant permission. Official LLM01 guidance.
LLM02:2025 — Sensitive Information Disclosure
Private information reaches someone who should not receive it. For example, a support response includes another customer’s notes because retrieval exposed too much context.
First defense: enforce access before retrieval and minimize the information supplied to the model. Review responses and logs for unintended exposure too. Official LLM02 guidance.
LLM03:2025 — Supply Chain
The application inherits risk from models, packages, datasets, adapters, and services it depends on. An unreviewed model download or compromised dependency can affect the whole system.
First defense: inventory dependencies, verify their origin, and review version changes. A familiar filename is not evidence of a trustworthy artifact. Official LLM03 guidance.
LLM04:2025 — Data and Model Poisoning
Someone manipulates data used for training, fine-tuning, or embeddings so later behavior serves their goal. A tampered knowledge source can also influence what the assistant uses as evidence during retrieval.
First defense: control who can modify datasets and knowledge sources, preserve versions, and investigate unexpected changes in behavior. Official LLM04 guidance.
LLM05:2025 — Improper Output Handling
An application uses model output in an unsafe destination. Generated HTML rendered without appropriate protection, for example, can create a browser security problem.
First defense: validate and encode output for its actual destination. Do not automatically execute generated commands or concatenate generated text into database queries. Official LLM05 guidance.
LLM06:2025 — Excessive Agency
The assistant has more capabilities, permissions, or freedom to act than its job requires. A support drafting tool probably does not need unrestricted account deletion.
First defense: provide narrowly scoped tools and permissions, with meaningful review for consequential actions. Removing an unnecessary capability removes a route to misuse it. Official LLM06 guidance.
LLM07:2025 — System Prompt Leakage
Internal instructions are exposed. The deeper issue is often what those instructions contain or what the system relies on them to enforce.
First defense: keep secrets out of prompts and enforce permissions in application code. Disclosure of ordinary instructions should not unlock an account or reveal credentials. Official LLM07 guidance.
LLM08:2025 — Vector and Embedding Weaknesses
The retrieval layer introduces weaknesses such as cross-user data exposure or manipulated search results. Similarity to a question does not mean a document is authorized or reliable.
First defense: enforce document-level access, isolate tenants appropriately, and check source integrity throughout ingestion and retrieval. Official LLM08 guidance.
LLM09:2025 — Misinformation
The assistant produces misleading or unsupported information that people rely on. A fluent answer may invent a product feature or cite a source that does not support the claim.
First defense: check important claims against reliable evidence, make uncertainty visible, and require suitable human review for consequential decisions. Official LLM09 guidance.
LLM10:2025 — Unbounded Consumption
Requests consume excessive computation, time, or money. A long-running agent loop or unrestricted workload can exhaust resources even when no private data is stolen.
First defense: set request, token, time, concurrency, and spending limits. Add cancellation and measure actual consumption. Official LLM10 guidance.
Risks can overlap in one incident
In our fictional support assistant, a tampered manual tells the model to send internal notes to an outsider. The application supplies the notes, and a broadly privileged mail tool sends them without review.
You could discuss this as prompt injection, information disclosure, and excessive agency. The labels describe different parts of the same failure. Collect the evidence and fix the relevant boundaries rather than arguing that only one category may apply.
A useful finding names the entry point, the affected data or action, the missing control, and the observed result.
Try a fifteen-minute design review
Draw your own assistant on paper: input sources, model, retrieval store, output destinations, and tools. Choose one valuable item, such as customer notes, and follow where it can travel.
For each connection, write one failure and one check. For example: “A different customer’s notes enter retrieval; check that the search excludes documents the current user cannot access.” Use fictional records in a local or authorized test environment.
Then record the result and what remains untested. A control written in a design document is an intention; a test provides evidence about its implementation.
Pause and predict: if you remove every action tool, does every risk disappear? No. Disclosure, misinformation, retrieval weaknesses, and excessive resource use can still matter in an assistant that only answers questions.
Choose your next deeper read
This article covers all ten names at an introductory level. The current companion guides examine the first four in more detail: prompt injection, sensitive information disclosure, supply chain, and data and model poisoning.
The practical habit is to connect each risk to a real boundary, a responsible owner, and a check you can repeat. The official OWASP pages linked above provide the fuller definitions and mitigation guidance; the scenarios and explanations here are original learning examples.