Review scope and evidence labels
This page profiles the OWASP Top 10 for LLM Applications as community security guidance for large-language-model application risk.
Evidence labels used on this page:
- Community security guidance — based on OWASP or similar public security community material.
- Official guidance — based on public official guidance such as NIST material.
- Author analysis — interpretation for AI security, architecture, governance and operational risk on this site.
- Implementation evidence required — local records that must exist before a mitigation can be treated as operating.
This entry is a Research profile, not a claim that an organisation is secure because it mentions OWASP. The value of the OWASP LLM Top 10 is in using it to drive design review, threat modeling, testing, governance and evidence.
Standard snapshot
| Field | Value |
|---|---|
| Category | LLM application security guidance |
| Research type | Standard / community guidance |
| Core question | What common risk classes should teams consider when building or using LLM applications? |
| Main scope | LLM-enabled applications, RAG systems, AI agents, plugins, tools, APIs and generated outputs |
| Useful outputs | Risk checklist, abuse cases, test plan, control mapping, residual-risk decisions and audit evidence |
| Companion methods | AI Threat Modeling, AI Security Architecture, AppSec review, NIST AI RMF, MITRE ATLAS |
| Review status | Public OWASP project reviewed; local implementation requires system-specific validation |
What the OWASP LLM Top 10 is
The OWASP Top 10 for LLM Applications is community security guidance focused on common risk classes in systems that use large language models. Evidence: Community security guidance.
It helps teams move beyond vague statements such as “AI is risky” and toward practical questions about prompts, data, output handling, tool permissions, retrieval, model behavior and operational evidence. Evidence: Community security guidance; Author analysis.
For this site, the OWASP LLM Top 10 is used as a practical vocabulary for AI Security Architecture and AI Threat Modeling, especially where LLM features are exposed through web applications, internal tools, APIs or AI-assisted engineering workflows. Evidence: Author analysis.
What it is not
The OWASP LLM Top 10 is not:
- a certification,
- a compliance guarantee,
- a complete AI safety framework,
- a replacement for secure software development,
- a replacement for architecture review,
- a replacement for local threat modeling,
- proof that an LLM application is safe by itself.
A team can say it considered OWASP risks only if it can show evidence: which risks were applicable, what controls were chosen, what was tested, what remained accepted and when the review will be repeated. Evidence: Author analysis; Implementation evidence required.
Risk themes for architecture review
OWASP LLM guidance is useful because it highlights risk classes that appear repeatedly in LLM applications.
| Risk theme | Architecture question | Evidence to retain |
|---|---|---|
| Prompt injection | Can instructions from users or documents override intended behavior? | Abuse tests, prompt review, output validation notes |
| Sensitive information disclosure | Can prompts, responses, context, embeddings or logs expose protected data? | Data-flow map, classification, retention and access review |
| Supply-chain exposure | Can libraries, models, datasets, plugins or generated code introduce hidden risk? | Dependency review, SBOM, provenance and build evidence |
| Data or model manipulation | Can training, fine-tuning, retrieval or context sources be poisoned? | Source governance, dataset/retrieval controls, change review |
| Insecure output handling | Can generated output become unsafe code, command, HTML, query or decision input? | AppSec tests, sandboxing, human review and validation controls |
| Excessive agency | Can an AI agent take actions beyond what should be permitted? | Least-privilege permissions, approval gates and execution logs |
| Retrieval and embedding weakness | Can RAG or vector search return unsafe, unauthorized or manipulated context? | Indexing controls, access checks, provenance and retrieval tests |
| Unbounded consumption | Can usage patterns cause cost, availability or denial-of-service problems? | Rate limits, quotas, monitoring and incident thresholds |
Evidence: Community security guidance; Author analysis.
How to use it in threat modeling
OWASP LLM Top 10 works best as an input to threat modeling, not as a passive checklist.
A practical use pattern:
- Describe the LLM use case and business process.
- Draw the data flow, model boundary, tool boundary and RAG boundary.
- Mark which OWASP LLM risk classes apply.
- Write abuse cases for the applicable risks.
- Map mitigations to architecture controls.
- Decide what evidence must be retained.
- Re-run the review when prompts, tools, datasets, retrieval sources, permissions or model providers change.
Evidence: Community security guidance; Author analysis.
Relationship to existing Research entries
OWASP LLM Top 10 connects to:
- AI Security Architecture — OWASP risks become architecture-review questions.
- AI Threat Modeling — OWASP categories help structure LLM abuse cases.
- Secure AI-Assisted Development — AI-generated code and AI-enabled applications need AppSec review before deployment.
- AI Governance — risk acceptance and accountability must be assigned.
- SBOM — supply-chain risk needs component, dependency and provenance evidence.
- Zero Trust — tool use, agent permissions and access to data sources need least privilege and telemetry.
Governance relevance
OWASP LLM Top 10 is useful for governance because it gives management and technical teams a shared language for LLM application risk. Evidence: Community security guidance; Author analysis.
It can support an AI risk register, control mapping, security architecture review, vendor assessment, development gate, audit-evidence checklist and executive summary. Evidence: Author analysis; Implementation evidence required.
Current limitations and follow-up research
This entry is a public Research profile. It does not replace reading the current OWASP project material and does not decide which risks apply to a specific system.
Follow-up Research nodes should cover:
- MITRE ATLAS,
- Prompt Injection,
- RAG Security,
- AI Red Teaming,
- Model Supply Chain Security,
- IAM for AI systems.