Does the OWASP LLM Top 10 replace the regular OWASP Top 10?

No. LLM applications face both sets of risks. An LLM-powered web app still needs to protect against SQL injection, broken access control, and vulnerable dependencies — plus the LLM-specific risks. The OWASP LLM Top 10 is additive, not a replacement.

Which OWASP Top 10 risks still apply to LLM apps?

All of them, potentially. A01 (Broken Access Control) and A03 (Injection) are especially relevant — agent tool abuse and SQL injection via LLM output are both still injection/access control problems. A06 (Vulnerable Components) applies to LLM SDKs and model dependencies. A09 (Logging Failures) applies to prompt and response logging. Treat traditional OWASP risks as a baseline and LLM-specific risks as additions.

Do SAST tools like Semgrep or CodeQL detect LLM vulnerabilities?

Not directly. Semgrep and CodeQL can be extended with custom rules, but they don't ship with LLM-specific patterns out of the box. They don't understand system prompt semantics, LLM output as a taint source, or agent tool permission models. LLMArmor is purpose-built for these patterns. You can run both — Semgrep/CodeQL for traditional web risks and LLMArmor for LLM-specific risks.

What new threat models do LLM apps introduce?

Three major new threat models: (1) Prompt injection — an attacker controls application behavior through natural language rather than code. (2) Training/RAG data poisoning — the model's knowledge base is an attack surface. (3) Agentic privilege escalation — an LLM with tool access can take real-world actions based on attacker-controlled prompts, collapsing the traditional application/auth boundary.

How often is the OWASP LLM Top 10 updated?

The OWASP LLM Top 10 was first published in 2023 and updated for 2025. Given the pace of LLM development, updates are expected to be more frequent than the traditional OWASP Top 10 (which updates roughly every 3–4 years). Subscribe to the OWASP LLM project page or the project's GitHub repository for release announcements.

Is there a SAST tool specifically for the OWASP LLM Top 10?

Yes — LLMArmor is a free, open-source Python SAST tool built specifically for the OWASP LLM Top 10. It covers LLM01 through LLM10 (excluding LLM03, LLM04, and LLM09 which require runtime analysis), using regex and AST taint analysis. Install with pip install llmarmor .

OWASP LLM Top 10 vs OWASP Top 10: What's Different

AppSec teams have a 20-year-old playbook for the OWASP Top 10. Input validation. Parameterized queries. Output encoding. Role-based access control. WAFs. SAST. The playbook works because web applications are deterministic systems: the same input produces the same output, and the attack surface is bounded by the application’s code. LLMs broke half of that playbook. Your SAST tools don’t know what a system prompt is. Your WAF doesn’t understand that a retrieved email can contain instructions. And the “parameterize your inputs” advice for SQL injection doesn’t translate cleanly to a system where the model treats every token — from any source — as a potential command.

Two lists, two threat models

Traditional OWASP Top 10 (2021) addresses risks in deterministic web applications: broken access control, cryptographic failures, injection (SQL, LDAP, SSTI), insecure design, misconfiguration, vulnerable components, authentication failures, data integrity failures, logging gaps, and SSRF. The common thread: these are engineering mistakes that produce predictable, exploitable behaviors.

OWASP LLM Top 10 (2025) addresses risks that emerge from the non-deterministic, generative nature of language models: prompt injection (the model is the parser), sensitive data leakage through prompts and logs, supply chain risks in model weights and plugins, improper handling of LLM output at dangerous sinks, excessive agent autonomy, and consumption-based DoS. These risks exist in addition to, not instead of, traditional web application risks.

Side-by-side comparison

