The OWASP Top 10 for LLM Applications (2025), Explained for Business Owners

If you keep hearing "prompt injection" and want the real story without the jargon, this is it. The OWASP Top 10 for LLM Applications (2025) is the security industry's shortlist of the ten most critical risks in AI software, numbered LLM01 to LLM10. Below we walk each one in plain English — what it is, why it matters to your business, and how owning your own AI stack helps. The honest part: going on-prem genuinely reduces some of these risks and does nothing for others. We say which is which.

Secure My AI Build Call 832-338-2926

What the OWASP LLM Top 10 is — and what changed in 2025

OWASP is the long-running open community behind the well-known web-application Top 10. The OWASP Top 10 for LLM Applications is its newer, community-maintained list of the most critical risks specific to software built on large language models — the systems behind chatbots, document assistants, and AI agents. The current edition is the 2025 list, and we attribute it to OWASP throughout this page.

Per the OWASP 2025 list, two entries are new to this edition: System Prompt Leakage (LLM07) and Vector and Embedding Weaknesses (LLM08) — the latter reflecting how common document-search (RAG) systems have become. Prompt Injection remains the number-one risk at LLM01. We re-verify the list against the official OWASP source before relying on it, rather than treating any single summary as gospel.

The ten risks at a glance

Each risk in one line, with an honest read on whether running the model on your own hardware helps. "Yes" means on-prem materially reduces it; "Partly" means it helps but does not solve it; "No" means it is a design-level issue that owning the box does not fix.

Code	Risk	In plain English	Does on-prem help?
LLM01	Prompt Injection	Crafted input tricks the model into ignoring your instructions.	No
LLM02	Sensitive Information Disclosure	The model reveals data it should have kept private.	Yes
LLM03	Supply Chain	A model, library, or dataset you pulled in is compromised.	Partly
LLM04	Data and Model Poisoning	Tainted training or fine-tuning data corrupts the model.	Partly
LLM05	Improper Output Handling	App trusts model output blindly and passes it somewhere dangerous.	No
LLM06	Excessive Agency	The AI is given more power or autonomy than the task needs.	No
LLM07	System Prompt Leakage	Hidden setup instructions get exposed to users or attackers.	No
LLM08	Vector and Embedding Weaknesses	The RAG document store is poisoned or leaks between users.	Partly
LLM09	Misinformation	The model states something false with full confidence.	No
LLM10	Unbounded Consumption	Unlimited or abusive use exhausts resources or runs up cost.	Partly

List and codes attributed to the OWASP Top 10 for LLM Applications (2025). Re-verify against the official OWASP source before publication, as the list is revised over time.

LLM01 — Prompt Injection

What it is. An attacker feeds the model crafted text that overrides your instructions. Direct injection comes straight from a user's chat box. Indirect injection hides instructions inside a document, web page, or image the model is asked to read — so the trap is sprung when the AI processes the content, not when someone types.

Why it matters. A model reads instructions and data through the same channel, so it can be talked into leaking context, calling a tool it shouldn't, or producing harmful output. Document and RAG pipelines are the real exposure, because the poisoned instruction can sit quietly in a file you uploaded.

How owning your stack helps. Honestly, it doesn't fix this one. Prompt injection is a design-level issue (LLM01), not something a private network removes. What helps is how the application is built — input and output separation, least agency, and human review. We go deep on it in our prompt injection protection guide.

LLM02 — Sensitive Information Disclosure

What it is. The model surfaces data it should have kept private — another user's input, secrets baked into context, or confidential records it had access to.

Why it matters. This is the nightmare that drives most "should we even use AI?" conversations. With a public AI API, your prompts and documents leave the building and become entries in a log you can't see.

How owning your stack helps. This is where on-prem genuinely moves the needle. When the model, the prompts, and the document store all live on hardware you own, there is no vendor API in the path retaining your inputs. You still need access control and encryption inside the building, but the off-site exposure simply goes away. See our local LLM security guide for the full control set.

