OWASP LLM Top 10 Explained: Risks, Examples and Controls

An AI answer can contain no malicious instructions and still be unsafe to rely on. OWASP's update on its 2025 LLM risks treats misinformation as a distinct concern alongside security failures. For a lawyer preparing a filing, a doctor reviewing records or an executive approving an action, protecting confidential data doesn't establish that the answer is correct. The OWASP LLM Top 10 is a shared vocabulary for assessing risks in applications built around large language models, covering data, retrieval systems, dependencies, permissions and actions, not just chatbot responses. Our analysis separates what OWASP establishes, what that means operationally, and what the accountable professional still needs to decide. The useful outcome isn't a completed checklist. It's a record showing why a particular application, with particular permissions and limitations, was considered suitable for its intended work.

The OWASP LLM Top 10 is a shared vocabulary for assessing risks in applications built around large language models. It covers the surrounding data, retrieval systems, software dependencies, permissions and actions, not just chatbot responses. A defensible use is to treat it as an awareness framework for threat assessment and evidence collection, rather than as certification that an application is secure. Professional teams should translate each category into a governance decision: who owns the exposure, what verification is required before reliance, which changes need approval, and what uncertainty remains. Technical controls can reduce exposure, but they don't replace professional judgement or establish the truth of an answer.

1. What makes LLM01 (2025) Prompt Injection a governance decision?

Prompt injection is a question of whose instructions an application follows. The OWASP LLM application security document distinguishes direct injection through user input from indirect injection through retrieved documents, web pages, emails and tool responses.

A document can therefore be both evidence to analyse and a vehicle for instructions the application shouldn't follow. The distinction matters when the model can access confidential records or invoke connected tools.

The boundary between a business document and an instruction deserves explicit testing.

Ownership, verification and the unresolved boundary

Our analysis: assign the application owner responsibility for the entire processing path, not merely the prompt box. Say a legal assistant retrieves a contract containing instructions to send the case summary to an external address. Verification should capture attempted tool calls and data access, even if the final answer looks harmless.

• Verify the boundary. Test malicious instructions in uploaded documents, retrieved passages and tool responses.
• Constrain the consequences. Limit tool permissions and require approval before sending, deleting or publishing.
• Retain the evidence. Preserve the input, retrieved context, attempted actions and reviewer decision.

Our guidance on architecture-level prompt injection defence develops this separation between model behaviour and application authority.

The remaining decision: which external content may the application process, and with what authority? Successful tests provide evidence about tested conditions, not proof against every future injection.

The following video provides additional context for reviewing this risk.

2. Who owns LLM02 (2025) Sensitive Information Disclosure?

The data owner should determine what an application may disclose before a model receives the material. OWASP's official application-risk resource places sensitive-information disclosure within an application-wide assessment, rather than limiting responsibility to the model provider.

The practical concern includes confidential information appearing in answers, retrieval results, retained prompts or operational logs. A privacy review therefore needs to follow the information through the workflow, including places users don't ordinarily see.

Confidential records need controls before processing, not just careful wording afterwards.

Test disclosure without using real confidential records

Our analysis: the information-governance lead should coordinate with the application owner. For an occupational-health summary, use synthetic records containing distinctive identifiers, then inspect outbound requests, answers, logs and retrieval results for unintended disclosure.

A proposed workflow change should identify which fields leave the controlled environment, which are masked, and where originals are restored. Independent review should assess whether the remaining context still identifies the individual.

Practical rule: Removing a name doesn't establish that the surrounding narrative is safe to disclose.

The remaining decision: what information is necessary for the task, and what residual exposure is acceptable? Pseudonymisation can reduce exposure, but it doesn't replace a jurisdiction-specific legal assessment or prevent disclosure through overly broad retrieval permissions.

3. What should procurement require for LLM03 (2025) Supply Chain Vulnerabilities?

Procurement needs an inspectable account of the components entering the application and the process for changing them. The OWASP overview of its 2025 framework includes supply-chain risk across development, deployment and management.

The relevant dependencies extend beyond the base model. Embedding services, software libraries, connectors, datasets and hosting arrangements can affect what the application executes and where information travels.

A component inventory is a decision record

Our analysis: give the platform owner responsibility for technical dependencies, with procurement and privacy specialists reviewing their respective exposures. Say a research team adds a document-parsing library to process confidential reports. Review should establish its origin, version, execution behaviour and network access before approval.

