OWASP LLM Security Testing: Top 10 Risks Guide (July 2026)

Prompt injection, excessive agency, system prompt leakage, poisoned vector stores, these aren't failure modes that map cleanly onto anything in traditional OWASP guidance. They're behaviors that surface from how LLM applications actually work at runtime, and they require their own testing framework. The OWASP Top 10 for LLM applications is the closest thing the industry has to a shared standard for OWASP LLM security testing, and the 2025 revision is meaningfully different from the 2023 original. This guide covers what changed, what each vulnerability category actually means in practice, and how to structure your testing program around it.

TLDR:

• Static code analysis and CVE scanning miss LLM vulnerabilities because attacks arrive at inference time through prompts, retrieved content, and tool responses.
• The 2025 OWASP update added three new entries: Unbounded Consumption, System Prompt Leakage, and Vector and Embedding Weaknesses, reflecting RAG and agentic architectures.
• Agentic systems require session-level security testing, not single-turn evaluation, because prompt injection propagates across every tool call an agent makes.
• OWASP test results map directly to EU AI Act Article 9 and Article 15 obligations, producing evaluation records auditors inspect during conformity assessments.
• Openlayer covers all ten OWASP LLM risk categories across pre-deployment evaluation and production monitoring, enforcing controls at the API boundary and logging each flagged inference automatically.

Why LLM applications require a dedicated security framework

Traditional application security was built for deterministic systems. A web app either returns a 200 or it doesn't. A SQL query either executes or it fails. LLM applications break that contract entirely.

LLM outputs are probabilistic, context-sensitive, and shaped by whatever a user feeds into the prompt at runtime. That means the attack surface changes with every inference call. The same application that returns a helpful response to one input might leak system prompt contents, fabricate citations, or execute unintended tool calls given a slightly different input. Static code analysis and CVE scanning miss all of it.

There are three structural properties of LLM applications that make standard security frameworks insufficient.

• Inputs are unbounded and user-controlled at inference time, not at deploy time. There is no fixed schema to validate against. A prompt injection can arrive dressed as a user question, a document upload, a retrieved chunk from a vector store, or a response from a third-party API the application trusts.
• The model itself is a dependency with opaque internals. Unlike a library with a known call signature, a model can behave differently across temperature settings, context window positions, and prompt phrasings in ways that are difficult to predict or catalog in advance.
• LLM applications increasingly take actions beyond producing text. Tool calling, code execution, database writes, and multi-agent handoffs mean that a compromised reasoning step can propagate into real-world consequences before a human ever sees the output.

The OWASP LLM Top 10 exists because these failure modes needed a shared taxonomy. Security teams needed names for the vulnerabilities, threat models built around prompt-based attack vectors, and testing criteria that map to how LLM applications actually behave at runtime. The list gives practitioners a structured starting point where none existed before.

What is the OWASP Top 10 for LLM applications

The OWASP LLM Top 10 framework is a security framework published by the Open Worldwide Application Security Project, built for AI systems running on LLMs. Where traditional OWASP guidance covers web application vulnerabilities like SQL injection and broken authentication, this list targets the attack surfaces that appear when you wire an LLM into a product: prompt manipulation, training data poisoning, insecure plugin chains, and more.

The framework was first released in 2023 and has been updated as the threat surface has matured. It does not replace existing OWASP guidance. It sits alongside it, covering the layer of risk that is native to generative model behavior.

There are ten vulnerability categories in total. Each one maps to a distinct failure mode in LLM application architecture, from how inputs are handled before they reach the model to how outputs are consumed downstream. Security teams assessing LLM deployments use the list as a structured checklist: a way to confirm that each class of risk has been reviewed and tested, including the ones that fall outside prior web security experience.

Why It Matters for Security Testing

Most LLM application vulnerabilities do not look like traditional bugs. They are behavioral failures: a model that follows a user's instruction to ignore its system prompt, a retrieval pipeline that surfaces confidential documents, an agent that executes unintended actions because its tool-calling interface was not scoped correctly. Standard static analysis and unit testing do not catch these. The OWASP Top 10 for LLM Applications gives security and ML teams a shared vocabulary and a structured scope for the kind of adversarial, behavioral testing these systems actually require.

What changed in the 2025 update

The 2025 OWASP LLM Top 10 update wasn't a cosmetic refresh. OWASP reorganized the list to reflect how LLM attack surfaces had shifted since the original 2023 release, retiring some entries, introducing new ones, and renaming others to better capture what practitioners were actually seeing in production deployments.