LLM03 through LLM10 — the rest, in plain English

Each card gives you what it is, why it matters, and how owning your stack helps — with the on-prem angle called out honestly.

LLM03 — Supply Chain

What it is: A model, library, dataset, or plugin you pulled in from outside is tampered with or carries a hidden flaw.
Why it matters: You inherit the trust of every component you ship. A backdoored model or a compromised dependency lands inside your walls.
How owning your stack helps: Partly. You can pin and verify exactly which model and packages you run, and apply signed updates on your schedule instead of auto-pulling. You still have to vet what you bring in — owning the box does not vet the model for you.

LLM04 — Data and Model Poisoning

What it is: Tainted data slips into training or fine-tuning, corrupting how the model behaves — sometimes with a deliberate trigger.
Why it matters: A poisoned model can be subtly wrong or carry a hidden backdoor that activates on a specific input, which is hard to spot after the fact.
How owning your stack helps: Partly. Controlling your own training and fine-tuning data, and curating what feeds it, shrinks the attack surface versus an opaque third-party pipeline. The discipline still has to be there.

LLM05 — Improper Output Handling

What it is: The application trusts whatever the model returns and passes it straight into a database, a command, a web page, or another system.
Why it matters: If model output flows unchecked into code or queries, an attacker who can steer the model can reach systems behind it. The model becomes a way in.
How owning your stack helps: No. This is an application-design problem. The fix is treating model output as untrusted — validating and escaping it before it touches anything — regardless of where the model runs.

LLM06 — Excessive Agency

What it is: The AI is wired to take actions — send email, run tools, change records — with more permission or autonomy than the task actually needs.
Why it matters: When an over-empowered agent is manipulated (often via injection), the damage is whatever it was allowed to do. Broad permissions mean a broad blast radius.
How owning your stack helps: No. Owning the box does not narrow the agent's powers — you do, by scoping least privilege, requiring human-in-the-loop for consequential actions, and limiting what tools it can call.

LLM07 — System Prompt Leakage

What it is: The hidden setup instructions that shape the model's behavior get exposed to users or attackers. New in the 2025 list.
Why it matters: If those instructions hold secrets or reveal guardrail logic, leaking them hands an attacker a map for bypassing your controls.
How owning your stack helps: No. The real fix is to never put secrets in the system prompt and to assume it can be extracted. On-prem keeps the prompt off a vendor's servers, but a determined user can still coax it out.

LLM08 — Vector and Embedding Weaknesses

What it is: The document store behind a RAG system is poisoned, or content leaks between users who should not see each other's data. New in the 2025 list.
Why it matters: RAG is where most business value lives — and the vector store holds your documents. Weak access boundaries there can leak one client's data into another's answer.
How owning your stack helps: Partly. Keeping the vector store on your own hardware removes the third-party exposure, and per-user access boundaries stop cross-leaks — but you have to build those boundaries; a private box alone does not.

LLM09 — Misinformation

What it is: The model states something false with complete confidence — the familiar "hallucination" problem.
Why it matters: A confident wrong answer in a quote, a contract summary, or medical or legal context can cause real harm if a person acts on it unchecked.
How owning your stack helps: No. Local or cloud, models still make things up. Grounding answers in your own verified documents and keeping a human in the loop for high-stakes output is the mitigation.

LLM10 — Unbounded Consumption

What it is: Unlimited, abusive, or runaway use exhausts compute, degrades service, or runs up cost — including attempts to extract the model itself.
Why it matters: On a metered cloud API this is a surprise bill; on any deployment it is a denial-of-service and a model-theft risk if requests are not bounded.
How owning your stack helps: Partly. On owned hardware there is no per-token meter to run up, which removes the cost-explosion angle. You still want rate limits and access control so one user can't starve everyone else.

What actually changes when you own the box