• Inventory components. Record models, datasets, libraries, connectors and deployment versions.
• Verify integrity. Check signatures or checksums where available and review formats that can execute code during loading.
• Validate changes. Retest affected workflows after component updates and preserve the approval record.

A subprocessor policy describing third-party subprocessors handling user data is one type of procurement artefact, not evidence about another supplier's arrangements.

The remaining decision: which dependencies are acceptable when upstream visibility is incomplete? An inventory makes exposure inspectable; it doesn't demonstrate that every listed component is trustworthy.

4. How should LLM04 (2025) Data and Model Poisoning change source governance?

Poisoning makes the integrity of incoming material a security responsibility, not merely an editorial preference. OWASP distinguishes this category from ordinary misinformation because manipulated training, fine-tuning or retrieval material can influence subsequent behaviour.

The project's early community framework already included training-data poisoning. The governance implication is to examine how material becomes trusted, not only whether an individual answer appears reasonable.

Review what enters the knowledge base

Say a compliance assistant draws on an internal policy library. Someone inserts an unofficial exception stating that a restricted transaction no longer requires approval, and the assistant later presents that exception as established policy.

Our analysis: the knowledge-base owner should approve sensitive source changes, while an independent reviewer checks whether the revised material supports the intended interpretation. Keep the source version, uploader, approval and affected index entries together.

• Before ingestion. Review provenance, authority and relevance, especially for public or user-submitted material.
• Before release. Test targeted questions and adversarial triggers against the updated collection.
• After discovery. Remove suspect material, rebuild affected indexes where necessary and reassess dependent outputs.

The remaining decision: how much source uncertainty can the workflow tolerate? Sampling and behavioural tests can miss targeted manipulation. A model that behaves normally on routine questions may still fail when a particular topic or trigger appears.

5. Where should LLM05 (2025) Improper Output Handling be controlled?

Control belongs where generated content enters another system. OWASP's improper-output-handling category concerns applications that pass model output onward without appropriate validation, encoding or restriction.

The distinction is between reading a proposed action and executing it. A model-generated database query, shell command or web fragment should be assessed as untrusted input, even when it originated inside an approved application.

Separate a proposal from an executable operation

Our analysis: the integration owner should be accountable for downstream validation. Consider an analyst asking an assistant to update a customer record: the model should propose the intended fields and values, while application code checks the schema, permissions and permitted operation.

A validated change plan should show the target record, proposed changes, applicable constraints and expected result. An independent reviewer can then compare the plan with the original request before a constrained execution step applies it.

A readable explanation is not validation of the command underneath it.

Use parameterised queries, operation allow-lists, output encoding and sandboxed rendering where appropriate. Preserve the approved plan and the actual execution result so reviewers can identify differences.

The remaining decision: which operations may proceed automatically after validation? Schema checks can establish structure and permitted values, but they don't establish that the proposed business change is factually justified or professionally appropriate.

6. What authority is justified under LLM06 (2025) Excessive Agency?

An application should receive only the authority its task requires. OWASP's excessive-agency entry identifies excessive functionality, excessive permissions and excessive autonomy as recurring causes of damaging actions.

The trigger needn't be an attack. An ambiguous request, mistaken output or compromised connected component can become consequential when the application has permission to act.

Approval should show the proposed action, not merely a reassuring summary.

Give the workflow owner responsibility for authority

Our analysis: a communications assistant that drafts correspondence doesn't automatically need permission to send it. The workflow owner should justify each tool, separate read access from write access, and identify actions that require explicit approval.

• Verify permissions. Attempt prohibited actions using the application's actual runtime identity.
• Review the operation. Display recipients, attachments and proposed changes before approval.
• Keep an audit trail. Record tool calls, approval decisions and execution outcomes.

Our explanation of least-privilege runtime control for AI agents addresses this distinction between a behavioural instruction and an enforceable restriction.

The remaining decision: how much autonomy is justified by the task's reversibility and impact? Human approval can reduce exposure, but a rushed reviewer may approve an incorrect action. Independent review is more useful when the reviewer can inspect the underlying operation and supporting evidence.

7. Why isn't secrecy enough for LLM07 (2025) System Prompt Leakage?

A hidden prompt shouldn't carry the burden of enforcing access control. OWASP treats system-prompt leakage as a distinct risk because exposing internal instructions can reveal application behaviour and other information placed in the prompt.

The governance concern isn't that someone might copy the wording. It's whether the organisation has made security depend on instructions remaining undisclosed or being obeyed consistently.

