The OWASP LLM Top 10 (2025): A Practical Guide for Security Teams

LLM01, Prompt Injection, remains the top risk because it is the most broadly applicable and the hardest to fully mitigate. Every LLM application that processes untrusted input is exposed. Direct prompt injection targets user-facing input fields; indirect prompt injection embeds adversarial instructions in content the LLM retrieves from external sources. The severity scales with the application's capabilities: a chatbot that only generates text has limited blast radius, while an agent with tool access can be weaponized into performing unauthorized actions. Security teams should assess prompt injection resistance for every LLM application, with particular focus on indirect injection vectors in RAG pipelines and agentic workflows.

LLM02, Sensitive Information Disclosure, covers the risk that the LLM reveals confidential data through its responses. This includes system prompt leakage, training data extraction, and the surfacing of sensitive documents through RAG retrieval. The risk is highest in applications that have access to mixed-classification data or that use system prompts containing API keys, internal URLs, or business logic that would benefit an attacker. LLM03, Supply Chain Vulnerabilities, addresses risks from third-party model providers, fine-tuning datasets, plugins, and framework dependencies. Organizations using open-source models, community-contributed plugins, or third-party fine-tuning services inherit supply chain risk that most procurement and vendor management processes are not yet equipped to evaluate.

LLM04, Data and Model Poisoning, covers the corruption of training data or fine-tuning datasets to introduce backdoors, biases, or adversarial behaviors into the model. This is particularly relevant for organizations that fine-tune models on internal data, as the poisoning can occur at the data collection stage. LLM05, Insecure Output Handling, is the risk that downstream systems treat LLM output as trusted input. If an LLM generates a SQL query and the application executes it without validation, the LLM becomes an injection vector for the downstream database. This category bridges traditional application security and LLM security, and it is often the easiest to test and mitigate because standard output validation techniques apply.

LLM06, Excessive Agency, is the risk that an LLM application has more capabilities or permissions than it needs for its intended function. An agent with access to ten tools when it only needs three has seven unnecessary attack surface vectors. This category directly maps to the principle of least privilege and is especially critical for agentic deployments. LLM07, System Prompt Leakage, focuses specifically on the extraction of system prompts through direct user queries or through inference from the model's behavior. System prompts often contain business logic, access control instructions, persona definitions, and sometimes credentials that provide significant advantage to an attacker.

LLM08, Vector and Embedding Weaknesses, covers vulnerabilities in the embedding and retrieval layers, including authorization bypass in vector stores, embedding inversion attacks that reconstruct source text from vectors, and adversarial perturbation of embeddings to manipulate retrieval results. This category is most relevant to RAG-based applications and any system that stores sensitive information in vector form. LLM09, Misinformation, addresses the risk that the LLM generates factually incorrect, misleading, or fabricated information. While hallucination is an inherent property of generative models, the security relevance increases when the output influences decisions in high-stakes domains like healthcare, legal, or financial services.

LLM10, Unbounded Consumption, covers denial-of-service and resource exhaustion attacks. LLM inference is computationally expensive, and an attacker who can trigger unbounded generation, recursive tool calls, or computationally expensive queries can impose significant cost on the application operator. This category also includes denial-of-wallet attacks where the attacker's goal is to inflate API usage costs rather than disrupt availability. Rate limiting, input length restrictions, and output token budgets are standard mitigations.

Not all ten categories carry equal weight for every LLM application. A simple internal chatbot with no tool access and no RAG pipeline faces primarily LLM01 (prompt injection for jailbreaking), LLM02 (system prompt leakage), and LLM09 (misinformation). The attack surface is limited because the application's only capability is text generation. Testing can focus on prompt injection resistance, system prompt extraction, and output quality validation.

RAG-based knowledge assistants add LLM08 (vector and embedding weaknesses) and significantly amplify LLM02 (sensitive information disclosure through document retrieval). The RAG authorization gap, where vector stores retrieve by similarity rather than permission, is the dominant risk. LLM04 (data poisoning) also becomes relevant if the document corpus can be influenced by untrusted sources. Testing should prioritize authorization boundary validation in the retrieval layer and corpus integrity verification.

Agentic deployments activate the full spectrum of risks, with particular emphasis on LLM06 (excessive agency), LLM01 (prompt injection leading to unauthorized tool invocation), and LLM05 (insecure output handling in tool parameter construction). Multi-agent architectures add inter-agent trust boundary evaluation and privilege escalation through agent chains. These deployments require the most comprehensive assessment scope and should not be evaluated using a generic LLM security checklist. The assessment must be tailored to the specific tools, permissions, and data flows of the agent system.

Using the OWASP LLM Top 10 as an assessment framework requires mapping each category to testable controls for your specific application. Start by documenting the application's architecture: what model is used, what data sources feed the context, what tools are available, what permissions those tools have, and who has access to the application. This architectural inventory directly determines which categories are in scope and which are not relevant.

For each in-scope category, define the threat scenarios that matter for your deployment. LLM01 is not a single test; it is a family of attack techniques that must be evaluated against your specific system prompt, tool bindings, and data sources. LLM02 is not just about system prompt extraction; it requires evaluating every pathway through which sensitive data can reach the LLM's context window and every mechanism by which that data can leak through the output. Generic vulnerability scanners will not provide this level of specificity. Manual adversarial testing by practitioners who understand both LLM internals and your application's business context is essential.

Finally, integrate LLM security into your existing development and deployment pipeline. The OWASP LLM Top 10 should inform threat modeling during design, guide security requirements during development, structure the scope of pre-deployment assessments, and define the monitoring and alerting criteria for production. LLM security is not a one-time audit. Models change, prompts evolve, tool integrations expand, and new attack techniques emerge continuously. The framework provides the vocabulary and structure for ongoing risk management, but it only delivers value if it is embedded into operational processes.