# OWASP LLM Top 10 Security Checklist

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

This checklist turns the OWASP Top 10 for LLM Applications (2025 edition) into a practical security review you can run against any LLM-powered system. It covers all ten risks, from prompt injection to unbounded consumption, with plain-English descriptions, concrete review items, evidence requirements, and a summary scorecard.

It is written for two audiences at once: teams building LLM features into their own products, and teams assessing vendor products with embedded LLM capabilities. Most organisations are both. Each review item is tagged **Build**, **Buy**, or **Both** so a single pass covers your whole estate.

---

## How to Use

1. List every in-scope LLM system in the scoping register below. Include systems you build and products you buy.
2. For each system, work through the ten risk sections in order. Mark each review item Pass, Fail, or N/A.
3. Use the "Applies to" column to skip items that do not match your relationship to the system (Build, Buy, or Both).
4. Collect the evidence listed at the end of each section as you go. An unevidenced Pass is an opinion, not a finding.
5. Assign a severity and status to each risk and record them in the summary scorecard, one scorecard per system.
6. Raise an action with an owner and target date for every Fail. Prioritise by severity and by how exposed the system is to untrusted input.
7. Re-run the review after remediation, after any material change to the system, and at least annually.

---

## Scoping: Which Systems to Review

Run this checklist against every system where an LLM processes untrusted input, touches sensitive data, or can take actions. Typical candidates:

- Customer-facing chatbots and assistants
- Internal copilots and knowledge assistants, including RAG over company documents
- AI agents with tool, API, or database access
- LLM features embedded in vendor SaaS products (CRM assistants, meeting summarisers, coding assistants)
- Internal applications that call LLM APIs for summarisation, extraction, or classification
- Fine-tuned or self-hosted models and the pipelines that train them

If a vendor product gained an AI assistant since you last reviewed it, it belongs in this register. Embedded LLM features are the ones that most often skip security review.

### Scoping register

| # | System / feature | Build / Buy | Description and data touched | In scope? | Review owner |
|---|------------------|-------------|------------------------------|-----------|--------------|
| 1 | [System] | [Build / Buy] | [What it does, data involved] | ☐ Yes ☐ No | [Name] |
| 2 | | | | ☐ Yes ☐ No | |
| 3 | | | | ☐ Yes ☐ No | |
| 4 | | | | ☐ Yes ☐ No | |
| 5 | | | | ☐ Yes ☐ No | |

---

## Summary Scorecard

Complete one scorecard per system after finishing the ten sections. Severity: High / Medium / Low. Status: Open / In progress / Closed.

**System reviewed:** [SYSTEM NAME]
**Review date:** [DATE]
**Reviewed by:** [NAME / ROLE]

| ID | Risk | Severity | Status | Owner | Target date |
|----|------|----------|--------|-------|-------------|
| LLM01 | Prompt Injection | | | | |
| LLM02 | Sensitive Information Disclosure | | | | |
| LLM03 | Supply Chain | | | | |
| LLM04 | Data and Model Poisoning | | | | |
| LLM05 | Improper Output Handling | | | | |
| LLM06 | Excessive Agency | | | | |
| LLM07 | System Prompt Leakage | | | | |
| LLM08 | Vector and Embedding Weaknesses | | | | |
| LLM09 | Misinformation | | | | |
| LLM10 | Unbounded Consumption | | | | |

---

## LLM01: Prompt Injection

Attackers craft inputs, or hide instructions inside content the model reads (web pages, documents, emails, tickets), to make the model ignore its instructions and do something else. It is the most widely exploited LLM weakness, and it cannot be fully eliminated, only contained, so the review focuses on layered defences and bounded impact.