Design controls that survive disclosure

Say an internal assistant's prompt describes approval thresholds and tells the model not to show restricted records. Our analysis: the application-security owner should verify that the retrieval service independently enforces those restrictions.

Keep credentials and secrets outside prompts. Place authorisation checks in application code and infrastructure, then test whether requests remain blocked when the user knows the intended workflow and policy wording.

Assume a determined user may learn the instructions. Assess whether the application remains appropriately restricted.

Independent review should examine both prompt-extraction tests and the controls outside the model. A validated configuration change should identify whether new instructions expose business logic or accidentally introduce sensitive values.

The remaining decision: which internal instructions can be tolerated becoming visible? Extraction testing can reveal weaknesses, but unsuccessful attempts don't prove secrecy. The stronger evidence is that disclosure wouldn't grant additional access or authority.

8. Who verifies isolation for LLM08 (2025) Vector and Embedding Weaknesses?

The retrieval-system owner should verify access at retrieval time, before documents enter the model's context. OWASP's vector-and-embedding category addresses weaknesses in systems that use embeddings to retrieve material for generated answers.

For professional knowledge bases, relevance and authorisation are separate questions. A passage may match a query closely while belonging to a different client, patient, department or confidential matter.

Test the retrieval result, not just the answer

Consider a notarial practice using retrieval-augmented generation across client files. Our analysis: testing should attempt cross-client retrieval with realistic document similarities, then inspect the returned document identifiers and passages.

An answer that omits restricted text doesn't establish that the retrieval layer withheld it. Reviewers need evidence from the retrieval boundary itself.

• Enforce permissions. Apply user, tenant and document restrictions to each retrieval operation.
• Govern indexing. Review documents and metadata before indexing, with controlled updates.
• Inspect access. Retain sufficiently protected logs to investigate unexpected retrieval without creating an unnecessary duplicate confidential archive.

Changes to filters, indexes or embedding services should undergo regression testing before release. Independent review should include denied-access cases, not merely examples that retrieve the expected answer.

The remaining decision: does the confidentiality model justify separate indexes or environments? Segmentation can reduce shared exposure, but it doesn't correct inaccurate permissions or establish that retrieved content is true.

9. What evidence is sufficient for LLM09 (2025) Misinformation?

Evidence should be sufficient for the claim's intended use, not merely sufficient to make the answer plausible. OWASP's misinformation category recognises false, misleading and unsupported output as a risk in its own right.

Security testing and factual verification answer different questions. An application may respect access restrictions and produce a professionally unusable answer because its sources don't support its conclusion.

Verification needs a traceable connection between each consequential claim and its evidence.

Keep disagreement visible

Our analysis: assign the final professional reviewer ownership of reliance. For a legal memorandum, verify that each cited authority exists, supports the proposition, applies in the relevant jurisdiction and remains suitable for the question.

Independent model review can identify contradictions, missing qualifications and unsupported assertions. It isn't independent evidence when reviewers repeat the same mistaken premise or rely on the same unsuitable source.

Our guidance on practical AI hallucination detection distinguishes checking an answer from accepting its fluency.

The remaining decision: should an unresolved claim be qualified, escalated or excluded? Preserve source dates, reviewer objections and unresolved disagreements in the verification trail. Agreement among models can support review, but it doesn't establish correctness or transfer responsibility away from the professional using the result.

10. What limits are appropriate for LLM10 (2025) Unbounded Consumption?

The service owner should set enforceable resource limits before deployment. OWASP's unbounded-consumption category covers uncontrolled resource use, cost and service-availability exposure.

For governance purposes, the issue includes legitimate workflows that expand unexpectedly as well as deliberate abuse. A document review can become expensive if the application repeatedly retrieves material, retries failed operations or continues an agent loop.

Cost visibility should support a decision about how much processing a task warrants.

Budget the complete workflow

Our analysis: technical operations and the budget owner should agree limits together. For an investigative research task, define input size, output allowance, retrieval scope, permitted tool depth and stopping conditions before enabling extended processing.

• Enforce ceilings. Apply server-side rate, token, step and spending limits.
• Test termination. Verify that loops, retries and failed tools stop predictably.
• Preserve visibility. Record resource use by workflow and processing stage.

Independent review should check whether proposed limits leave enough capacity for meaningful verification. A validated change plan should identify when additional review depth increases resource use.

