Safeguard
AI Security

OWASP Top 10 for LLM Applications: A Practical Walkthrough

OWASP's 2025 LLM Top 10 added three new categories in one revision — here's what changed, why, and concrete mitigation patterns for each risk.

Safeguard Research Team
Research
7 min read

On November 18, 2024, the OWASP GenAI Security Project shipped version 2.0 of its Top 10 for LLM Applications — and it wasn't a light edit. Three categories from the original 2023 list disappeared entirely, replaced by System Prompt Leakage, Vector and Embedding Weaknesses, and Unbounded Consumption (an expansion of the old Model Denial of Service entry). The project itself has outgrown its name too: what launched in 2023 as a small band of security practitioners is now the OWASP GenAI Security Project, led by Steve Wilson with co-leads Ads Dawson, John Sotiropoulos, Scott Clinton, and Sandy Dunn, and it now counts roughly 600 contributors spread across 18-plus countries, with a wider community pushing toward the 8,000 mark. That churn matters for anyone building an LLM Top 10 checklist into a security program in 2026: a control mapped to the 2023 numbering — say, "LLM03: Training Data Poisoning" — now lives under a different ID and a broader definition ("LLM04: Data and Model Poisoning"). This post walks through the current (2025 / v2.0) ten categories, with a real incident behind each one and a concrete mitigation pattern you can actually implement, not just a policy statement to file away.

What is prompt injection, and why is it still LLM01?

Prompt injection is the act of crafting input — direct or indirect — that overrides an LLM's intended instructions, and it has held the number-one slot in both the 2023 and 2025 OWASP lists because no framework has fully solved it. The distinction that matters operationally is direct versus indirect: a user typing "ignore previous instructions" is direct; a support bot that summarizes an inbound email containing hidden instructions in white-on-white text is indirect. Security researchers Kai Greshake, Sahar Abdelnabi, and colleagues formalized indirect prompt injection in a 2023 paper, "Not What You've Signed Up For," showing that any LLM app which ingests untrusted third-party content — web pages, PDFs, emails — inherits an injection surface even if user input itself is clean. Mitigation in practice means treating retrieved content the same way you'd treat user input in a SQL query: segregate it with explicit delimiters, strip or flag embedded instruction-like text before it reaches the model context, and never let a single LLM call both read untrusted content and take an action (like sending an email) in the same turn without a human or policy checkpoint in between.

How does sensitive information disclosure happen without a breach?

Sensitive information disclosure (LLM02 in the 2025 list) happens when an LLM app leaks data it was never supposed to expose — training data memorization, an over-permissive RAG index, or simply an employee pasting secrets into a prompt. The clearest public case is Samsung's: in April 2023, engineers reportedly pasted proprietary source code and meeting notes into ChatGPT to debug and summarize it, and because OpenAI's consumer product could retain conversation data for training at the time, Samsung banned generative AI tools company-wide within weeks. The mitigation pattern has two layers: data-loss-prevention controls at the prompt boundary (block secrets, credentials, and classified content before they leave your network to a third-party API), and strict retrieval-scoping on the model side — RAG pipelines should enforce the same row- and document-level access controls as the underlying data store, so a user's query can never retrieve chunks they wouldn't have read access to directly.

What makes the LLM supply chain different from a normal software supply chain?

The LLM supply chain adds an entirely new artifact class — model weights, fine-tuning datasets, and embedding indexes — on top of the usual packages and containers, and OWASP elevated this to LLM03 in the 2025 revision specifically because weights are opaque in a way source code isn't. Mithril Security demonstrated the risk directly in July 2023 with "PoisonGPT": they surgically edited a small number of layers in an open-source GPT-J model to inject false facts, re-uploaded it to Hugging Face under a name resembling a trusted publisher (EleutherAI), and showed it passed standard benchmark evaluations undetected. Nothing in a typical CI pipeline — no SAST, no dependency scanner — would catch a backdoored .bin or .safetensors file, because the payload lives in floating-point weights, not source code. The mitigation is provenance, not inspection: verify a signed hash for every model artifact against a trusted registry before it loads, and treat an unsigned or unverified model the same way you'd treat an unsigned container image in production — block it.

What counts as "excessive agency" once an LLM can call tools?

Excessive agency (LLM06 in 2025) is what happens when an LLM-powered agent has more permissions, tool access, or autonomy than the task actually requires, so a hallucinated or manipulated decision turns into a real-world action instead of just a bad sentence. The risk grew sharply more concrete once tool-calling and agent frameworks — and later Anthropic's Model Context Protocol, introduced in November 2024 — made it standard for an LLM to invoke external functions: file writes, database queries, outbound API calls, and payments are all now one inference call away in many production agents. The core mitigation is the same principle behind least-privilege IAM: scope each tool integration to the narrowest permission set the agent's task needs, require explicit allow-listing of which tools a given agent or prompt chain may invoke, and log every tool call with the prompt and response that triggered it so an unexpected call — a refund tool invoked from a request that never mentioned a refund — is detectable after the fact, not just theoretically preventable.

How is unbounded consumption different from a normal denial-of-service attack?

Unbounded consumption (LLM10 in 2025, expanded from the original "Model Denial of Service" category) covers not just availability attacks but the fact that LLM inference has a direct, attacker-influenceable dollar cost per request — something a normal web endpoint doesn't have. Researchers Ilia Shumailov, Yiren Zhao, and colleagues described "sponge examples" in a 2021 paper, showing that specially crafted inputs could be engineered to maximize a neural network's energy consumption and latency, degrading availability without ever exceeding a simple rate limit. Against a hosted LLM API, the same idea translates directly into cost: an attacker who can trigger long, expensive completions (or many parallel ones) can run up an inference bill or exhaust GPU capacity meant for legitimate users. Mitigation means enforcing hard per-request and per-session token ceilings, timeouts on generation length, and cost-based rate limiting keyed to authenticated identity rather than raw request count, since a single expensive request can cost as much as a hundred cheap ones.

How Safeguard Helps

Safeguard covers more of this list than a typical AI-BOM tool does, but it's still not a full answer to every category on its own. On the supply chain side, AI-SPM statically inspects model files — Pickle, PyTorch archives, safetensors, GGUF, ONNX — for hidden code-execution payloads before a model is ever loaded, while the AI-BOM tracks model identity, weight provenance, signing status, and runs statistical backdoor tests for trojan triggers and class-level poisoning; together they're built to catch a PoisonGPT-style tampered model before it loads, addressing LLM03/Supply Chain Vulnerabilities and a good chunk of LLM04/Data and Model Poisoning. Load-time policy enforcement blocks unsigned or unverified weights the same way a guardrail policy blocks an unsigned container image in CI. For agentic systems, the AI-BOM validates tool calls against a declared tool surface and flags unexpected ones — the concrete control LLM06/Excessive Agency calls for. The AI Gateway is the piece that reaches into LLM01 and LLM02 territory: its monitor mode already evaluates every prompt, response, and tool call for direct and indirect injection, jailbreak patterns, and PII/secret egress today, though the block/redact enforcement path is rolling out behind a per-tenant flag rather than on by default. What's still on the application side of the line: output sanitization logic specific to your app, and the hard per-request token ceilings that LLM10/Unbounded Consumption calls for — the gateway's per-tenant rate limits help with abuse volume, but they're not the same as a token budget enforced inside your own request path. This list is exactly the map for where to put each remaining control.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.