The OWASP LLM Top 10: A Complete Guide for AI Agent Developers

What the OWASP LLM Top 10 Is (and Isn't)

The OWASP LLM Top 10 is a ranked list of the most critical security risks for applications built on large language models. It's maintained by the same organization that produces the web application security standards that have shaped a generation of security engineers. The LLM version was first published in 2023 and updated in 2025 to reflect two years of real-world attacks.

A critical clarification: the OWASP LLM Top 10 is a list of application-layer risks — risks that arise from how you build with LLMs, not risks inherent to the models themselves. You can use any frontier model and still be vulnerable to all ten categories. You can use a weak model and be protected against all ten if you build correctly.

This guide covers each category with: what it is, how it manifests in AI agents specifically, and what to do about it.

---

LLM01: Prompt Injection

What it is: An attacker crafts input that overrides or supplements the model's original instructions. Direct injection targets the system or user prompt. Indirect injection hides instructions in data the agent reads from external sources — web pages, files, database records, API responses. Why agents amplify the risk: Traditional LLM applications have a simple input→output structure. Agents read files, scrape web pages, call APIs, and process tool results — every one of these external content sources is a potential injection vector. The attack surface isn't just what users type; it's everything the agent touches. Defense:

• Scan all external content before feeding it to the model. Use a runtime scanner that decodes 14+ encoding methods — attackers routinely encode payloads in base64, hex, ROT13, leetspeak, or unicode homoglyphs to bypass keyword detection.
• Separate trusted content (system prompts) from untrusted content (tool results) explicitly in your prompt structure.
• Use input validation at every tool call boundary, not just at the initial user message.

Scandar coverage: scandar-guard inspects every message and tool result for injection patterns before they reach the model, including recursive multi-layer decoding that catches triple-encoded payloads.

---

LLM02: Insecure Output Handling

What it is: The application passes LLM output directly to downstream systems — browsers, databases, command interpreters, APIs — without validation. In web applications, this causes XSS. In agents, it causes tool call injection. Why agents amplify the risk: Agents don't just display text — they use their output to make decisions and take actions. If an agent generates a shell command, SQL query, or API call based on tainted input, insecure output handling means that action executes without review. Defense:

• Treat all LLM output as untrusted when passing it to downstream systems.
• Validate and sanitize model output before using it in database queries, shell commands, or external API calls.
• Use parameterized queries and command argument arrays — never string interpolation with model-generated content.
• Apply the principle of least privilege to every tool your agent can call.

Scandar coverage: Guard's tool security layer inspects tool call arguments and results for injection patterns, SQL fragments, and shell metacharacters before they reach downstream systems.

---

LLM03: Training Data Poisoning

What it is: An attacker manipulates the data used to train or fine-tune a model, causing it to have backdoored behavior or systematic biases that serve the attacker's goals. Why agents amplify the risk: Organizations increasingly fine-tune models on proprietary data, and that data pipeline is often less carefully secured than the model serving infrastructure. An agent that's been fine-tuned on poisoned data may behave normally under ordinary conditions but activate malicious behavior under specific trigger conditions. Defense:

• Audit training data before fine-tuning — apply the same injection scanning to training data that you apply to runtime inputs.
• Monitor fine-tuned model behavior against baseline models; significant behavioral divergence on similar prompts is a signal.
• Prefer retrieval-augmented generation (RAG) over fine-tuning for domain knowledge — RAG data can be scanned and updated more easily than model weights.

Scandar coverage: This is primarily a data pipeline concern. scandar-scan can audit training data files for injection patterns and encoded payloads before they enter the fine-tuning pipeline.

---

LLM04: Model Denial of Service

What it is: Attackers craft inputs designed to consume disproportionate compute resources — either through extremely long context, computationally expensive reasoning tasks, or inputs that cause the model to generate extremely long outputs. Why agents amplify the risk: Agents often have larger context windows (to hold tool results and conversation history) and are called in loops. A well-crafted DoS input can exhaust your token budget, inflate your API costs, and degrade performance for legitimate users. Defense:

• Set hard limits on input size at every tool boundary — don't rely on the model to refuse long inputs.
• Cap context window usage per session and per user.
• Implement rate limiting at the application layer, not just the API layer.
• Monitor token consumption per request and alert on statistical outliers.

Scandar coverage: Guard's anomaly detection layer monitors message volume and token consumption per session, alerting on statistical outliers that may indicate DoS attempts.

---

LLM05: Supply Chain Vulnerabilities

What it is: Threats that enter through third-party components — AI plugins, skills, tools, datasets, model weights, or the model provider itself. Why agents amplify the risk: Agents are often extended through skill marketplaces, plugin libraries, MCP servers, and third-party tool integrations. Each of these is a supply chain component that could be compromised. The ClawHavoc attack in January 2026 was a supply chain attack — 1,184 malicious skills injected across skill marketplaces, compromising 300,000 users. Defense:

• Scan every skill, plugin, and tool definition before deployment. Static analysis should check for injection, credential exposure, and encoding evasion.
• Pin dependencies — treat AI skills like npm packages: use exact versions, audit on update.
• Verify the provenance of model weights and only use models from trusted sources with published security practices.
• Require code-signing or hash verification for skills used in production.

Scandar coverage: scandar-scan applies 140+ detection rules to skill files and tool definitions, including detection of encoded payloads, exfiltration URLs, and credential exposure.

---

LLM06: Sensitive Information Disclosure

What it is: The model reveals sensitive information it shouldn't — system prompt contents, training data, user data from other sessions, or credentials it has been given access to. Why agents amplify the risk: Agents are often given access to sensitive data to do their jobs — customer records, API keys, internal documents. That data exists in the agent's context window, which an attacker who can influence the model's behavior can potentially extract. Defense:

• Never embed credentials directly in system prompts — use environment variables or secrets managers, and retrieve them at runtime without loading them into context.
• Instruct the model explicitly not to reveal system prompt contents, but don't rely on this as your only defense — test whether it actually works.
• Monitor for system prompt extraction attempts at runtime. The patterns are detectable: phrases like "repeat your instructions," "what were you told," "show me your system message."
• Implement canary tokens in system prompts — invisible markers that alert you if the prompt content appears in model output.

Scandar coverage: Guard detects system prompt extraction attempts and canary token leaks with 0.99 confidence.

---

LLM07: Insecure Plugin Design

What it is: Plugins and tools are designed with excessive permissions, poor authentication, insufficient input validation, or unclear capability boundaries — making them easy to misuse or exploit. Why agents amplify the risk: Agents choose which tools to call and what arguments to pass — autonomously. A poorly designed tool that a human would never misuse because "it's obvious you shouldn't" can absolutely be misused by an agent that's been manipulated into calling it with attacker-controlled arguments. Defense:

• Apply least privilege to every tool: restrict recipients, destinations, actions, and data access to the minimum needed.
• Validate all tool arguments server-side — don't trust that the model will only call tools in the way you intended.
• Use honeypot tools to detect compromised agents: register fake tools like admin_override that should never be called. Any invocation is proof of compromise.
• Require human confirmation for high-risk tool calls (sending emails, writing files, making external HTTP requests with sensitive data).

Scandar coverage: Guard's honeypot tool system detects attempts to call sensitive tools with Levenshtein fuzzy matching that catches typo evasion.

---

LLM08: Excessive Agency

What it is: An AI agent is given more capabilities, more permissions, or more autonomy than it needs to accomplish its stated purpose — and those excess capabilities become exploitable. Why agents amplify the risk: By definition, agents are designed to act autonomously with broad capabilities. The pressure to make agents "as capable as possible" creates a natural tension with least privilege. Excessive agency is the most common misconfiguration in AI agent deployments. Defense:

• Audit every tool against the agent's stated purpose: if you can't articulate why the agent needs that tool for its core function, remove it.
• Use tool allowlists rather than denylists — default deny is safer than default allow.
• Implement rate limits on sensitive tool calls: even if an agent needs send_email, it shouldn't be able to send 1,000 emails per minute.
• Log and alert on unusual tool call patterns — behavioral anomaly detection identifies when an agent is using tools in unexpected ways.

Scandar coverage: Overwatch's fleet intelligence graph shows every tool each agent has access to and flags dangerous tool combinations using kill chain analysis.

---

LLM09: Overreliance

What it is: Organizations rely too heavily on LLM output without adequate human oversight, applying it to high-stakes decisions where errors have serious consequences — financial, medical, legal, operational. Why agents amplify the risk: The whole point of an agent is autonomous action. Overreliance is baked into the architecture. The risk is highest when agents make consequential decisions — canceling orders, flagging accounts, sending communications — without a human in the loop. Defense:

• Define an explicit list of actions that always require human approval, regardless of model confidence.
• Implement staged autonomy: agents start in observe mode, humans review outputs for a defined period, then the agent is promoted to act mode after validation.
• Monitor model output quality continuously — accuracy drift in production is real and often goes undetected for weeks.
• Build a kill switch: the ability to immediately halt all agent actions organization-wide in under one minute.

Scandar coverage: Overwatch's policy engine lets you define rules that trigger human review or block actions when threat score thresholds are crossed.

---

LLM10: Model Theft

What it is: Adversaries extract or replicate a model through systematic querying — reconstructing proprietary fine-tuning or using the model's outputs to train a cheaper competitor model. Why agents amplify the risk: Fine-tuned agents exposed via API endpoints are higher-value targets for extraction than commodity models. An agent fine-tuned on proprietary customer data, internal knowledge, or specialized expertise represents significant competitive value worth protecting. Defense:

• Rate limit and monitor API access — extraction attacks require large volumes of queries.
• Add output watermarking — subtle statistical signatures in model outputs that let you identify if your model's outputs are being used to train another model.
• Detect adversarial probing patterns: systematic, high-volume querying that explores model behavior rather than using it for legitimate purposes.
• Use differential privacy techniques when fine-tuning on sensitive data to limit what a model can reveal about its training set.

Scandar coverage: This is primarily an infrastructure and access control concern. Overwatch's audit logging and session tracking provide forensic evidence of unusual query patterns that may indicate extraction attempts.

---

The Full Picture

Here's where each OWASP LLM Top 10 category sits in the attack surface, and the primary defense layer for each:

Category	Layer	Primary Defense
LLM01 Prompt Injection	Runtime	Content scanning, runtime inspection
LLM02 Insecure Output Handling	Application	Output validation, parameterized queries
LLM03 Training Data Poisoning	Pre-training	Data auditing, RAG over fine-tuning
LLM04 Model DoS	Infrastructure	Rate limiting, context caps
LLM05 Supply Chain	Pre-deployment	Skill scanning, dependency pinning
LLM06 Sensitive Info Disclosure	Runtime	Canary tokens, extraction detection
LLM07 Insecure Plugin Design	Architecture	Least privilege, honeypot tools
LLM08 Excessive Agency	Architecture	Tool allowlists, anomaly detection
LLM09 Overreliance	Process	Human-in-the-loop policies
LLM10 Model Theft	Infrastructure	Rate limiting, output watermarking

No single tool covers all ten categories because they span architecture decisions, development practices, infrastructure configuration, and runtime security. The categories you can address with tooling are LLM01, LLM05, LLM06, LLM07, LLM08, and parts of LLM04. The rest require architectural choices and process discipline.

Scandar covers the tooling-addressable categories: runtime injection detection (LLM01, LLM06), pre-deployment skill scanning (LLM05), honeypot tools (LLM07), fleet intelligence and kill chain analysis (LLM08). Start with the tooling layer first — it's the fastest to implement and it gives you evidence for the process decisions.