LLM Top 10 Risk	Closest OWASP 2021 Analog	Why It’s Different
LLM01 — Prompt Injection	A03 — Injection	SQL injection can be fully prevented with parameterized queries. Prompt injection cannot be fully parameterized — the LLM treats user tokens and system tokens as the same thing. Non-deterministic and context-dependent.
LLM02 — Sensitive Info Disclosure	A04 — Insecure Design, A09 — Logging Failures	Training data and LLM API calls are new exfiltration channels. PII sent to an external LLM API may be outside your data boundary even if it never touches your logs.
LLM03 — Supply Chain	A06 — Vulnerable Components	Traditional supply chain: dependency with CVE. LLM supply chain: poisoned model weights, backdoored fine-tuning data, compromised embeddings. The “component” is a 70B-parameter black box.
LLM04 — Data & Model Poisoning	A04 — Insecure Design	No traditional analog. Training data manipulation can embed behavioral backdoors invisible to code review or SAST.
LLM05 — Improper Output Handling	A03 — Injection (SSTI/XSS)	The LLM is now an untrusted template engine sitting between user input and dangerous sinks. Taint flows through a probabilistic model, not a deterministic function.
LLM06 — Insecure Plugin Design	A05 — Security Misconfiguration, A08 — SSRF	Agent tools create new permission surfaces. A plugin granted file-system access and prompted via injection becomes an SSRF + file-write chain.
LLM07 — System Prompt Leakage	A02 — Cryptographic Failures	System prompts are often treated as secrets but are stored in plaintext in source code and sent to external APIs. Extraction is trivial.
LLM08 — Excessive Agency	A01 — Broken Access Control	The LLM is the new privileged user. A model with tool access can take real-world actions based on attacker-controlled instructions. There is no traditional access control equivalent for “the AI decided to do this.”
LLM09 — Misinformation	N/A	No OWASP 2021 analog. LLMs generate plausible-but-false content with high confidence. Downstream security decisions made on hallucinated data are a new risk class.
LLM10 — Unbounded Consumption	A04 — Insecure Design	Cost-based DoS via token generation. Traditional DoS is bandwidth/CPU. LLM DoS is dollars-per-token. Rate limiting is necessary but insufficient if context windows are unbounded.

What’s genuinely new

Non-determinism breaks signature-based detection

Traditional injection attacks produce predictable exploit strings. SAST can flag "SELECT * FROM users WHERE id=" + input because the structure is deterministic. But "You are a {user_role} assistant." being vulnerable depends on what user_role contains at runtime, and the exploit can be phrased in a thousand semantically equivalent ways. Signature-based SAST tools can detect the structural pattern (tainted variable in system role), but they cannot reason about whether a given string is a “safe” persona or a “malicious” instruction override — because the LLM can’t either.

Training data and embeddings are new attack surfaces

Traditional AppSec doesn’t model the training pipeline as an attack surface. In LLM applications, the training data, fine-tuning examples, and vector database contents are all potential injection points. A poisoned embedding in a vector store achieves indirect prompt injection at scale — every user who triggers a similarity search on that embedding receives the injected instruction. This attack surface doesn’t appear in any threat model built for a traditional web application.

Agentic systems collapse application/auth boundaries

In a traditional three-tier web application, the application tier enforces business logic and the database tier enforces data access. An LLM agent with tool access to both tiers can bypass both — it can query the database directly, call external APIs, send emails, and write files, all based on a prompt that an attacker may have influenced. The principle of least privilege still applies, but the “principal” is now a probabilistic system that cannot reliably say no.

What stays the same

The OWASP LLM Top 10 does not make the traditional Top 10 irrelevant. LLM applications still have:

Input validation requirements — though the definition of “valid” is harder to specify for natural language
Least privilege — agents and plugins should have minimal permissions
Secret management — API keys must not be hardcoded, regardless of whether they reach the LLM
Logging hygiene — log retention, access controls, and redaction requirements are unchanged
Dependency hygiene — pip audit and safety still apply to Python LLM applications
Parameterized queries — SQL queries built from LLM output must still be parameterized

What it means for your AppSec program

Update your security program to address LLM-specific risks without abandoning existing controls:

