OWASP LLM Top 10: What API Builders Need to Know in 2026

The classic OWASP API Security Top 10 was written for traditional REST and GraphQL APIs. It covers broken object-level authorization, excessive data exposure, lack of rate limiting. Excellent baseline — but it doesn't address the attack surface that emerges when your API calls a language model.

The OWASP LLM Top 10 fills that gap. It was developed by a working group of AI security researchers and covers the vulnerability classes specific to LLM-integrated applications. Here's what each one means for API developers.

LLM01: Prompt Injection

Prompt injection is the LLM equivalent of SQL injection: user-controlled input manipulates the model's behavior in ways the developer didn't intend. In a direct prompt injection, the user inserts instructions into their input that override the system prompt. In an indirect injection, malicious instructions come from external content the model processes (web pages, documents, retrieved database content).

For API developers, the risk is concrete: prompt injection attacks can cause your API to leak system prompts, bypass authorization logic implemented in the prompt, exfiltrate other users' data (if you build user context into the prompt), and execute unintended tool calls in agent architectures.

Mitigations: Separate system prompt from user input architecturally. Use parameterized LLM calls where possible. Validate and sanitize all external content before including it in prompts. Implement output validation — don't trust model outputs blindly in automated pipelines.

LLM02: Insecure Output Handling

LLM output is attacker-controlled data. If your API takes model output and passes it to another system without sanitization — a shell command, a database query, a rendered HTML template — you have a secondary injection vulnerability. The LLM becomes a proxy for injection attacks.

This surfaces as XSS when model output is rendered in a browser, as SQL injection when output is interpolated into queries, as command injection in agent tools that execute shell commands, and as SSRF in systems that follow model-generated URLs.

Mitigations: Never pass LLM output directly to downstream systems without validation. Apply context-appropriate encoding (HTML escaping for web rendering, parameterized queries for databases). Treat LLM output with the same suspicion as user input.

LLM03: Training Data Poisoning

If your pipeline includes fine-tuning or retrieval-augmented generation (RAG), the data used to train or contextualize the model is part of your attack surface. An attacker who can influence your training data or knowledge base can embed backdoors, biases, or malicious instructions that activate under specific conditions.

For most API developers using foundation models via API, the relevant variant is RAG poisoning: if your RAG pipeline ingests user-controlled or externally-sourced content, that content can contain embedded prompt injections that execute when retrieved.

Mitigations: Audit data sources before ingestion. Maintain provenance tracking for RAG content. Apply content filtering to retrieved documents before including them in prompts.

LLM04: Model Denial of Service

LLM inference is expensive. Adversarially crafted inputs can maximize token consumption — either through very long inputs, inputs that cause maximum-length outputs, or recursive patterns that exhaust context windows. The result is degraded availability and increased costs.

Mitigations: Implement input token limits. Set maximum output token constraints. Rate-limit LLM calls per user/session. Monitor token usage and alert on anomalies. This pairs with the general API rate limiting requirements in the standard OWASP API Top 10.

LLM05: Supply Chain Vulnerabilities

LLM applications have a complex supply chain: foundation model providers, fine-tuning data, plugins, tools, and third-party libraries. Vulnerabilities in any of these affect your application. A compromised plugin or a model update that changes behavior can introduce security regressions.

Mitigations: Vendor-assess your LLM provider. Monitor model updates and test for behavioral changes. Apply the same dependency security practices you use for code dependencies to LLM plugins and tools.

LLM06: Sensitive Information Disclosure

Models memorize training data. They can be prompted to reproduce PII, credentials, proprietary content, or system configuration from their training corpus. In fine-tuned models trained on your company data, this risk is elevated — the model may reproduce internal documents, customer records, or API keys that were in the training set.

In production RAG systems, the model may reproduce sensitive retrieved content to users who shouldn't have access to it — effectively bypassing your access control layer if authorization isn't enforced at retrieval time.

Mitigations: Don't include sensitive data in training sets without careful evaluation. Enforce access control at retrieval, not just at display. Apply output filtering for known sensitive patterns (PII, credentials).

LLM07: Insecure Plugin Design

LLM plugins and tools (functions in the OpenAI sense, or tool calls in the Anthropic sense) allow models to take real-world actions: query databases, call APIs, send emails, execute code. If these tools don't implement proper authorization, the model can be manipulated (via prompt injection) into taking actions the user isn't authorized to perform.

An agent that can send emails on behalf of any user is a different security surface than an API endpoint that sends an email. The LLM is now the authorization decision-maker — and it can be manipulated.

Mitigations: Apply least-privilege to tool scopes. Require explicit user confirmation for high-impact actions. Validate tool inputs before execution. Log all tool calls with the prompt context that triggered them.

LLM08: Excessive Agency

This is the agentic AI version of privilege escalation. If an LLM agent has been granted too much autonomy — too many tools, too broad permissions, too little human oversight — a compromised or manipulated agent can cause damage proportional to those permissions.

Mitigations: Minimize agent tool access to what's needed for the task. Require human approval for irreversible actions. Design agents to confirm before significant actions. Implement agent scope boundaries at the API level.

LLM09: Overreliance

LLMs hallucinate. They produce confident, fluent, incorrect output. If your API uses LLM output for consequential decisions — medical advice, legal interpretation, financial recommendations, security policy — without validation, you're inheriting the model's error rate into your application.

Mitigations: Don't use LLM output for high-stakes decisions without human review or deterministic validation. Ground responses in verified data via RAG. Display appropriate uncertainty signals to users. Define use cases where LLM output must not be acted upon automatically.

LLM10: Model Theft

Fine-tuned models represent significant investment. Adversarial queries can extract enough information about model behavior to reconstruct a functional copy — particularly for specialized fine-tunes. For most API developers using commercial APIs, this risk sits with the provider. For those self-hosting fine-tuned models, it's relevant.

Mitigations: Rate-limit API queries. Monitor for systematic probing patterns. Apply access controls to model endpoints. If self-hosting, evaluate model watermarking.

What to Prioritize for API Builders

Not all 10 apply equally. For developers building APIs on top of commercial LLMs (OpenAI, Anthropic, Gemini), the most immediately relevant risks are:

• LLM01 (Prompt Injection) — the highest-impact, most widely applicable risk for any API that accepts user input and passes it to an LLM
• LLM02 (Insecure Output Handling) — critical for any API that pipes model output to other systems
• LLM04 (Model DoS) — relevant for any production API that charges for LLM-backed operations
• LLM06 (Sensitive Information Disclosure) — especially relevant for RAG architectures handling multi-tenant data
• LLM07 & LLM08 (Plugin Design / Excessive Agency) — critical for agentic systems with tool access

For comprehensive coverage of AI-specific API security, see Scantient's AI security features. For the underlying API security controls that still apply regardless of AI integration, the guide to securing AI app APIs covers authentication, rate limiting, and output validation in detail.