Read the "Does on-prem help?" column honestly and a pattern appears. Owning the hardware is strongest against the data-exposure risks — sensitive information disclosure (LLM02), parts of supply chain (LLM03), and the vector store side of embedding weaknesses (LLM08) — because your model, prompts, and documents never leave the building. That is real, and it is the core of why private AI exists.

It is weakest against the design-level risks — prompt injection (LLM01), improper output handling (LLM05), excessive agency (LLM06), system prompt leakage (LLM07), and misinformation (LLM09). These live in how the application is built, not where it runs. A private network does not patch them; deliberate engineering does.

So the controls that move the needle pair the two: keep the data on owned hardware, then add access control, output handling, least agency, and logging on top. Lock down "who can do what" on the box with RBAC, SSO and MFA, and see the whole defense stack in our local LLM security guide.

Mapping each risk to a control we build

No single fix covers all ten. Here is the concrete control we reach for against each, on a real TIS build.

LLM01 Prompt Injection

Input/output separation, least agency, and human review — not a network setting.

LLM02 Sensitive Disclosure

On-prem data residency plus per-role access control so the model only sees what it should.

LLM03 Supply Chain

Pinned, verified models and packages; signed updates applied on your schedule.

LLM04 Data Poisoning

Curated training and fine-tuning data you control, not an opaque pipeline.

LLM05 Output Handling

Treat model output as untrusted — validate and escape before it touches any system.

LLM06 Excessive Agency

Least-privilege tool access and human-in-the-loop for consequential actions.

LLM07 System Prompt Leakage

No secrets in the system prompt; assume it can be extracted.

LLM08 Embedding Weaknesses

Vector store on owned hardware with per-user access boundaries.

LLM09 Misinformation

Grounding in your verified documents plus human review for high-stakes output.

LLM10 Unbounded Consumption

Rate limits and access control; no per-token meter to run up on owned hardware.

We design against this list on builds across Texas

We don't hand you a model and wish you luck. We build the private stack that shrinks the data-exposure risks, then engineer the controls the design-level risks demand — and we install and support it on-site across Houston, Katy, Fulshear and the Fort Bend area. See our Texas service areas.

OWASP LLM Top 10 questions

What is the OWASP Top 10 for LLM Applications?+

It is a community-maintained list, published by OWASP, of the ten most critical security risks for applications built on large language models. The current edition is the 2025 list, numbered LLM01 through LLM10. We design private AI builds against it.

Does running AI on-premise fix all ten risks?+

No, and we will not pretend otherwise. Owning the box materially reduces some risks — sensitive information disclosure and parts of the supply chain — because your data and model stay in your building. But others, like prompt injection and improper output handling, are design-level issues that on-prem does not solve. They need controls in how the application is built.

What changed in the OWASP 2025 LLM list?+

Per the OWASP 2025 list, two entries are new this edition: System Prompt Leakage (LLM07) and Vector and Embedding Weaknesses (LLM08). Prompt Injection remains the number-one risk at LLM01. We attribute the list to OWASP and re-verify it against the official OWASP source.

Why is prompt injection still the top risk?+

Because an LLM reads instructions and data through the same channel, so a crafted input — or hidden text inside a document the model reads — can override what you told it to do. It is a design-level problem, not a patch, which is why it sits at LLM01 and why going local does not remove it.

How does TIS build against the OWASP LLM Top 10?+

We keep the model, prompts, and document store on hardware you own to shrink the data-exposure risks, then layer on the controls the design-level risks need — output handling, least agency, role-based access, and logging. We map each risk to a concrete control rather than promising a single fix.

Go deeper on the risk on-prem can't fix in prompt injection protection, lock down access with AI access control, or read the full local LLM security guide.

Want an AI build that respects this list?

Tell us what you want the AI to do and what data it will touch — we'll scope a private build that shrinks the risks owning the box can fix and engineers around the ones it can't.