OWASP LLM Top 10 (2025) and the Agentic Top 10, Explained

The OWASP LLM Top 10 (officially the OWASP Top 10 for Large Language Model Applications) is the standard list of security risks in software built on LLMs: chatbots, copilots, RAG search and AI agents. The 2025 edition reflects two years of real incidents, and it reads very differently from the classic web list. This guide walks through every OWASP LLM Top 10 risk, then covers the newer OWASP Agentic Top 10 for systems where AI can take actions.

If you are looking for the classic web application list (broken access control, injection, misconfiguration), see our OWASP Top 10 2025 guide. This article is about the LLM-specific list.

ID	OWASP LLM Top 10 (2025)	In one line
LLM01	Prompt Injection	Input, direct or hidden in content, changes what the model does
LLM02	Sensitive Information Disclosure	The model or its integrations leak secrets, personal data or internal data
LLM03	Supply Chain	Compromised models, packages, plugins or MCP servers
LLM04	Data and Model Poisoning	Tampered training, fine-tuning or embedding data
LLM05	Improper Output Handling	Model output used unchecked in code, SQL, HTML or shell
LLM06	Excessive Agency	The model has more tools, permissions or autonomy than it needs
LLM07	System Prompt Leakage	Secrets or security logic placed in a system prompt get exposed
LLM08	Vector and Embedding Weaknesses	RAG stores leak across users or get poisoned
LLM09	Misinformation	Confident, wrong output that people or systems act on
LLM10	Unbounded Consumption	No limits on usage, leading to runaway cost or denial of service

The OWASP LLM Top 10, risk by risk

LLM01: Prompt Injection

Prompt injection is the top OWASP LLM Top 10 risk because there is no complete fix. A language model cannot reliably tell instructions from data, so text that reaches it can steer it. Direct injection comes from the user ("ignore your previous instructions"). Indirect injection hides in content the model reads: a web page, an email, a PDF, a code comment, a tool result, or an AI rules file in a repository. Indirect injection is the dangerous one, because the attacker never talks to your app at all.

Defenses: treat all model input as untrusted, keep untrusted content clearly separated from instructions, limit what the model can do (see LLM06), require human approval for consequential actions, and scan the files your agents load for hidden instructions. Rules files such as CLAUDE.md, AGENTS.md and .cursorrules are a growing target, because agents load them as trusted instructions.

LLM02: Sensitive Information Disclosure

Models leak what they can see. That includes personal data in training or retrieval sets, secrets pasted into prompts, and API keys shipped to the browser so a frontend can call an LLM directly. A common real-world version: an OPENAI_API_KEY exposed through a public environment variable prefix, which anyone can lift from the JavaScript bundle.

Defenses: keep provider keys on the server, scrub personal data before it reaches prompts or vector stores, scope what retrieval can return per user, and treat hardcoded secrets in AI configs as seriously as in code.

LLM03: Supply Chain

LLM apps pull in models from hubs, fine-tuning adapters, Python packages, and increasingly MCP servers and agent plugins. Any of them can be malicious or compromised. Loading a model with trust_remote_code=True runs whatever code the model repository contains; torch.load without weights_only=True can execute code hidden in a pickle file; an unpinned MCP server updates itself to whatever was published last. See MCP security for the agent tooling side.

Defenses: pin versions, prefer safe formats such as safetensors, avoid remote code execution flags, keep an inventory of every model and AI dependency (an AI bill of materials), and review additions like any other dependency.

LLM04: Data and Model Poisoning

If attackers can influence training, fine-tuning or embedding data, they can plant backdoors or biases that trigger later. For most teams this shows up in RAG: anyone who can edit a wiki page, upload a document or post a support ticket that gets indexed can put text in front of your model.

Defenses: control and log what gets indexed, keep provenance for training and retrieval data, and test models for unexpected behavior on trigger phrases.

LLM05: Improper Output Handling

This is classic injection with a new source. If model output goes into eval, a shell command, a SQL query or raw HTML, a prompt injection becomes code execution, SQL injection or XSS. Agents that generate and run code are the extreme case.

Defenses: treat output as untrusted user input, validate it against an expected schema, encode it for the context it is used in, and run generated code only in a sandbox.

LLM06: Excessive Agency

Excessive agency means the model can do more than the task needs: a support bot with write access to the database, an agent tool that runs arbitrary shell commands, or editor settings that auto-approve every agent action for the whole team. When a prompt injection lands, agency decides how much damage it does.

Defenses: give each tool the narrowest permission that works, prefer specific tools over general ones ("create ticket" rather than "run SQL"), and keep a human approving destructive or external actions.

LLM07: System Prompt Leakage