The remaining decision: what happens when the limit is reached? Pausing for approval may be more defensible than returning an incomplete answer without notice. Resource caps reduce exposure, but an overly restrictive cap can leave important claims unchecked, so the resulting limitation should remain visible.

Where Each LLM Risk Enters the Workflow and Where Controls Start

• LLM01:2025 Prompt Injection — Where the Risk Enters: User input or retrieved and uploaded content; Main Consequence: Instructions are overridden, potentially exposing data or triggering actions; Priority Control: Treat external content as untrusted; restrict tools and require approval for consequential actions
• LLM02:2025 Sensitive Information Disclosure — Where the Risk Enters: Prompts, outputs, logs, training data, or retrieval systems; Main Consequence: Personal or confidential information is exposed; Priority Control: Classify and pseudonymise data; enforce least-privilege access
• LLM03:2025 Supply Chain Vulnerabilities — Where the Risk Enters: Models, datasets, plug-ins, libraries, and hosting providers; Main Consequence: Compromised components introduce malicious behaviour or vulnerabilities; Priority Control: Inventory and verify components; reassess them after updates
• LLM04:2025 Data and Model Poisoning — Where the Risk Enters: Training, fine-tuning, or retrieval data; Main Consequence: The model learns false, biased, or backdoored behaviour; Priority Control: Track data provenance; review data and test for trigger behaviours
• LLM05:2025 Improper Output Handling — Where the Risk Enters: Model output passed to browsers, databases, interpreters, or APIs; Main Consequence: Executed or rendered output causes injection, code execution, or data changes; Priority Control: Validate and encode outputs; use parameterised queries and sandboxing
• LLM06:2025 Excessive Agency — Where the Risk Enters: Tool permissions, functions, and autonomous actions; Main Consequence: Flawed or manipulated outputs cause harmful real-world actions; Priority Control: Apply least privilege; require human approval for consequential actions
• LLM07:2025 System Prompt Leakage — Where the Risk Enters: Hidden system instructions exposed through model responses; Main Consequence: Internal rules or architecture are revealed, enabling bypasses; Priority Control: Keep secrets out of prompts; enforce security controls outside the model
• LLM08:2025 Vector and Embedding Weaknesses — Where the Risk Enters: Vector stores and retrieval queries; Main Consequence: Users access unauthorised documents or source information leaks; Priority Control: Enforce permissions on every retrieval; segment stores where needed
• LLM09:2025 Misinformation — Where the Risk Enters: Generated answers, citations, and claims; Main Consequence: False or unsupported content is relied on in professional work; Priority Control: Verify claims against sources; assign a professional to review final content
• LLM10:2025 Unbounded Consumption — Where the Risk Enters: Requests, agent loops, and repeated model queries; Main Consequence: Excessive costs, service disruption, or model extraction; Priority Control: Set rate, token, and spending limits; cap agent steps

What should a decision-maker ask for before deploying LLM applications?

Ask for evidence that the application's authority, information access and outputs are controlled for its intended use. A policy statement or a favourable demonstration isn't equivalent to a tested workflow with named owners, documented exceptions and an explicit acceptance of remaining uncertainty.

The OWASP GenAI Security Project provides a common taxonomy for organising risks across engineering, security and governance. Our analysis is that its greatest practical value comes when teams connect that vocabulary to inspectable decisions rather than treating category coverage as a security verdict.

Require a deployment decision record

Start with an inventory of models, data sources, retrieval stores and connected tools. Identify who can change them, which versions were tested, and which changes trigger reassessment.

Then request a concise evidence package:

• Named ownership. Identify an accountable owner for each relevant risk and the person authorised to accept residual exposure.
• Least-privilege access. Show the runtime permissions, retrieval restrictions and separation between read and write operations.
• Documented testing. Retain injection, disclosure, isolation and output-handling cases, including failures and remediation.
• Human approval. Identify irreversible or external actions that require approval and show what the reviewer sees.
• Verification history. Preserve claims checked, sources consulted, reviewer disagreements, corrections and unresolved uncertainty.
• Operational limits. Document resource ceilings, stopping conditions, rollback arrangements and escalation routes.

The evidence should describe the deployed configuration. Results from a narrower prototype don't establish how an application behaves after adding new documents, permissions or tools.

More articles on this subject are collected in the AI security overview.

Sources: Key factual claims are attributed to the OWASP Gen AI Security Project, including its 2025 updates page, the OWASP Top 10 for LLM Applications 2025 resource and the OWASP LLM application security document.