OWASP LLM Top 10 & Prompt Attacks

The standard reference taxonomy for LLM application vulnerabilities, and the attack family that's genuinely new relative to classical application security: attacks that work entirely through natural-language input, with no code injection or exploit in the traditional sense at all.

Intuition: One Structural Gap, Many Named Vulnerabilities

Nearly every vulnerability on this page is a variation on the same root cause, not fifteen unrelated things to memorize: LLM systems have no hard, mechanical separation between instructions (trusted, meant to be obeyed) and data (untrusted, meant to be processed, never obeyed) the way SQL has between code and a parameterized value. Compare them directly before anything else:

Everything below — prompt injection, jailbreaks, insecure output handling, excessive agency, data exfiltration, tool abuse — is a specific consequence of that one blurred boundary, approached from a slightly different angle each time.

The OWASP LLM Top 10

The OWASP Top 10 for LLM Applications is the community-standard taxonomy (maintained by the same organization behind the well-known web-application OWASP Top 10), covering: prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. Treat it the way the classical web OWASP Top 10 is treated in application security — a baseline checklist every LLM-facing system should be reviewed against before shipping, not an exhaustive list that guarantees safety once satisfied. This page and Model & Data Attacks cover most of these categories in depth; a few (denial of service, overreliance) are addressed by the general Production Reliability and AI Safety material elsewhere on the site.

Prompt Injection: Direct vs. Indirect

The foundational LLM vulnerability, and the clearest instance of the blurred boundary above:

• Direct prompt injection: a user directly types instructions intended to override the system prompt — the simplest form, and the one most safety training and guardrails specifically target.
• Indirect prompt injection: the malicious instructions arrive not from the user's own message, but embedded in content the model retrieves or processes — a webpage the model is asked to summarize, a document retrieved by RAG, an email an agent is asked to read. This is the more dangerous variant in practice, exactly as shown above: the user who triggers the attack often isn't the attacker and has no idea anything malicious happened.
• Why it's structurally hard to fully solve: unlike SQL injection (solved definitively by parameterized queries), there's no equivalently clean separation for natural language. Mitigation is therefore layered and probabilistic, not a single fix — see the defense-in-depth diagram below.

Jailbreaks

Prompts specifically crafted to bypass a model's safety training — role-play framings, encoding tricks (asking for a harmful response encoded to evade pattern-matching filters), or multi-turn manipulation that gradually shifts context across a conversation until a request that would be refused directly gets answered. An ongoing arms race: newer jailbreak techniques get discovered, model providers patch against them via safety fine-tuning, and the cycle continues — defense-in-depth (model-level safety tuning plus system-level input/output classifiers, not relying on either alone) is the realistic posture, not "solved once."

Insecure Output Handling

Treating an LLM's output as automatically safe to use downstream — rendered directly as HTML (enabling XSS if the model's output is attacker-influenced), executed directly as code, or used to construct a database query — is the LLM-era version of trusting unsanitized user input, with the added wrinkle that the "input" being trusted is model output that was itself potentially influenced by untrusted content upstream. The fix is the same as classical output-encoding/sanitization discipline: never treat generated content as safe-by-construction for whatever context it gets used in next.

Excessive Agency

Giving an LLM-based agent (see Agent Architectures) more real-world capability than a given task actually requires. The risk compounds directly with prompt injection — the exact same injected instruction has a radically different worst case depending on what the agent is actually permitted to do:

The fix is the same least-privilege principle as IAM (see Security & Reproducibility), applied to tool access: scope exactly which tools an agent can invoke for a given task, require human-in-the-loop approval for costly-to-reverse actions, and never grant broad, standing capability "just in case."

Data Exfiltration via Generated Output

A specific, sneaky consequence of prompt injection worth calling out on its own: an attacker doesn't need to breach a database directly if they can convince the model (via an injected instruction) to include sensitive data — from its context window, a retrieved document, or conversation history — in its own generated output, especially if that output is then rendered as a clickable link or an image URL to an attacker-controlled server. Defending against this means restricting what a model is allowed to output in sensitive contexts (blocking auto-rendered links/images from model output, or requiring explicit allowlisting of output domains) in addition to input-side defenses.

Tool Abuse in Agentic Systems

Beyond excessive agency's "too much capability granted," tool abuse covers an agent being manipulated into misusing a tool it was legitimately granted — calling a legitimate, appropriately-scoped tool with attacker-influenced arguments. Mitigations: validating tool-call arguments against expected patterns/schemas (not just that a call is well-formed JSON, but that its values look sane for the context — see MCP Protocol Deep Dive — Tool Discovery and Schemas), and treating any tool-call arguments that were influenced by untrusted content with the same suspicion as the content itself.

No Single Fix: Defense in Depth, Quantified

Given the structural gap this page opened with, every mitigation above is partial by itself. Toggle real layers on and off and watch the combined real probability of catching an attack change:

Code: A Tool-Call Argument Sanity Check

The concrete version of "validating that a call's values look sane," applied to the send-email example from tool abuse above:

import re

ALLOWED_RECIPIENT_DOMAIN = "@yourcompany.com"

def validate_tool_call(tool_name: str, args: dict) -> bool:
    if tool_name == "send_email":
        recipient = args.get("to", "")
        # Well-formed JSON isn't enough -- check the VALUE against context.
        if not recipient.endswith(ALLOWED_RECIPIENT_DOMAIN):
            raise ValueError(f"Blocked: recipient {recipient!r} outside allowed domain")
    return True

Next: Model & Data Attacks — attacks that target the model artifact and training data directly, rather than working through the model's normal input/output interface.