System prompts leak, often with a single question. The risk is not the prompt itself but what teams put in it: API keys, internal URLs, or rules that are supposed to enforce security ("never show other customers' data"). Security that lives only in a prompt is not security.

Defenses: keep secrets out of prompts, enforce authorization in code, and assume users can read your system prompt.

LLM08: Vector and Embedding Weaknesses

RAG systems store embeddings of your documents. Without per-user access control in retrieval, one customer's question can surface another customer's data. Shared vector stores can also be poisoned (see LLM04).

Defenses: filter retrieval by the requesting user's permissions, partition stores by tenant, and validate what gets embedded.

LLM09: Misinformation

Models produce fluent, confident errors, including package names that do not exist. Attackers register those hallucinated names ("slopsquatting") so that developers who trust an AI suggestion install malware.

Defenses: ground answers in retrieved sources, show citations, verify packages before installing, and keep humans reviewing high-stakes output.

LLM10: Unbounded Consumption

Without rate limits, quotas and input size caps, an LLM endpoint is an expensive denial-of-service target and an easy way to run up your provider bill ("denial of wallet").

Defenses: rate-limit per user and per key, cap input and output tokens, set budget alerts with your provider, and keep provider keys off the client.

The OWASP Agentic Top 10

In late 2025 OWASP published a companion list for agentic applications, systems where AI plans and takes actions with tools. The OWASP Agentic Top 10 (often written ASI01 to ASI10) overlaps with the OWASP LLM Top 10 but focuses on what goes wrong when models act autonomously:

ID	Agentic risk	Example
ASI01	Agent Goal Hijack	Hidden instructions in a rules file or web page redirect the agent's task
ASI02	Tool Misuse and Exploitation	An auto-approved tool deletes data or runs commands
ASI03	Identity and Privilege Abuse	Agents run with long-lived, over-scoped credentials
ASI04	Agentic Supply Chain Vulnerabilities	An unpinned MCP server or plugin ships a malicious update
ASI05	Unexpected Code Execution	An agent hook or instruction pipes a remote script to a shell
ASI06	Memory and Context Poisoning	Hidden comments or encoded payloads planted in agent context
ASI07	Insecure Inter-Agent Communication	Tool calls over plain HTTP that can be read or modified
ASI08	Cascading Failures	One agent's bad output propagates through a multi-agent pipeline
ASI09	Human-Agent Trust Exploitation	Users approve actions because the agent sounds confident
ASI10	Rogue Agents	Agents acting outside their intended scope without detection

The practical lesson of the agentic list: agentic AI security risks live in configuration as much as in code. Agent settings, MCP configs and rules files committed to a repo decide what every developer's agent is allowed to do.

Applying the OWASP LLM Top 10 to your codebase

Several OWASP LLM Top 10 risks show up as concrete patterns in source code and config, which means they can be caught before they ship:

• LLM01: hidden Unicode (tag characters, bidirectional overrides, zero-width characters), hidden HTML comments and encoded payloads in agent instruction files; user input concatenated into a system prompt.
• LLM02: AI provider keys in public environment variables, LLM clients running in the browser, secrets in MCP configs.
• LLM03: unpinned MCP packages, vulnerable mcp-remote versions, trust_remote_code=True, unsafe torch.load.
• LLM05: model output passed to eval, exec or a shell.
• LLM06: agent tools that run shell commands, auto-approved tools, AI CLIs run with approvals disabled in CI.

Others (poisoning, misinformation, unbounded consumption) depend on runtime behavior and data, and need testing, monitoring and process rather than static checks.

How Scanverra maps to the OWASP LLM Top 10

The Scanverra Repo Scanner includes an AI security engine whose findings are tagged with both an OWASP LLM Top 10 category and an OWASP Agentic category. It covers the code-level patterns listed above for LLM01, LLM02, LLM03, LLM05 and LLM06, plus the configuration side of the agentic list (ASI01 to ASI07): poisoned agent instructions, risky agent settings and hooks, MCP server configs, and AI usage that is not covered by a policy. It also builds an inventory of the AI providers, models and MCP servers your code uses. You can run it from the dashboard, in the CLI with SARIF output for CI, or in VS Code.

Where it stops: static analysis cannot test a model's behavior. It will not tell you whether your chatbot can be jailbroken, whether your RAG store leaks across tenants (LLM08), or whether your model is poisoned (LLM04). Use red-teaming and runtime monitoring for those, and use static checks to keep the preventable mistakes out of your repo.

Where to start

If you only do three things from the OWASP LLM Top 10: keep provider keys and secrets out of client code and configs, cut agent permissions to the minimum and keep a human approving real actions, and pin every model, package and MCP server you depend on. Then work down the list.