**Who this applies to:** Builders of any feature that accepts free text or retrieves external content. Buyers of any product whose assistant reads data you do not fully control, such as inboxes, shared documents, or the web.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 1.1 | System instructions are separated from user and retrieved content, with explicit trust boundaries between them | Build | ☐ Pass ☐ Fail ☐ N/A |
| 1.2 | Inputs and retrieved content are screened for injection patterns before reaching the model (filters, classifiers, or guardrail models) | Build | ☐ Pass ☐ Fail ☐ N/A |
| 1.3 | The model's privileges (tools, APIs, data access) follow least privilege, so a successful injection has bounded impact | Both | ☐ Pass ☐ Fail ☐ N/A |
| 1.4 | High-impact actions triggered by model output require human approval or an independent technical control | Both | ☐ Pass ☐ Fail ☐ N/A |
| 1.5 | The application is adversarially tested for direct and indirect prompt injection before release and after major changes | Build | ☐ Pass ☐ Fail ☐ N/A |
| 1.6 | External content (web pages, attachments, calendar invites) is treated as untrusted and clearly delimited when passed to the model | Both | ☐ Pass ☐ Fail ☐ N/A |
| 1.7 | The vendor documents its prompt injection defences and shares red-team or penetration test summaries on request | Buy | ☐ Pass ☐ Fail ☐ N/A |
| 1.8 | Injection attempts are logged, monitored, and fed into detection rules | Both | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** red-team or penetration test report covering direct and indirect injection, input filtering configuration, architecture notes showing trust boundaries, vendor security documentation.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM02: Sensitive Information Disclosure

The model reveals data it should not: personal information, credentials, commercial secrets, or other users' content. Leakage can come from training data, from context supplied at runtime, or from logs and histories kept around the model. Both directions matter: what your people send in, and what the system gives out.

