Securing LLM — OWASP Top 10
The ten critical risks in AI applications and how to defend against them

Why LLM security is different from regular security

LLM-based applications present a new attack surface that traditional application security doesn't cover. Three main reasons: the model is non-deterministic (the same input can produce different outputs), instructions and data share a single channel (everything is text in the same context window — so it's hard to separate a "command" from "data"), andagents can take actions in the real world (read emails, run code, access an API).

To give these risks a common language, the OWASP Gen AI Security project maintains the OWASP Top 10 for LLM Applications — a list of the ten most critical risks. The 2025 edition is the basis for this guide. For each risk we'll explain what it is, a short example, and how to defend against it.

The ten risks at a glance

LLM01 · Prompt Injection

The #1 vulnerability. An attacker injects instructions — directly in the user input, or indirectly through external content the model reads (a web page, PDF, email, tool/MCP description) — and makes the model bypass the developer's instructions. In AI agents with tool access this leads to malicious actions being performed.

Defense: An instruction hierarchy, separating instructions from data, least-privilege permissions for tools, human-in-the-loop for dangerous actions. The full, in-depth Prompt Injection guide → · Related: Jailbreak.

LLM02 · Sensitive information disclosure

The model exposes PII, secrets, keys or proprietary information — through the output, through stored training data, or through context that leaked between users. Example: a chatbot that returns another customer's details because the information got into the context.

Defense: Data minimization, filtering and sanitizing the output, context-based access control, and don't put secrets in the prompt.

LLM03 · Supply Chain

Models, datasets, plugins, adapters and LoRAs from third parties may be poisoned or vulnerable. A model downloaded from an untrusted repo may contain a backdoor.

Defense: Provenance verification, signatures, an "SBOM for models", vetting components before integration, and version pinning.

LLM04 · Data and model poisoning

An attacker contaminates training, fine-tuning or RAG sources to bias the model's behavior or plant hidden triggers. In RAG systems, a poisoned document that enters the index can affect future answers.

Defense: Vetting sources, anomaly monitoring, maintaining data integrity, and isolating untrusted sources.

LLM05 · Improper Output Handling

One of the common mistakes: treating the model's output as trusted. If you inject output directly into HTML, an SQL query or a shell — you create XSS, SQL Injection or even RCE vulnerabilities. The output is untrusted input for the next system in the chain.

Defense: Context-based encoding/escaping, validating the output, and don't run model output directly without a sandbox.

LLM06 · Excessive Agency

An agent that was given too many permissions, tools or autonomy. When combined with indirect injection, you get a "confused deputy" — the agent uses its permissions on the attacker's behalf. This is the vector behind the 2026 RCE incidents in agentic coding tools.

Defense: The least-privilege principle, minimal, well-defined tools, an allowlist for actions, and human approval for destructive actions. The full AI agent security guide →

LLM07 · System Prompt leakage

The system prompt can almost always be extracted (prompt leaking). The mistake is relying on its secrecy or storing secrets/keys/permission logic in it.

Defense: Assume the prompt will leak. Don't put secrets in it, and enforce permissions on the server side — not in the prompt.

LLM08 · Vector and Embedding Weaknesses (RAG)

In RAG systems: inverting embeddings to reconstruct the original text, cross-tenant leakage when there's no isolation, and poisoned vectors in the index. One tenant's query may retrieve another tenant's documents.

Defense: Tenant isolation, access control at the retrieval stage, and validating content that enters the index. Related: RAG guide.

LLM09 · Misinformation

The model produces self-confident but incorrect content (hallucinations), and users rely on it without checking. In sensitive contexts (medical, legal, financial) this is a real risk.

Defense: Grounding (grounding/RAG) with source citation, human verification, and presenting uncertainty instead of fabrication.

LLM10 · Unbounded Consumption

Attacks that exploit the cost of inference: "Denial-of-Wallet" (flooding with expensive requests), resource exhaustion, and model extraction through a large number of queries.

Defense: Rate limiting and quotas, cost monitoring, limiting input/output size, and detecting anomalous usage patterns.

A secure architecture for LLM

Good defense is defense in depth — no single layer is enough. Here's what a secure request flow looks like, with controls at every trust boundary:

Additional layers: canary tokens to detect leaks, secrets management, and a second guard model (dual-LLM) to check input/output.

Red Teaming and Evaluation

LLM security is an ongoing process, not a one-off check. Build a test suite that covers all ten risks, measure Attack Success Rate (ASR), and run regression after every model or prompt change. Combine automated tests with human review, and monitor in production.

LLM security checklist