OWASP LLM Top 10 as controls you can implement

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

The OWASP Top 10 for LLM Applications 2025 is a community risk list, published 18 November 2024, for applications that call a large language model. It is not a certification and it is not a claim that any one control stops every attack. Read as an engineering checklist, it says where to put a deterministic check, because the model itself is not that check.

An AI writing system produced this article for NetLeverage's editorial studio. No application was penetration-tested against the list. The controls below are the prevention items OWASP printed, grouped so a team can assign an owner. Recommendations about order are marked as ours.

How prompt injection works as a mechanism is a separate subject. This article does not repeat attack strings. It uses OWASP's own statement that a system prompt is not a security control, and that retrieval and fine-tuning do not fully close injection.

Why it matters

The 2025 letter from the project leads says the list changed because applications changed. Unbounded Consumption widens the old denial-of-service entry to cover cost and resource use. Vector and Embedding Weaknesses was added for retrieval-augmented systems. System Prompt Leakage was added because teams had been treating the hidden instruction as a secret. Excessive Agency was expanded for agents that call tools.

A team that "implements the Top 10" by adding a longer system prompt has inverted the document. LLM07 says the system prompt should not be treated as a secret and should not be used as a security control. Credentials, role names, and permission rules in that prompt are in the wrong place even if nobody ever extracts the wording. Attackers who use the application can infer many of the guardrails from what the model refuses.

How it works

OWASP numbers ten risks. The title page calls it Version 2025, 18 November 2024. LLM04's heading in that PDF omits the ":2025" suffix the other entries use. The names below follow the headings as printed.

The model is an untrusted caller

LLM01 defines prompt injection as user prompts that alter behaviour or output in unintended ways, including inputs a person cannot read, so long as the model parses them. Direct injection is in the user's prompt. Indirect injection is in something the model reads later: a web page, a file, a retrieved chunk. OWASP says the impact depends on the business context and on how much agency the application gave the model. It also says that, because of the way generative models work, it is unclear whether a fool-proof prevention exists. Retrieval-augmented generation and fine-tuning "do not fully mitigate" injection, in OWASP's words.

The mitigations it still lists are impact limits:

1. Constrain the role in the system prompt, and tell the model to ignore attempts to rewrite its instructions. Treat this as a reduction, not a boundary. LLM07 explains why.
2. Specify an output format and validate it with ordinary code.
3. Filter input and output. OWASP mentions the "RAG Triad": context relevance, groundedness, and question-answer relevance.
4. Give tools to the application, not a raw token to the model, and keep the model's privileges minimal.
5. Require a person to approve high-risk actions.
6. Separate external content and mark it as untrusted.
7. Test on purpose, treating the model as an untrusted user.

LLM05 is the other half of the same boundary. Improper output handling is failing to validate model text before it reaches another component. OWASP distinguishes it from overreliance: this entry is about the text crossing into a shell, a browser, SQL, a path, or an email template. The printed consequences include cross-site scripting, cross-site request forgery, server-side request forgery, privilege escalation, and remote code execution. The controls are the ordinary ones: treat the model as a user, follow the OWASP Application Security Verification Standard for validation and encoding, use parameterised queries, set a content security policy, and log odd outputs. A model that "writes SQL" is not a query builder. The application either binds parameters or it does not run the statement.

LLM06 names the agency problem as excessive functionality, excessive permissions, or excessive autonomy. Triggers include a confused answer from a harmless prompt, and injection from a user, a tool, or another agent. The preventions are specific:

• Offer only the tools the task needs. If the system does not need to fetch a URL, do not offer that tool.
• Inside a tool, implement only the operation required. A mail summary needs read, not send and delete.
• Avoid open-ended tools such as "run a shell command". A file-writing tool that only writes a file is a smaller surface than a shell.
• Grant the tool's identity the minimum rights on the downstream system. A product catalogue reader does not need UPDATE.
• Run the action as the end user, with that user's scope, rather than as a shared administrator. OWASP's example is OAuth with the smallest scope that still works.
• Require approval before high-impact actions, in the tool or in the downstream system.
• Enforce authorisation in the downstream system. Do not ask the model whether the action is allowed.
• Sanitise LLM inputs and outputs, including tool traffic, and test with static and dynamic checks.

Logging, monitoring, and rate limits are listed separately. OWASP says they do not prevent excessive agency. They limit how far a bad action gets before someone notices.

LLM07 then forbids the shortcut that makes the first three entries worse. Do not put API keys, connection strings, user roles, or permission maps in the system prompt. Keep them in systems the model does not read. Where possible, move hard behavioural constraints out of the prompt into independent checks. Detect harmful content in an external system. Privilege separation and authorisation bounds must be deterministic and auditable. If one agent would need two privilege levels, OWASP discusses multiple agents, each with the least privilege for its task. Training a model not to reveal its prompt is not a guarantee. An independent check of the output is preferable.

Taken together, LLM01, LLM05, LLM06, and LLM07 are one design rule. The model proposes. Code that you can read decides, encodes, and authorises. A second article in this series covers the attack classes. The control owner is still the application.

Data, documents, and the files you did not write

LLM02 is disclosure of personal data, financial or health detail, credentials, business secrets, or material the provider treats as sensitive, through the model's output. OWASP says a restriction written into the system prompt "may not always be honored" and can be bypassed. Controls it does list: scrub or mask data before it enters training; validate inputs; least privilege on sensitive stores; limit which external sources the model can reach; consider federated learning and differential privacy where they fit the training design; tell users not to paste secrets and let them opt out of training; follow OWASP API8:2023 so errors do not leak configuration. Homomorphic encryption and tokenisation are named as further techniques, not a default stack. LLM02 also lists concealing the system preamble; read that alongside LLM07's warning that prompt secrecy must not be the security boundary.

