OWASP LLM Top 10 Explained: Risks, Examples and Controls

You must assign clear ownership of each risk category to a named person or team, document what verification occurs before the application handles consequential work, and retain evidence showing which decisions remain professionally yours to make. A checklist of OWASP categories is not governance; a record of who decided what, on what evidence, and what uncertainty persists is.

An analysis of 13 November 2026 of the OWASP LLM Top 10 for 2025 argues that misinformation and security failure are distinct concerns, and that protecting confidential data does not establish that an answer is correct. The analysis uses a legal assistant retrieving contracts, a compliance assistant drawing on policy libraries, and a notarial practice using retrieval-augmented generation across client files as worked examples. In our assessment, the framework's value lies not in coverage of ten categories but in connecting each one to an inspectable decision: who owns the exposure, what verification is required before reliance, which changes need approval, and what uncertainty the professional user must accept.

Which risks arise from the application's own instructions and connections?

Prompt injection occurs when an application follows instructions it shouldn't. The distinction between direct injection through user input and indirect injection through retrieved documents, web pages or tool responses matters because a document can be both evidence to analyse and a vehicle for instructions the application should reject. A legal assistant that retrieves a contract containing instructions to send the case summary to an external address may execute those instructions if the application processes all text as equally authoritative.

Assign the application owner responsibility for the entire processing path, not merely the prompt box. Verification should capture attempted tool calls and data access, even if the final answer appears harmless. The boundary between a business document and an instruction deserves explicit testing. Your remaining decision is which external content the application may process and with what authority; successful tests provide evidence about tested conditions, not proof against every future injection.

System-prompt leakage exposes internal instructions, revealing application behaviour and 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. 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 and assess whether the application remains appropriately restricted. Independent review should examine both prompt-extraction tests and the controls outside the model.

What controls must you demonstrate over data before processing begins?

• Confidential-information disclosure — personal data appearing in answers, retrieval results, retained prompts or operational logs.
• Cross-client retrieval — material from one client, patient or department becoming accessible through another's query.
• Unintended field exposure — confidential fields leaving the controlled environment through retrieval or output.
• Unsupported source changes — material entering the knowledge base without approval or audit trail.

The data owner should determine what an application may disclose before a model receives the material. A privacy review must follow information through the workflow, including places users don't ordinarily see. 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. Removing a name does not establish that the surrounding narrative is safe to disclose.

The retrieval-system owner should verify access at retrieval time, before documents enter the model's context. For professional knowledge bases, relevance and authorisation are separate questions. A passage may match a query closely while belonging to a different client or confidential matter. Testing should attempt cross-client retrieval with realistic document similarities, then inspect the returned document identifiers and passages. An answer that omits restricted text does not establish that the retrieval layer withheld it; reviewers need evidence from the retrieval boundary itself. Changes to filters, indexes or embedding services should undergo regression testing before release, including denied-access cases, not merely examples that retrieve the expected answer.

What must you verify about the components and sources entering your application?

Procurement needs an inspectable account of the components entering the application and the process for changing them. 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. Give the platform owner responsibility for technical dependencies, with procurement and privacy specialists reviewing their respective exposures. A research team adding a document-parsing library to process confidential reports should establish its origin, version, execution behaviour and network access before approval.

Poisoning makes the integrity of incoming material a security responsibility, not merely an editorial preference. Manipulated training, fine-tuning or retrieval material can influence subsequent behaviour. The governance implication is to examine how material becomes trusted, not only whether an individual answer appears reasonable. Say a compliance assistant draws on an internal policy library and someone inserts an unofficial exception stating that a restricted transaction no longer requires approval; the assistant later presents that exception as established policy. 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.

1. Inventory deployed models, data sources, retrieval stores and connected tools — identify which versions were tested and which changes trigger reassessment.
2. Document who can change each component and when — record approvals, dates and the business justification for each change.
3. Retain source versions and audit trails — preserve uploader, timestamp, approval and affected index entries for sensitive material.
4. Test retrieval and embedding changes before release — include denied-access cases and cross-client scenarios, not merely successful retrievals.
5. Verify third-party component origin and execution behaviour — establish network access, dependencies and update mechanisms before deployment.

What authority should the application hold, and how should output be handled?

Excessive agency identifies excessive functionality, excessive permissions and excessive autonomy as recurring causes of damaging actions. The trigger need not be an attack; an ambiguous request, mistaken output or compromised connected component can become consequential when the application has permission to act. A communications assistant that drafts correspondence does not 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. Approval should show the proposed action, not merely a reassuring summary. Your remaining decision is 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.

Control belongs where generated content enters another system. Improper output handling 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. 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. 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.

How should you verify that answers are correct, not merely plausible?

Evidence should be sufficient for the claim's intended use, not merely sufficient to make the answer plausible. 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. 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 is not independent evidence when reviewers repeat the same mistaken premise or rely on the same unsuitable source. Preserve source dates, reviewer objections and unresolved disagreements in the verification trail. Agreement among models can support review, but it does not establish correctness or transfer responsibility away from the professional using the result.

The service owner should set enforceable resource limits before deployment. Uncontrolled resource use can create cost and service-availability exposure through 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. 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. Independent review should check whether proposed limits leave enough capacity for meaningful verification. What happens when the limit is reached matters; pausing for approval may be more defensible than returning an incomplete answer without notice.

Tooling can enforce resource caps, validate output structure and test retrieval boundaries. What remains is your professional judgement about which claims warrant verification depth, whether unresolved uncertainty should be qualified or excluded, and how much autonomy the task genuinely requires. Start with an inventory of models, data sources and connected tools, identify who can change them, and retain evidence showing which decisions you made and on what basis.