On 3 August 2026, the OWASP GenAI Security Project published the 2026 edition of its Top 10 for LLM Applications — the closest thing the field has to an agreed list of how AI applications actually get attacked. I read it the way I read most security guidance: not as a compliance checklist for a big enterprise, but as a homelab operator asking one blunt question. I run local models on my own hardware — Ollama, Open WebUI, a couple of RAG experiments. Which of these ten risks are actually mine?
This is that translation. Every item below is straight from OWASP’s public list; the framing — how each risk shows up when you are the one running the model, and the single most useful thing to do about it — is mine, based on running this stuff at home.
What’s actually new in 2026
If you already know the 2025 list, the headline is reassuring: the ten categories carry over by name. Prompt injection is still number one. What changed is underneath the titles. The 2026 edition re-ranks the risks against a much larger body of real incident data, expands the threat coverage inside each category, and — the part I find genuinely useful — maps every entry to established frameworks like the NIST AI Risk Management Framework, MITRE ATLAS and CWE. That mapping is what lets you connect “prompt injection” to a control you can actually implement rather than leaving it as a scary phrase.
OWASP also shipped a companion list this cycle, the Top 10 for Agentic Applications, aimed at autonomous, tool-using AI. That is a signal worth reading on its own: the risk conversation has moved from “the chatbot said something wrong” to “the agent took an action on my behalf.” If you are wiring a local model into anything that can do things — run shell commands, hit APIs, move files — that second list is for you too.
The short version
Same ten categories as 2025, re-ranked and re-evidenced, now mapped to NIST, MITRE ATLAS and CWE, with a separate list for agentic systems. If you self-host AI, five of these ten are your day-one problem. The rest matter more the moment you connect the model to your data or your tools.
The 2026 LLM Top 10, translated for self-hosters
Prompt Injection
Instructions hidden in content the model reads — a web page, a document, an email — that hijack what it does. Still the number-one risk, and the hardest to fully close.
At home: the moment your Open WebUI setup can browse a URL or read a file you didn’t write, that content can carry instructions. A “summarise this page” request is also “run whatever that page tells you to.”
Do this: treat any model that reads external content as untrusted, and never give that model the ability to take irreversible actions without a human confirming. Separation of privilege beats clever filtering.
Sensitive Information Disclosure
The model reveals data it shouldn’t — secrets in its context, other users’ data, or details from its training or retrieval sources.
At home: ironically this is why a lot of us self-host — to keep data off someone else’s servers. But a local RAG index pointed at your whole Documents folder will happily quote your bank statements back to anyone who can reach the chat box.
Do this: be deliberate about what you feed a retrieval index, and put authentication in front of any AI endpoint before it leaves localhost.
Supply Chain
Compromised or untrustworthy models, datasets, libraries or extensions pulled into your stack.
At home: that random GGUF quant from an unknown uploader, or a one-click “AI app” template, is code and weights you are running with your own hands. Model files can carry more than weights.
Do this: prefer models and images from sources you can name, pin versions, and use safetensors-format weights over pickle-based formats where you have the choice.
Data and Model Poisoning
Deliberately corrupted training or fine-tuning data that plants bad behaviour or backdoors in a model.
The gear I run for this
Hardware from my own homelab, relevant to this guide — direct Amazon links.
Affiliate links — I earn a small commission at no extra cost to you. Browse my full homelab store →
At home: less of a concern if you only run off-the-shelf models, but real the moment you fine-tune on scraped or community-contributed data.
Do this: know the provenance of anything you fine-tune on, and keep a clean baseline model to compare behaviour against.
Improper Output Handling
Treating model output as trustworthy and passing it straight into another system — a shell, a browser, a database.
At home: this is the one that bites homelabbers. You ask a model for a command and pipe it into a terminal; you let it generate HTML that renders in your dashboard. Its output is untrusted input to whatever consumes it.
Do this: never auto-execute model output. Escape it, sandbox it, and put a human between “the model suggested this” and “the system ran it.”
Excessive Agency
Giving a model more capability, permission or autonomy than the task needs — so a mistake or an injection becomes an action.
At home: the temptation to hand your local agent broad access — your files, your smart home, your scripts — because it’s convenient. Convenience and blast radius are the same dial.
Do this: grant the narrowest tools and scopes that work, and require confirmation for anything destructive. This is the single biggest lever on the new agentic risks.
System Prompt Leakage
The assumption that your system prompt is secret — and the damage when its contents (rules, keys, internal details) leak.
At home: if you’ve tucked an API key or a “you have access to X” instruction into a system prompt, assume a determined user can extract it.
Do this: keep secrets and real authorisation outside the prompt entirely. The prompt shapes behaviour; it is not a security boundary.
Vector and Embedding Weaknesses
Attacks on the RAG layer — the vector store and embeddings that give a model your private knowledge.
At home: this category grew up as we all bolted RAG onto local models. A shared vector store with no access control leaks across every document in it; poisoned content in the index steers answers.
Do this: scope vector stores per trust boundary, and control what gets ingested as carefully as what gets queried.
Misinformation
Confident, wrong output — and the human tendency to over-trust it, especially when it’s fast and fluent.
At home: a local 7B model asked for a firewall rule or a Docker command will give you something that looks right. Running it on your own network is how a hallucination becomes an outage.
Do this: verify anything operational before you act on it. Treat model answers as a knowledgeable draft, never as a source of truth.
Unbounded Consumption
Resource and cost exhaustion — runaway generation, denial-of-wallet on hosted APIs, or a self-hosted box driven into the ground.
At home: less about a cloud bill, more about an exposed Ollama endpoint someone else discovers and drives your GPU flat, or a runaway loop that pins the machine.
Do this: don’t expose inference endpoints to the internet without authentication and rate limits. A local model behind an open port is someone else’s free compute.
Which of these are actually yours?
The honest answer depends on how far down the road you are. Here’s how I’d triage it for a typical self-hosted setup.
| If your setup is… | The risks that matter most |
|---|---|
| A local chat model (Ollama + Open WebUI), nothing connected | LLM02 (data), LLM09 (misinformation), LLM10 (exposed endpoint) |
| A model that reads your documents (RAG) | Add LLM01, LLM02, LLM08 — the retrieval layer is now your soft spot |
| A model that can take actions (agent, tools, scripts) | Add LLM05, LLM06 — and read the companion Agentic Top 10 |
| You fine-tune or run unknown model files | Add LLM03, LLM04 — provenance becomes the whole game |
Five things to do this weekend if you run a local LLM
- Put authentication in front of every AI endpoint — no open Ollama or Open WebUI ports reachable beyond your LAN or VPN.
- Assume model output is untrusted input. Never pipe it straight into a shell, and never auto-execute it.
- Be deliberate about what your RAG index can see. A whole-home-folder index is a data-disclosure risk wearing a helpful hat.
- Give any agent the narrowest tools that work, and require confirmation for anything it can’t undo.
- Keep secrets out of system prompts entirely — the prompt is not a vault.
Where this fits on the site
If you’re setting any of this up, the practical guides here line up with the risks above. My local LLMs hub covers choosing and running models on your own hardware, the self-hosted apps guide includes the Ollama and Open WebUI stack this article keeps referring to, and the homelab security material is where “put authentication in front of it” stops being a slogan and becomes a setup. The one-line summary of the whole OWASP list, for a self-hoster: the model is not the risk — everything you connect it to is.
Source: the OWASP Top 10 for LLM Applications 2026, published by the OWASP GenAI Security Project on 3 August 2026. The ten category names are OWASP’s; the self-hosting commentary and recommendations are my own. AI assisted with drafting this article; the framing and the practical guidance come from running local models in my own homelab.