The OWASP Top 10 for LLM applications, read as a buyer's checklist

AI security is not conventional security with a new logo on it. Language models introduce failure modes that firewalls and antivirus were never designed to see. OWASP maintains the reference list, and the 2025 edition names ten:

• LLM01:2025 Prompt Injection
• LLM02:2025 Sensitive Information Disclosure
• LLM03:2025 Supply Chain
• LLM04:2025 Data and Model Poisoning
• LLM05:2025 Improper Output Handling
• LLM06:2025 Excessive Agency
• LLM07:2025 System Prompt Leakage
• LLM08:2025 Vector and Embedding Weaknesses
• LLM09:2025 Misinformation
• LLM10:2025 Unbounded Consumption

OWASP describes the list's scope as covering “risks, vulnerabilities and mitigations for developing and securing generative AI and large language model applications across the development, deployment and management lifecycle”. Development, deployment and management. Not hosting.

What they mean to a business reader

Prompt injection is an attacker writing text that the model treats as an order. It is first on the list for a reason, and it has already produced a real vulnerability in a shipped product.

Sensitive information disclosure is the assistant revealing something it should not, whether from its training, its context or a document it was allowed to retrieve.

Supply chain covers the model weights, the datasets, the inference engine and every library underneath. A model is a dependency, and it arrives from somewhere.

Data and model poisoning is contamination of what the system learns from, whether in training, fine-tuning or retrieval.

Improper output handling is treating generated text as safe input for another system. If an answer becomes a database query, a shell command or an email, it is an untrusted string that happens to be fluent.

Excessive agency is giving the model more power than the task needs. It is the multiplier on every other entry in the list.

System prompt leakage matters because teams routinely put rules, and sometimes secrets, in the system prompt and treat it as private. It is not.

Vector and embedding weaknesses are the risks of the retrieval layer: the index is a second copy of the content, and access to it is access to the source.

Misinformation is the model being confidently wrong, which is an operational risk wherever an answer is acted on without review.

Unbounded consumption is unbounded cost and unbounded load. In a metered service it is a bill. On a fixed appliance it is a queue.

Which of the ten does hosting change?

Being honest about this is the whole point of the article.

Local deployment narrows the exfiltration path for LLM01 and LLM02, because an instruction that succeeds still needs somewhere to send the data. It gives the organisation direct control over LLM03 and LLM08, because the model, the engine and the index are all on its own equipment. It changes the shape of LLM10 from a variable bill to a fixed capacity.

It does nothing at all for LLM04, LLM05, LLM06, LLM07 and LLM09. Those are decided by the application, the permissions and the review process, and they are identical whether the model is in a rack or a region.

Five of the ten do not care where the model runs. Any supplier who answers all ten with "it is on-premise" has not read the list.

The minimum for a thirty-person organisation

• Authenticate every user; no shared accounts on the assistant
• Enforce document permissions at retrieval, not in the prompt
• Validate any output that another system will act on
• Keep tool and integration permissions to the narrowest set that works
• Record which model version is running, and where it came from
• Protect the index and the logs like the documents they contain
• Decide, in writing, which answers need a human check before they leave the company

NIST's AI Risk Management Framework sits above this as the lifecycle view. It is “intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems”. OWASP tells you what can go wrong in the application; NIST tells you how to organise the work of preventing it.