Here's what changed across the three main categories:

Retired from the 2023 list

• Overreliance (LLM09:2023) was folded into broader guidance on output validation, recognizing that blind trust in LLM outputs is a symptom of missing controls, not a standalone vulnerability class.
• Training Data Poisoning moved from a dedicated entry to a sub-concern under Supply Chain Vulnerabilities, reflecting that most organizations don't control their training pipelines directly and need to think about it as a vendor risk.

New in the 2025 list

• Unbounded Consumption (LLM10:2025) replaced the older Denial of Service entry with a more precise framing: attackers who exploit LLM inference costs, context window abuse, and resource exhaustion at scale. The new name captures financial and resource risk more accurately.
• System Prompt Leakage (LLM07:2025) was promoted to its own entry after years of documented prompt extraction attacks showed that treating system prompts as a security boundary without enforcement is a consistent failure pattern.
• Vector and Embedding Weaknesses (LLM08:2025) is entirely new, added to account for retrieval-augmented generation architectures where poisoned or manipulated vector stores introduce retrieval-layer attacks that didn't exist in simpler LLM deployments.

Renamed or reframed entries

The through-line across all these changes is architectural maturity. The 2023 list was written when most LLM applications were simple prompt-response wrappers. The 2025 update accounts for RAG pipelines, agentic systems, multi-model supply chains, and the reality that LLM outputs now trigger real downstream actions instead of just returning text.

LLM01 through LLM05: Input, output, and data-layer risks

The first five entries in the OWASP Top 10 for LLM Applications cover the attack surface that sits closest to the model itself: what goes in, what comes out, and how data moves between them.

LLM01: Prompt Injection

Prompt injection occurs when an attacker embeds instructions inside user input that override the system prompt or hijack the model's intended behavior. There are two variants worth distinguishing. Direct injection targets the model through the user-facing input field. Indirect injection is subtler: the model retrieves external content (a webpage, a document, a tool response) that contains embedded instructions, and the model executes them as if they were legitimate.

Testing for prompt injection involves constructing inputs that attempt to:

• Override system-level instructions by embedding conflicting directives in user turns
• Leak the system prompt by asking the model to repeat, summarize, or paraphrase it
• Trigger unauthorized tool calls by framing malicious instructions as retrieved content

LLM02: Sensitive Information Disclosure

LLMs can surface training data, system prompt contents, or contextual data passed at runtime in ways the application never intended. This is not always an adversarial act: a poorly scoped system prompt that includes API keys, internal policy documents, or PII can be extracted through straightforward conversational probing.

Security testing here involves checking whether the model will:

• Reproduce verbatim training data when prompted with partial sequences
• Reveal system prompt contents when asked directly or indirectly
• Surface PII or confidential context injected earlier in the conversation window

LLM03: Supply Chain Vulnerabilities

LLM applications depend on a chain of external components: base models, fine-tuned adapters, embedding models, vector stores, plugins, and third-party APIs. A compromised component anywhere in that chain can introduce backdoors, biased outputs, or data exfiltration paths that are invisible at the application layer.

Testing priorities include:

• Verifying provenance and integrity of base models and fine-tuned weights against known registries
• Auditing third-party plugins and tool integrations for data handling practices and access scope
• Checking whether model cards and documentation accurately reflect training data sources and known limitations

LLM04: Data and Model Poisoning

Poisoning attacks target the training or fine-tuning pipeline, not the deployed model. An attacker who can influence training data can embed persistent backdoors that activate on specific trigger inputs, or degrade model behavior in ways that are hard to detect post-deployment.

Key testing considerations:

• Reviewing data ingestion pipelines for untrusted or unvalidated sources, particularly scraped web content
• Checking whether fine-tuning jobs enforce data provenance tracking and anomaly detection on label distributions
• Validating that model behavior on held-out adversarial test sets is consistent with expected outputs before promotion to production

LLM05: Improper Output Handling

When LLM outputs are passed downstream to other systems without sanitization, the application inherits the model's vulnerability surface. A response containing SQL fragments, shell commands, or HTML can trigger injection attacks in the consuming system if the application treats model output as trusted input.

Testing for improper output handling requires tracing every downstream sink that consumes model output and verifying:

• SQL query construction that includes model output applies parameterized queries, not string concatenation
• HTML output from model responses is sanitized to prevent cross-site scripting
• Shell commands or code execution paths that include model-generated content enforce strict allow-listing

LLM06 through LLM10: Agency, leakage, and resource risks