Add LLM-specific SAST to your CI pipeline (llmarmor scan ./src) alongside existing SAST tools
Threat-model agentic flows explicitly — map every tool, its permissions, and the blast radius of a prompt injection attack that reaches it
Add a prompt review step to code review — treat system prompts as security-sensitive code artifacts
Enforce PII redaction before any prompt is sent to an external LLM API
Add max_tokens linting to catch unbounded consumption patterns
Treat LLM output as untrusted input in all code reviews — flag any LLM response reaching eval(), SQL, or HTML sinks
Rotate API keys after any incident where source code containing keys was exposed
Add LLM-specific sections to your threat model template and security review checklist

Scan for LLM-specific vulnerabilities

LLMArmor is the SAST equivalent for LLM applications — the same concept as Semgrep or Bandit, but with rules built specifically for the OWASP LLM Top 10:

pip install llmarmor
llmarmor scan ./src

It detects LLM01, LLM02, LLM05, LLM06, LLM07, LLM08, and LLM10 using regex and AST taint analysis. It produces SARIF output for GitHub Code Scanning integration and exits with structured codes for CI gating.

Frequently asked questions

Does the OWASP LLM Top 10 replace the regular OWASP Top 10?: No. LLM applications face both sets of risks. An LLM-powered web app still needs to protect against SQL injection, broken access control, and vulnerable dependencies — plus the LLM-specific risks. The OWASP LLM Top 10 is additive, not a replacement.
Which OWASP Top 10 risks still apply to LLM apps?: All of them, potentially. A01 (Broken Access Control) and A03 (Injection) are especially relevant — agent tool abuse and SQL injection via LLM output are both still injection/access control problems. A06 (Vulnerable Components) applies to LLM SDKs and model dependencies. A09 (Logging Failures) applies to prompt and response logging. Treat traditional OWASP risks as a baseline and LLM-specific risks as additions.
Do SAST tools like Semgrep or CodeQL detect LLM vulnerabilities?: Not directly. Semgrep and CodeQL can be extended with custom rules, but they don't ship with LLM-specific patterns out of the box. They don't understand system prompt semantics, LLM output as a taint source, or agent tool permission models. LLMArmor is purpose-built for these patterns. You can run both — Semgrep/CodeQL for traditional web risks and LLMArmor for LLM-specific risks.
What new threat models do LLM apps introduce?: Three major new threat models: (1) Prompt injection — an attacker controls application behavior through natural language rather than code. (2) Training/RAG data poisoning — the model's knowledge base is an attack surface. (3) Agentic privilege escalation — an LLM with tool access can take real-world actions based on attacker-controlled prompts, collapsing the traditional application/auth boundary.
How often is the OWASP LLM Top 10 updated?: The OWASP LLM Top 10 was first published in 2023 and updated for 2025. Given the pace of LLM development, updates are expected to be more frequent than the traditional OWASP Top 10 (which updates roughly every 3–4 years). Subscribe to the OWASP LLM project page or the project's GitHub repository for release announcements.
Is there a SAST tool specifically for the OWASP LLM Top 10?: Yes — LLMArmor is a free, open-source Python SAST tool built specifically for the OWASP LLM Top 10. It covers LLM01 through LLM10 (excluding LLM03, LLM04, and LLM09 which require runtime analysis), using regex and AST taint analysis. Install with pip install llmarmor.

OWASP LLM Top 10 Guide Complete developer guide to all 10 LLM risks.

OWASP Coverage Reference Rule-by-rule breakdown of LLMArmor's detection coverage.

LLM01: Prompt Injection The most critical LLM risk — exploits and defenses.

LLM02: Sensitive Information Disclosure API key hygiene, PII redaction, and system prompt protection.

LLM05: Improper Output Handling RCE and SQLi via LLM output — with CVE examples.

LLMArmor vs garak Static analysis vs dynamic red-teaming for LLM security.