Large Language Models (LLMs) and Generative AI are being built into products, customer support, internal tools and developer workflows at remarkable speed. But these systems introduce a new class of security risks that traditional application security testing was never designed to catch — a chatbot can be tricked into revealing confidential data, an AI agent can be manipulated into taking unauthorised actions, and a poisoned model from a public hub can quietly compromise an entire pipeline.

To help teams secure these systems, the Open Worldwide Application Security Project (OWASP) maintains the OWASP Top 10 for LLM Applications — the industry-standard list of the most critical security risks in LLM and Generative AI applications. This guide explains each of the 2025 risks in plain language, with practical defences you can apply today.

The OWASP Top 10 for LLM Applications is a community-driven list of the ten most important security risks specific to applications that use Large Language Models. It gives developers, security teams and leaders a shared vocabulary for understanding how LLM-powered systems fail — and a prioritised starting point for testing and hardening them. It complements, rather than replaces, the classic OWASP Top 10 for web applications: you still need to secure the software around your AI, and now you also need to secure the model and its behaviour.

Prompt injection is the number-one LLM risk. An attacker crafts input that overrides the model's instructions — directly (typing a malicious prompt) or indirectly (hiding instructions inside a document, web page, email or tool output the model later reads). Successful prompt injection can make a model ignore its guardrails, leak data, or trigger harmful actions through connected tools.

LLMs can reveal information they should not — personal data (PII), credentials, proprietary business data, or other users' inputs. This happens through over-broad context, inadequate output filtering, or training on sensitive data. The result can be a privacy breach under DPDP, GDPR or sector regulation.

AI applications depend on third-party models, datasets, libraries and hosting platforms. A compromised or maliciously crafted model from a public hub, a tampered dataset, or a vulnerable dependency can backdoor your application. Provenance, integrity verification and vetting of AI components are essential.

If an attacker can influence training or fine-tuning data, they can introduce bias, backdoors or vulnerabilities into the model itself — a poisoning attack. This is especially dangerous when models are continuously fine-tuned on user-supplied or scraped data without validation.

Treating model output as trusted is dangerous. If an application passes LLM output straight into a browser, database, shell or downstream system without validation, it can lead to cross-site scripting (XSS), SQL injection, server-side request forgery (SSRF) or remote code execution. All model output should be treated as untrusted user input.

As LLMs are given tools, plugins and the ability to act (AI agents), excessive agency becomes a serious risk: too much functionality, too many permissions, or too much autonomy means a manipulated model can take damaging, irreversible actions. Limit what agents can do, and require human approval for high-impact operations.

The system prompt that configures an LLM often contains instructions, business logic or even secrets. If it can be extracted by an attacker, it exposes how the system works and may reveal credentials or bypass routes. Never rely on the system prompt to keep secrets, and test whether it can be leaked.

Retrieval-Augmented Generation (RAG) and other systems that use vectors and embeddings introduce their own risks — poisoned or manipulated embeddings, data leakage across tenants, and access-control failures in the vector store. As RAG becomes the default pattern, securing the retrieval layer is critical.

LLMs can produce confident but false output (hallucinations). When applications and users over-rely on this output for decisions — legal, medical, financial or operational — the consequences can be severe. Mitigations include grounding responses in trusted sources, human oversight and clear communication of limitations.

LLMs are resource-intensive. Without limits, attackers can drive excessive inference (denial-of-wallet), extract the model through repeated queries, or cause denial of service. Rate limiting, quotas, monitoring and spend caps protect both availability and cost.

Securing AI is not a one-time task — it spans the model, the data, the application and the agents around it. A practical programme combines hands-on testing with governance:

Knowing the risks is the first step; proving your AI is resilient against them is the next. The most effective way to do that is an independent AI/LLM security assessment that red-teams your application against the OWASP LLM Top 10 and MITRE ATLAS, then maps remediation to recognised AI governance frameworks. This pairs naturally with traditional penetration testing (VAPT), which secures the software and infrastructure around your AI — most AI products need both.

The OWASP Top 10 for LLM Applications gives every team building with AI a clear, prioritised map of what can go wrong — from prompt injection and data leakage to excessive agency and supply-chain risk. Treat it as a baseline: test against all ten, harden the model and the software around it, and back it with AI governance. Do that, and you can adopt AI quickly without taking on hidden risk.