The final five OWASP LLM vulnerabilities shift focus from what gets into an LLM to what an LLM can do once it's running. These risks involve autonomous action, data exposure, and unchecked resource consumption, and they tend to surface in production, not during development.

Here's how each one breaks down:

• LLM06: Excessive Agency occurs when an LLM is granted more permissions, access, or autonomy than its task requires. An agent connected to a file system, email client, and database simultaneously creates a wide blast radius if it acts on a malformed or adversarially crafted instruction. Principle of least privilege applies here just as it does in traditional systems.
• LLM07: System Prompt Leakage happens when a model reveals instructions that were meant to remain hidden from users. Attackers who recover system prompts gain insight into application logic, persona constraints, and sometimes embedded credentials or API keys.
• LLM08: Vector and Embedding Weaknesses cover vulnerabilities in retrieval-augmented generation (RAG) pipelines, including poisoned document stores, proximity-based retrieval bypasses, and embedding inversion attacks that reconstruct sensitive source text from vector representations.
• LLM09: Misinformation describes the model generating confident, plausible, but factually incorrect outputs. This is distinct from hallucination as a failure mode in that it includes cases where outputs are technically fluent but systematically misleading, particularly in high-stakes domains like legal, medical, or financial contexts.
• LLM10: Unbounded Consumption refers to scenarios where an LLM application consumes compute, memory, or API quota without enforced limits, making it vulnerable to denial-of-service conditions, runaway cost accumulation, or degraded availability for legitimate users.

How to test your LLM application against the OWASP Top 10

Testing against the OWASP Top 10 runs across four phases, each targeting a different layer of the stack.

Phase 1: Model Evaluation

Start by testing the base model in isolation using adversarial prompt sets that cover injection resistance, system prompt leakage, and sensitive data reproduction. A solid prompt injection dataset includes direct override attempts, persona-jailbreak sequences, and indirect injection via crafted retrieval content.

Phase 2: Integration Testing

Once the model passes isolation tests, test the full pipeline with retrieval, tool calls, and agent orchestration active. This is where supply chain and plugin vulnerabilities surface: a malicious document retrieved from a vector store can carry embedded instructions the model executes as if they were system-level directives.

Phase 3: Output and Behavior Validation

Run outputs through automated scoring for groundedness, toxicity, and sensitive data exposure before any response reaches a user. Flag responses when toxicity probability exceeds 0.15, or when groundedness scores fall below 85%.

Phase 4: Production Monitoring

Deploy behavioral baselines during staging and compare live traffic against them continuously. LLM observability for drift in refusal rates, topic distribution, or confidence scores signals that something in the model's behavior has shifted, whether from prompt manipulation at scale or upstream data changes.

Agentic AI and the expanding OWASP attack surface

Agentic AI systems introduce a qualitatively different threat model than single-turn LLM applications. When an LLM can browse the web, execute code, query databases, and trigger downstream API calls autonomously, the blast radius of a successful attack grows considerably. The OWASP Top 10 for LLM Applications was originally scoped around single-inference risks, but the 2025 update explicitly accounts for multi-step agent architectures where vulnerabilities compound across tool calls.

There are a few specific ways agentic systems expand the attack surface worth understanding before applying any testing framework.

Prompt Injection Across Tool Boundaries

In a single-turn LLM, prompt injection is contained to one response. In an agentic system, a malicious instruction injected through a web page, email body, or retrieved document can propagate through every subsequent tool call the agent makes. An attacker who controls a webpage an agent retrieves can instruct that agent to exfiltrate session data, modify calendar entries, or send emails on behalf of the user. OWASP LLM01 (Prompt Injection) and LLM06 (Excessive Agency) interact directly here: the injection succeeds precisely because the agent has been granted more capability than the task requires.

Privilege Escalation Through Chained Calls

Agents that coordinate sub-agents or call privileged APIs create lateral movement opportunities that traditional LLM security testing never needed to model. A low-privilege agent that can invoke a higher-privilege tool effectively inherits that tool's access under the right prompt conditions. Testing for this requires tracing the full call graph, not inspecting individual model outputs in isolation.

Persistent Memory as an Attack Vector

LLM agents with long-term memory stores introduce a persistence layer that static prompt injection does not. An adversarial input written into an agent's memory during one session can influence behavior in future sessions with different users or broader permissions. This maps to OWASP LLM02 (Sensitive Information Disclosure) and LLM06 (Excessive Agency) when the recalled content bypasses controls that would have blocked the original input at inference time.