**Who this applies to:** Builders who train, fine-tune, or feed context into models. Buyers whose staff put company data into vendor AI features, which in practice means every buyer.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 2.1 | Data sent to the model (prompts, context, uploaded files) is covered by your data classification policy, and sensitive fields are masked or tokenised where feasible | Both | ☐ Pass ☐ Fail ☐ N/A |
| 2.2 | Training and fine-tuning datasets are scrubbed of personal data, credentials, and confidential records before use | Build | ☐ Pass ☐ Fail ☐ N/A |
| 2.3 | Outputs are filtered for personal data, secrets, and confidential content before display and before logging | Build | ☐ Pass ☐ Fail ☐ N/A |
| 2.4 | The vendor contract states that your data is not used for training without consent, and defines retention limits and deletion rights | Buy | ☐ Pass ☐ Fail ☐ N/A |
| 2.5 | Access to prompt logs and conversation history is role-restricted and audited | Both | ☐ Pass ☐ Fail ☐ N/A |
| 2.6 | Users are told what they may and may not submit, and DLP or monitoring controls back the policy | Both | ☐ Pass ☐ Fail ☐ N/A |
| 2.7 | Cross-user and cross-tenant isolation has been tested (one user cannot retrieve another's data through the model) | Both | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** data flow diagram for the system, DLP rule configuration, vendor data processing agreement, log access review records, isolation test results.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM03: Supply Chain

LLM applications inherit risk from everything they are assembled from: base models, fine-tuned adapters, training datasets, frameworks, plugins, and hosted APIs. A tampered model or a compromised dependency undermines every control you layer on top, so provenance and integrity checks matter as much as your own code.

**Who this applies to:** Builders who assemble applications from third-party models and libraries. Buyers who need to know what sits underneath the vendor's product, including its sub-processors and upstream model providers.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 3.1 | An inventory exists of all models, datasets, libraries, and AI services in use, each with a named owner | Both | ☐ Pass ☐ Fail ☐ N/A |
| 3.2 | Models and datasets are sourced from verified publishers, with integrity verified (checksums or signed artefacts) | Build | ☐ Pass ☐ Fail ☐ N/A |
| 3.3 | Licences for third-party models and datasets have been reviewed and permit your intended commercial use | Both | ☐ Pass ☐ Fail ☐ N/A |
| 3.4 | LLM frameworks, plugins, and vector database clients are covered by dependency scanning and a patching cadence | Build | ☐ Pass ☐ Fail ☐ N/A |
| 3.5 | Third-party fine-tuned adapters (for example LoRA weights) are reviewed and tested before deployment | Build | ☐ Pass ☐ Fail ☐ N/A |
| 3.6 | The vendor discloses its upstream model providers and sub-processors, and notifies you when they change | Buy | ☐ Pass ☐ Fail ☐ N/A |
| 3.7 | Collapse or compromise of a single model provider is covered in continuity planning (fallback provider or degradation plan) | Both | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** AI bill of materials or system inventory export, dependency scan reports, licence review records, vendor sub-processor list.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM04: Data and Model Poisoning

Attackers tamper with pre-training, fine-tuning, or embedding data to change how a model behaves: introducing backdoors, bias, or hidden triggers that activate on specific inputs. Poisoning is hard to detect after the fact, so the controls concentrate on provenance, validation, and evaluation before data or models reach production.

**Who this applies to:** Primarily builders who train or fine-tune models or maintain RAG ingestion pipelines. Buyers should confirm the vendor manages this risk for the models behind its product.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 4.1 | Provenance is recorded for all training, fine-tuning, and embedding data (source, date, collection method) | Build | ☐ Pass ☐ Fail ☐ N/A |
| 4.2 | Training pipelines validate and filter incoming data for anomalies, duplicates, and adversarial content | Build | ☐ Pass ☐ Fail ☐ N/A |
| 4.3 | Access to training data and pipelines is restricted, logged, and reviewed | Build | ☐ Pass ☐ Fail ☐ N/A |
| 4.4 | Models are evaluated for backdoors, bias, and behavioural drift before promotion to production (benchmarks plus targeted probes) | Build | ☐ Pass ☐ Fail ☐ N/A |
| 4.5 | User feedback or live data used for retraining is moderated and validated before entering the pipeline | Both | ☐ Pass ☐ Fail ☐ N/A |
| 4.6 | The vendor describes how it protects training data integrity and evaluates its models before release | Buy | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** data provenance records, pipeline validation configuration, pre-deployment evaluation results, pipeline access logs, vendor assurance documentation.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM05: Improper Output Handling

Whatever the model produces ends up somewhere: a browser, a database query, a shell command, an API call. If downstream systems trust that output blindly, a manipulated model becomes an injection engine for classic attacks such as cross-site scripting, SQL injection, and remote code execution.

**Who this applies to:** Builders whose applications render or act on model output. Buyers whose systems consume content generated inside a vendor product (exports, webhooks, generated code).

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 5.1 | Model output is validated and context-encoded before rendering in browsers or UI components | Build | ☐ Pass ☐ Fail ☐ N/A |
| 5.2 | Output is never passed to interpreters, shells, or databases without sanitisation and parameterised execution | Build | ☐ Pass ☐ Fail ☐ N/A |
| 5.3 | Actions driven by model output (API calls, file writes, workflow triggers) are restricted to an allow-list | Both | ☐ Pass ☐ Fail ☐ N/A |
| 5.4 | Downstream services treat LLM output with the same suspicion as untrusted user input | Both | ☐ Pass ☐ Fail ☐ N/A |
| 5.5 | Generated code is reviewed or sandboxed before execution in any environment that matters | Both | ☐ Pass ☐ Fail ☐ N/A |
| 5.6 | Security testing (SAST, DAST, or manual review) covers the paths where model output flows into other systems | Build | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** code review notes for output handling paths, security test results, allow-list configuration, sandbox architecture description.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM06: Excessive Agency

LLM systems increasingly act rather than just answer: calling tools, sending messages, changing records. Excessive agency means the system can do more than its purpose requires, so one bad decision or one successful injection turns into real-world damage instead of a wrong answer.

**Who this applies to:** Builders deploying agents, plugins, or tool-calling features. Buyers of products whose AI can take actions in connected systems, such as sending email or updating records.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 6.1 | Each agent or tool integration has the minimum set of functions and permissions needed for its purpose | Both | ☐ Pass ☐ Fail ☐ N/A |
| 6.2 | High-impact actions (payments, deletions, external communications, production changes) require human approval | Both | ☐ Pass ☐ Fail ☐ N/A |
| 6.3 | Agents run under their own scoped identities and credentials, distinct from any human user | Build | ☐ Pass ☐ Fail ☐ N/A |
| 6.4 | Rate limits and budgets cap what an agent can do within a time window | Both | ☐ Pass ☐ Fail ☐ N/A |
| 6.5 | Every agent action is logged with enough detail to reconstruct what happened and why | Both | ☐ Pass ☐ Fail ☐ N/A |
| 6.6 | A kill switch exists to halt an agent and revoke its credentials quickly | Both | ☐ Pass ☐ Fail ☐ N/A |
| 6.7 | The vendor documents exactly what actions its AI features can take autonomously and which controls you can configure | Buy | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** permission matrix per agent or integration, approval workflow configuration, agent action logs, kill-switch runbook, vendor capability documentation.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM07: System Prompt Leakage

Assume system prompts will eventually be extracted; users routinely coax models into revealing them. The real risk is what leaks alongside the wording: credentials, connection strings, confidential business rules, or security controls that exist only as polite instructions to the model.

**Who this applies to:** Builders who write system prompts. Buyers should confirm the vendor does not embed customer data or secrets in prompts, and does not rely on prompt secrecy for security.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 7.1 | System prompts contain no credentials, API keys, connection strings, or personal data | Build | ☐ Pass ☐ Fail ☐ N/A |
| 7.2 | No security control depends on the system prompt remaining secret; guardrails are enforced outside the model | Both | ☐ Pass ☐ Fail ☐ N/A |
| 7.3 | Sensitive business logic (pricing rules, escalation criteria, internal thresholds) lives in application code, not in the prompt | Build | ☐ Pass ☐ Fail ☐ N/A |
| 7.4 | Prompts are stored and versioned like source code, with access control and change review | Build | ☐ Pass ☐ Fail ☐ N/A |
| 7.5 | The application is tested against known prompt extraction techniques | Build | ☐ Pass ☐ Fail ☐ N/A |
| 7.6 | The vendor confirms its system prompts contain no customer-specific data and that safety controls do not rely on prompt secrecy | Buy | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** prompt repository review, extraction test results, guardrail architecture description, vendor attestation.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM08: Vector and Embedding Weaknesses

RAG systems store knowledge as embeddings in vector databases. Weak access controls, poisoned documents, or cross-tenant bleed in the retrieval layer let attackers read or influence what the model sees, quietly bypassing permissions enforced elsewhere in the application.

**Who this applies to:** Builders operating RAG pipelines or vector stores. Buyers using vendor features that index company documents for retrieval, such as "chat with your files" capabilities.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 8.1 | Retrieval enforces the same document permissions as the source systems (a user cannot retrieve content they cannot open) | Both | ☐ Pass ☐ Fail ☐ N/A |
| 8.2 | Multi-tenant vector stores enforce strict tenant isolation, verified by testing rather than assumed | Both | ☐ Pass ☐ Fail ☐ N/A |
| 8.3 | Documents are validated at ingestion for hidden instructions, malicious content, and classification level | Build | ☐ Pass ☐ Fail ☐ N/A |
| 8.4 | Embedding inversion and data extraction risk has been assessed for sensitive corpora | Build | ☐ Pass ☐ Fail ☐ N/A |
| 8.5 | Deleting a source document removes its embeddings and cached chunks within a defined timeframe | Both | ☐ Pass ☐ Fail ☐ N/A |
| 8.6 | Retrieval activity is logged and monitored for unusual access patterns | Both | ☐ Pass ☐ Fail ☐ N/A |
| 8.7 | The vendor explains how uploaded or indexed documents are isolated, retained, and access-controlled | Buy | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** vector store access control configuration, tenancy and permission test results, ingestion pipeline checks, deletion verification records, vendor documentation.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM09: Misinformation

Models produce confident, plausible, and sometimes wrong output. When that output feeds decisions in legal, medical, financial, or HR contexts, or is published without review, hallucinations stop being a quality issue and become a business, safety, and liability problem.

**Who this applies to:** Both audiences equally. Builders own the accuracy of their features; buyers own how staff rely on vendor AI output in real decisions.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 9.1 | High-stakes outputs (legal, medical, financial, HR, safety) require human review before they are acted on or published | Both | ☐ Pass ☐ Fail ☐ N/A |
| 9.2 | Answers are grounded in verified sources (RAG or citations) where accuracy matters, and citations are shown to users | Build | ☐ Pass ☐ Fail ☐ N/A |
| 9.3 | Accuracy and hallucination rates are measured for key workflows, with defined acceptance thresholds | Build | ☐ Pass ☐ Fail ☐ N/A |
| 9.4 | Users see clear guidance on the system's limitations and their duty to verify before relying on output | Both | ☐ Pass ☐ Fail ☐ N/A |
| 9.5 | A feedback channel exists for reporting wrong output, and reports are triaged and tracked | Both | ☐ Pass ☐ Fail ☐ N/A |
| 9.6 | The vendor publishes evaluation or accuracy information for its AI features, or provides it under NDA | Buy | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** evaluation reports, screenshots of in-product disclaimers and citations, review workflow records, feedback triage log.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## LLM10: Unbounded Consumption

LLM inference is expensive, and nothing about it is self-limiting. Without controls, an attacker or a buggy retry loop can run up costs (denial of wallet), starve other users of capacity, or issue high volumes of queries to clone your model's behaviour.

**Who this applies to:** Builders exposing LLM endpoints or agent loops. Buyers on usage-based pricing, where uncontrolled consumption becomes a budget incident instead of an outage.

| # | Review item | Applies to | Result |
|---|-------------|------------|--------|
| 10.1 | Rate limits and quotas apply per user, per API key, and per tenant | Both | ☐ Pass ☐ Fail ☐ N/A |
| 10.2 | Hard spend caps and budget alerts are configured for every LLM API account | Both | ☐ Pass ☐ Fail ☐ N/A |
| 10.3 | Input size, output length, and context window limits are enforced at the application boundary | Build | ☐ Pass ☐ Fail ☐ N/A |
| 10.4 | Timeouts, queue depth limits, and retry backoff protect against resource exhaustion, including from agent loops | Build | ☐ Pass ☐ Fail ☐ N/A |
| 10.5 | Usage is monitored for anomalous spikes and for extraction patterns (systematic querying to replicate model behaviour) | Both | ☐ Pass ☐ Fail ☐ N/A |
| 10.6 | Vendor throttling behaviour, overage pricing, and contractual consumption caps are understood and documented | Buy | ☐ Pass ☐ Fail ☐ N/A |

**Evidence to collect:** rate limit configuration, billing alert settings, usage dashboards, load test results, vendor pricing and throttling terms.

**Severity:** ☐ High ☐ Medium ☐ Low **Status:** ☐ Open ☐ In progress ☐ Closed

---

## Beyond the Top 10

The LLM Top 10 covers the application layer well, but two areas deserve standing attention beyond a point-in-time review:

- **Agentic risks.** Autonomous and multi-agent systems introduce failure modes this list only touches: goal hijacking, tool misuse, memory poisoning, insecure agent-to-agent communication, and cascading failures across agents. OWASP publishes a separate Top 10 for Agentic Applications (2026); run it alongside this checklist for any system that plans and acts with limited supervision.
- **Continuous monitoring.** A checklist captures one moment. New AI tools enter the organisation without review, vendors add LLM features between assessments, and staff adopt unapproved assistants. Maintain a living AI inventory, monitor which tools are in use and what data flows into them, and trigger a fresh review whenever the estate changes materially.

Treat this document as the recurring core of your LLM security programme, not its entirety: pair it with your incident response playbook and vendor assessment process.

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*