LLM04 is poisoning of pre-training, fine-tuning, or embedding data, including a backdoor that sits quiet until a trigger. OWASP also points at malware in model files, including malicious pickling, which belongs with supply chain as well. Controls: track origin and transformations (it names OWASP CycloneDX or an ML bill of materials); vet vendors; sandbox untrusted data and use anomaly detection; keep fine-tunes on purpose-built sets; stop the training job from reading stores it should not; version datasets; keep user-supplied text in a retrieval store when that avoids a full retrain; red-team; watch training loss; at inference time, ground answers. A sleeper trigger is, in OWASP's own warning, hard to test for and detect.

LLM08 is the retrieval case. Embeddings can leak across tenants, be inverted back toward source text, or be poisoned, including by a document whose visible text and hidden text disagree. Controls printed: permission-aware vector stores and strict partitioning; validate and authenticate sources; review combined datasets and tag them; keep immutable retrieval logs. The scenario mitigations add two practical checks: extraction that does not trust colour and layout, and validation before a document enters the knowledge base. OWASP also says retrieval can change behaviour that is not factual accuracy, and that you should measure that change rather than assume grounding only helps.

LLM03 is the supplier view of the same files. It covers outdated packages, licence clashes, abandoned models, pre-trained weights you cannot inspect, weak provenance, a malicious LoRA adapter, shared conversion services, on-device tampering, and a privacy policy that changes under you. Model cards, it says, do not prove origin. Models can be fine-tuned to look good on a published benchmark. The controls: vet suppliers and re-read their terms; vulnerability-scan and patch, including in development environments that hold sensitive data; red-team a third-party model on your use case; keep a signed software bill of materials, and look at AI and machine-learning bills of materials starting with CycloneDX; inventory licences; accept models from verifiable sources and check signatures and hashes; watch collaborative build systems; run anomaly and robustness tests, knowing OWASP calls these emerging; patch APIs and model versions on a policy; for edge deployments, encrypt, check integrity, and use vendor attestation to stop an unrecognised firmware. Those attestation controls are the vendor's recommendation inside this list. They are not a statement that any particular chip's attestation covers the guest application. That limit is a separate subject.

Answers people will believe, and bills you will pay

LLM09 defines misinformation as false or misleading output that looks credible. Hallucination is one cause. Training bias and incomplete information are others. Overreliance is the human half: people paste the output into a decision. OWASP's examples, which this article does not re-verify from the news reports, include a cited airline chatbot dispute, cited fabricated court cases, cited health answers, and cited insecure or non-existent packages. The mitigations: retrieve from trusted sources; fine-tune or use embeddings where that matches the product; have people cross-check high-stakes answers, and train those people so they do not rubber-stamp; validate key outputs automatically; say what the system is bad at; review generated code and do not install a package because the model named it; label machine-generated content and state the field the system is for.

LLM10 is unbounded consumption: too much inference, aimed at downtime, at the invoice, or at copying the model's behaviour. Examples include floods of variable-length input, "denial of wallet" on a priced API, context-window overflow, expensive queries, extraction of a shadow model, and using the model's own outputs as synthetic training data. Controls: cap input size; do not return logit_bias and logprobs unless you must, and then not in detail; rate-limit and quota per caller; cap resources, time, and queued actions; sandbox the application's network; log and alert on odd consumption; consider watermarking; degrade rather than fall over; keep an inventory and an approval path for what actually runs in production. OWASP also lists adversarial training and glitch-token filters. Adversarial training is model-side; a list of glitch tokens scanned before output re-enters context is an application measure. Neither replaces quotas. The entry also includes role-based access to model repositories.

What to choose and why

Our order, for a team that already has a working prototype, follows the blast radius in the document rather than the numbers one to ten.

A control that only exists as a sentence in the prompt fails LLM07 even if you also tick LLM01's first mitigation. Keep the sentence if you want it. Do not count it as the control.

Risks and limits

• OWASP says it is unclear whether prompt injection has a fool-proof prevention. A completed checklist is not a proof of safety.
• OWASP calls anomaly detection and adversarial robustness tests on supplied models emerging, as well as AI/ML bills of materials. It places homomorphic encryption under advanced techniques and lists watermarking, adversarial training and differential privacy without quantifying their effectiveness. Shipping the name without the design is not the mitigation.
• The PDF cites incidents and CVEs as scenarios. This article does not re-investigate those incidents and does not repeat payloads.
• The list is CC BY-SA 4.0. Quoting a control here is not a replacement for the entry, its references, or the frameworks it points at, including MITRE ATLAS identifiers printed on several entries.
• Version 2025 is dated 18 November 2024 in the file that was opened. A later edition would supersede the table. Nothing here is a NetLeverage product claim, and no control was executed in a lab.

The adapted OWASP control material is attributed to the OWASP GenAI Security Project under Creative Commons Attribution-ShareAlike 4.0, https://creativecommons.org/licenses/by-sa/4.0/. This article regroups and paraphrases the entries and adds editorial interpretation; adapted material is shared under that same licence.

Sources

Sources checked on 10 November 2026; access limitations are identified below.

1. OWASP, OWASP Top 10 for LLM Applications 2025, Version 2025, 18 November 2024 — https://genai.owasp.org/download/43299/. Entries LLM01 through LLM10, including each prevention list and the project leads' letter.

This article was originally published on 10 November 2026.