The practical implication is that agent evaluation for agentic systems requires session-level coverage, going beyond single-turn assessment. Teams need to track what an agent does across a full interaction sequence, including which tools it called, what data it retrieved, and whether its actions stayed within the intended permission boundary.

Mapping OWASP LLM risks to regulatory compliance frameworks

The OWASP LLM Top 10 does not exist in a vacuum. Each vulnerability category maps directly onto obligations imposed by the EU AI Act, NIST AI RMF, and ISO 42001, meaning the security gaps OWASP names are often the exact gaps auditors will inspect.

There are three frameworks worth mapping explicitly.

EU AI Act

High-risk AI systems must satisfy Article 9 risk management requirements and Article 15 accuracy and robustness standards before deployment. Prompt injection (LLM01) and insecure output handling (LLM05) are direct Article 15 failures: a system that can be manipulated into producing unsafe outputs has not met the robustness threshold for high-risk AI systems. Training data poisoning (LLM03) creates Article 9 exposure, since contaminated training data undermines the EU AI Act risk management assessment an organization is required to document and maintain.

NIST AI RMF

The RMF's GOVERN, MAP, MEASURE, and RESPOND functions align tightly with the OWASP list. Sensitive information disclosure (LLM02) falls under MEASURE and RESPOND: teams are expected to test for it, detect it at runtime, and have a documented response plan as part of NIST AI RMF implementation. Excessive agency (LLM06) maps to GOVERN: if an LLM agent can take real-world actions without human oversight, the organization has likely failed to define appropriate control boundaries at the governance layer.

ISO 42001

ISO 42001 requires documented AI risk treatment plans. Supply chain vulnerabilities (LLM05) are a direct fit: third-party model components and external plugins must be inventoried, assessed, and treated as in-scope risks, not assumed safe by default.

The practical implication is that security testing against the OWASP LLM Top 10 generates evidence artifacts that satisfy multiple regulatory obligations simultaneously. A test suite covering prompt injection, data poisoning, and output handling produces more than a security posture report. It produces the evaluation records, failure mode documentation, and risk treatment evidence that EU AI Act conformity assessments require.

Translating OWASP test results into runtime controls

Running OWASP tests in isolation produces a snapshot. What actually reduces risk is converting those findings into controls that run continuously, at inference time, before outputs reach users.

There are three categories of runtime control worth building from your OWASP test results.

Blocking Controls

These sit at the API boundary and reject requests or responses that fail defined thresholds. If your prompt injection tests (LLM01) surface reliable patterns, those patterns become AI guardrails for input filters. If your insecure output handling tests (LLM02) identify response structures that downstream systems misparse, those structures get blocked before delivery. The control fires before harm occurs, not after logging it.

Monitoring and Alerting Controls

Not every risk warrants a hard block. Some findings from your sensitive information disclosure tests (LLM06) or overreliance scenarios (LLM09) are better handled by flagging for human review. Set threshold-based alerts: flag responses when a personally identifiable information classifier scores above 0.85, or when a groundedness score drops below 0.75 on retrieval-augmented queries. These thresholds should trace directly back to what your test suite found acceptable.

Audit Trail Controls

Compliance functions need evidence; dashboards alone are not enough. Each OWASP test category maps to an artifact auditors will ask for: test results, enforcement logs, incident records, and threshold review histories. Structure your logging so that every flagged inference carries the model version hash, the threshold that triggered the flag, and the disposition taken. That record satisfies the EU AI Act technical documentation requirements and closes the loop between a test finding and a demonstrable control.

The practical sequencing matters here. Run your OWASP-aligned test suite before deployment to set baselines. Then configure runtime controls against those baselines. Schedule re-evaluation when the model changes, when the input distribution drifts measurably, or when a new OWASP LLM Top 10 revision publishes. Controls that were never re-validated against a model update are not active controls; they are stale configuration.

How Openlayer supports OWASP LLM security testing

Openlayer maps directly to the OWASP LLM Top 10 across the full model lifecycle, from pre-deployment evaluation through production monitoring, covering all ten risk categories through its unified evaluation, observability, and governance platform, so security and ML teams can test, enforce controls, and maintain audit-ready evidence in a single place.

Here is how the coverage breaks down across the ten risks:

• Prompt injection and jailbreak resistance testing runs as part of Openlayer's pre-deployment evaluation suite. You can configure adversarial prompt datasets, set pass/fail thresholds, and block deployment if injection success rates exceed an acceptable ceiling, for example, flagging any configuration where more than 2% of adversarial prompts elicit a policy-violating response.
• Sensitive information disclosure is caught through output-layer scanning that checks responses for PII patterns, credential fragments, and verbatim training data reproduction before responses reach users. Threshold-based alerts fire when disclosure rates cross a defined floor, such as triggering review if PII leakage probability exceeds 0.05 on any response batch.
• Supply chain and model integrity risks are tracked through Openlayer's model registry, which records training data provenance, dependency versions, and the approval event authorizing each deployment artifact. Every production model carries a version hash traceable to the evaluation record that cleared it.
• Excessive agency and insecure output handling are tested through Openlayer's agent evaluation layer, which scores tool call accuracy, tracks permission scope at each reasoning step, and flags agent paths where output is passed to downstream processes without a validation gate.
• Overreliance and misinformation risks are measured using groundedness and faithfulness metrics scored against retrieved context. You can set a deployment floor, such as blocking any release where groundedness scores fall below 85%, and monitor for drift in production as the model's source material or user queries shift.
• Unbounded consumption is tracked through session-level cost and token metrics across Openlayer's 13 session-level monitoring dimensions, alerting when resource usage patterns suggest runaway inference or denial-of-service conditions.

Across all six areas, Openlayer generates pass/fail records, metric scores, and flagged failure modes that become the evidentiary record auditors review during conformity assessments. Controls are not documented as policy; they are enforced at the API boundary and logged automatically, so the audit trail builds without manual effort.

Final thoughts on LLM application security and the OWASP Top 10

The OWASP Top 10 for LLM applications is not a checklist you complete once and file away. Each category maps to a live failure mode in production systems, and the v2025 update (the current published version as of this writing) reflects real architectural moves toward agentic systems and RAG pipelines that compound those risks considerably. Running the test suite is step one. Turning those results into blocking controls, monitoring thresholds, and audit trail artifacts is what actually reduces risk in production. Get in touch with the Openlayer team to see how that coverage maps to your stack.

FAQ

What is the OWASP Top 10 for LLM Applications and how does it differ from traditional OWASP guidance?

The OWASP Top 10 for LLM Applications is a security framework targeting attack surfaces that arise directly from generative model behavior: prompt injection, training data poisoning, insecure plugin chains, vector store weaknesses, and more. Traditional OWASP guidance covers deterministic web application vulnerabilities like SQL injection and broken authentication, while the LLM list targets the probabilistic, runtime-shaped risks that static code analysis and CVE scanning cannot catch.

How should I test my LLM application against the OWASP Top 10 for LLMs?

Run testing across four sequential phases: model evaluation in isolation using adversarial prompt sets, integration testing with retrieval and tool calls active, output validation against groundedness and toxicity thresholds (flag responses when toxicity probability exceeds 0.15 or groundedness falls below 85%), and continuous production monitoring against behavioral baselines set during staging. Each phase surfaces a different layer of the OWASP LLM risk surface that earlier phases cannot reach.

OWASP LLM security testing vs. general penetration testing: which do I need for an LLM application?

You need both, but they cover different ground. General penetration testing finds infrastructure and API-layer vulnerabilities; OWASP LLM security testing targets behavioral failures like prompt injection, system prompt leakage, and excessive agency that standard pen testing never exercises. For any LLM application with tool-calling or RAG components, OWASP-aligned adversarial evaluation is the layer that actually validates runtime model behavior.

What changed between the 2023 and 2025 OWASP LLM Top 10 lists?

The 2025 update added three entries absent from 2023: Unbounded Consumption (replacing the narrower Denial of Service framing to cover cost and resource abuse), System Prompt Leakage as a standalone category, and Vector and Embedding Weaknesses to account for RAG pipeline attacks. Training Data Poisoning moved from its own entry into Supply Chain Vulnerabilities, and the scope of Prompt Injection expanded to cover indirect injection through retrieved content, beyond direct user input alone.

How does OWASP AI security testing connect to EU AI Act and NIST AI RMF compliance obligations?

Running an OWASP-aligned test suite generates the evidentiary artifacts that both frameworks require. Prompt injection and output handling tests produce robustness records that satisfy EU AI Act Article 15 accuracy and robustness standards; supply chain vulnerability assessments map directly to Article 9 risk management documentation; and sensitive information disclosure tests produce the MEASURE and RESPOND evidence NIST AI RMF expects. A single test run against the OWASP LLM Top 10 can populate compliance records across multiple frameworks simultaneously, without treating security testing and regulatory documentation as separate workstreams.