The OWASP LLM Top 10 is the authoritative list of security risks in production LLM applications. If you ship features that call OpenAI, Anthropic, or any open-weights model, your security checklist should map every release to these ten risks.
This guide walks each risk with a concrete mitigation, the team that owns it, and how the control maps to US compliance frameworks (SOC 2 trust services criteria, HIPAA technical safeguards, SOX general computing controls). Use it as a release-readiness gate, not a year-end audit document.
The current authoritative list is maintained at the OWASP GenAI Security Project and the OWASP LLM Top 10 project page. The framing here is implementation-side, not specification.
What is the OWASP LLM Top 10?
The OWASP LLM Top 10 is a list of the ten most critical security risks for applications that use Large Language Models. It is updated by the OWASP GenAI Security Project and is the de facto reference cited in vendor questionnaires, SOC 2 readiness assessments, and AI-specific risk frameworks like the NIST AI Risk Management Framework.
The list is technology-neutral. It applies whether your stack is OpenAI plus LangChain, self-hosted Llama, or a multi-vendor RAG pipeline. We hire and place AI engineers across all of these stacks; see our AI developer pillar for the broader role definition.
What is the implementation checklist for each risk?
Each row below is a release-gate question. If you cannot answer "yes" with evidence, the feature is not ready to ship.
| Risk | Mitigation owner | Maps to |
|---|---|---|
| LLM01 Prompt Injection | App team | SOC 2 CC6.1, CC6.6 |
| LLM02 Insecure Output Handling | App team | SOC 2 CC6.1, OWASP ASVS |
| LLM03 Training Data Poisoning | Data platform | SOC 2 CC8.1, HIPAA 164.308(a)(1) |
| LLM04 Model Denial of Service | Platform / SRE | SOC 2 A1.1, A1.2 |
| LLM05 Supply Chain Vulnerabilities | Security / vendor risk | SOC 2 CC9.2, SOX ITGC |
| LLM06 Sensitive Information Disclosure | App team + privacy | HIPAA 164.312(a), GDPR Art. 32 |
| LLM07 Insecure Plugin Design | App team | SOC 2 CC6.1, CC8.1 |
| LLM08 Excessive Agency | App team + product | SOC 2 CC6.1, SOX ITGC change control |
| LLM09 Overreliance | Product / UX | NIST AI RMF GOVERN-1.4 |
| LLM10 Model Theft | Security / platform | SOC 2 CC6.1, CC6.7 |
LLM01 Prompt Injection
An attacker manipulates the model by sending crafted input directly (jailbreak prompts) or indirectly (poisoned documents, tool outputs, external retrievals). Mitigations: separate trusted system instructions from untrusted user content, validate tool-call arguments before execution, sandbox any code interpretation, and run output through a safety classifier before showing it to users. Never grant the model itself any privileged action.
LLM02 Insecure Output Handling
The application trusts model output and forwards it raw to downstream systems (rendering as HTML, executing as SQL, passing as a shell command). Treat every model output as untrusted input. Encode for the destination context (HTML escape for rendering, parameterise for SQL, avoid shell entirely). This is the single highest-leverage control because one missed escape becomes XSS, SQLi, or RCE.
LLM03 Training Data Poisoning
Relevant if you fine-tune or run continuous learning on user-submitted data. Audit your training pipeline: signed datasets, immutable provenance logs, separation of feedback collection from training data, periodic model evaluation against a held-out adversarial set. If you only call hosted models, this risk transfers to your vendor; document in your vendor risk file.
LLM04 Model Denial of Service
Attackers craft inputs that drive token usage and cost through the roof: long contexts, recursive tool loops, embedding bombs. Mitigations: per-tenant rate limits, max-token budgets per request, recursion depth caps, alerts on cost-per-tenant anomalies. Tie alerts to your billing dashboard, not just CloudWatch.
LLM05 Supply Chain Vulnerabilities
Your LLM stack pulls model weights, embedding indexes, vector databases, framework libraries, plugin manifests. Each is a supply-chain entry point. Pin versions, sign artefacts where possible, scan with software composition analysis tools for known CVEs, and keep an SBOM that includes models alongside code dependencies. SBOM coverage of model artefacts is the new baseline question on enterprise security questionnaires.
LLM06 Sensitive Information Disclosure
The model leaks PII or trade secrets through training-data memorisation, log exposure, or careless prompt construction. Mitigations: redact PII before inclusion in prompts, never put secrets (API keys, internal credentials) in system prompts, use deterministic redaction libraries, log prompt and completion to a separate audit store with stricter access. For HIPAA workloads, ensure your LLM vendor signs a BAA before any PHI flows.
LLM07 Insecure Plugin Design
Tool calls and plugins extend the model's capability surface. Each tool is a potential RCE vector if it accepts unstructured arguments and executes them. Mitigations: typed tool schemas (JSON Schema, Pydantic, Zod), allow-list every tool action, reject unknown parameters, run tools in least-privilege containers. Treat each tool call like an authenticated API request, not a model continuation.
LLM08 Excessive Agency
An agent has more authority than the task requires (write access when read would suffice, send-email when draft would suffice, root credentials when a scoped role would suffice). Mitigations: principle of least privilege, mandatory human-in-the-loop for irreversible actions, dry-run mode for new agents, change-control logging for any agent action that modifies production state.
LLM09 Overreliance
This risk is a product risk, not a code risk. Users trust hallucinated or wrong outputs because the UI implies authority. Mitigations: confidence indicators, citation-required output formats, friction on high-stakes actions (medical, legal, financial), human review on critical paths, clear UI signal that the output is AI-generated.
LLM10 Model Theft
Self-hosted model weights or proprietary fine-tuned models are exfiltrated. Mitigations: encrypted storage at rest, signed model artefacts, network egress controls on model-serving infrastructure, watermarking where supported, monitoring for abnormal weight-file access patterns. If you only call hosted models, this risk transfers to your vendor.
How does the checklist map to US compliance frameworks?
The same OWASP LLM mitigations are referenced in three US-relevant frameworks. If your customer base is US enterprise, your auditor will already know to map AI-specific risks to existing trust criteria.
- SOC 2 Type II: most LLM controls fall under CC6 (logical and physical access) and CC7 (system operations). Output handling and supply chain controls map to CC8 (change management). Availability controls (rate limits, cost guardrails) sit under A1.
- HIPAA: any LLM that processes PHI requires a Business Associate Agreement with the model vendor, encryption in transit and at rest, and audit logging at the prompt-and-completion level. PHI redaction before inclusion in prompts is a 164.312(a) safeguard.
- SOX: agent actions that modify financial systems trigger ITGC change-control requirements. Excessive agency (LLM08) is the highest-risk item; require dual-approval for any agent that can post journal entries or modify revenue-recognition data.
For deeper US compliance framing including the Colorado AI Act and NYC Local Law 144 hiring rules, see our forthcoming Compliance Checklist for AI Applications post (next in this series).
Who owns each control on the engineering team?
Mapping the checklist to roles avoids "the security team will get to it" failure mode. The right ownership in a 2026 mid-market AI SaaS:
- App engineers own LLM01, LLM02, LLM07, LLM08 (input handling, output handling, plugin design, agency scope). These are code-level controls.
- Platform / SRE own LLM04, LLM10 (DoS protection, model storage). These are infrastructure controls.
- Data platform owns LLM03, LLM06 (training data integrity, sensitive information). These are pipeline controls.
- Security / vendor risk owns LLM05 (supply chain). This is procurement and SBOM hygiene.
- Product / UX owns LLM09 (overreliance). This is interface design.
If your team is too small to staff each role, an AI developer pod from Workforce Next typically pairs an LLM application engineer with a fractional security reviewer for the first 90 days of any production launch. The same pattern works for RAG-specific engagements and LangChain-heavy stacks.
Where do most teams fail this checklist on first audit?
From the AI security reviews we run for clients, three failures are most common:
- LLM02 missed: rendering model output as HTML or Markdown without escaping. This is the most frequent finding, and the most fixable. One escape function and a test catches it.
- LLM07 over-permissive tools: tool definitions accept arbitrary string parameters that get passed to a shell, a database query, or a file system call. Refactor to typed schemas with allow-listed actions.
- LLM05 missing model SBOM: the team has a code SBOM but not a model SBOM. Auditors increasingly ask for both, especially in healthcare and financial services. Add model artefact provenance to your existing SBOM tooling.
For a broader view of how AI-native teams stay disciplined as they scale, see our 2026 AI MVP tech stack guide and the agent framework selection guide.
What does an AI security review engagement look like?
A typical 2-week security review for an LLM application covers all ten OWASP risks plus the data-flow specific to your stack. SethAI matches a senior application security engineer with LLM-application experience to your team. The review produces a per-risk findings document, a prioritised remediation backlog, and a release-gate checklist tied to your existing CI.
If you also need engineers to implement the remediations, that is a separate dedicated pod. See our managed offshore team page for the operating model.
Frequently asked questions
See the FAQ block below for quick answers on framework versions, vendor risk, compliance mapping, and team structure.
Ready to scope a review? Book a 30-minute call on our contact page and we will share two senior AI security engineer profiles within 5 business days.