The OWASP Top 10 for LLM Applications (2025): an enterprise defense playbook

Prompt Injection

Prompt injection is the practice of crafting input - direct, from a user, or indirect, buried in a document, web page or tool result the model later reads - that overrides the system's intended instructions. In production, it fails quietly: a support bot starts following instructions embedded in a customer's message, or a document-summarization agent executes commands hidden in invisible text inside a file it was asked to summarize. Detection relies on logging the full prompt context the model actually received, not just the user-visible message, and running automated adversarial probes against every new prompt template before release. Effective mitigation is layered rather than a single filter: treat retrieved content and tool output as untrusted data, separate instructions from data with clear structural boundaries, give the model the least privilege it needs to complete a task, and require human or policy-engine approval before any high-impact action an injected instruction could trigger. No single filter stops every injection, so the programs that hold up over time combine architecture changes with continuous adversarial testing.

No single filter stops every injection, so the programs that hold up over time combine architecture changes with continuous adversarial testing.

Insecure Output Handling

This risk appears when an application trusts model output the same way it would trust output from a fully trusted internal service, then renders it in a browser, inserts it into a database query, or passes it to a shell or API without validation. In production, it shows up as cross-site scripting from a chatbot that echoes attacker-supplied markup, or an injection attack carried inside a natural-language-to-database feature. Detection means fuzzing the full round trip from model output to whatever executes or renders it, and reviewing any code path where generated text reaches a browser, interpreter or privileged API. Mitigation applies the same output-encoding and parameterization discipline used for any other untrusted input: encode before rendering, use parameterized queries rather than string-built ones, run generated code only inside a sandboxed, resource-limited execution environment, and apply schema validation to structured output before your application acts on it.

Training Data Poisoning

Poisoning targets the data used to pretrain, fine-tune or continually update a model, embedding biased behavior, hidden triggers or backdoors that activate only under specific conditions. In production, a poisoned model can behave normally on almost every input, then produce a harmful, biased or attacker-controlled response when a particular phrase or pattern appears, which makes the problem hard to notice through ordinary testing. Detection depends on provenance tracking for every training and fine-tuning dataset, statistical outlier analysis on data sources before they enter a training pipeline, and behavioral evaluation suites that specifically probe for anomalous, trigger-like responses. Mitigation starts with sourcing data from vetted, access-controlled pipelines, applying data sanitization and deduplication before training, and preferring retrieval-augmented approaches over frequent uncontrolled fine-tuning when the underlying data cannot be fully vetted. Any model accepted from a third party should go through its own security review before it is trusted in a production pipeline.

Model Denial of Service

LLM workloads are expensive per request compared to typical web traffic, which makes them an attractive denial-of-service target through resource exhaustion rather than raw request volume. In production, this looks like a handful of crafted prompts that trigger extremely long generations, recursive agent loops that keep calling tools and the model without making progress, or oversized context windows that quietly drive up latency and cost for every other user on a shared endpoint. Detection requires per-request cost and token tracking, with alerts on generation length, loop counts and latency outliers rather than only on raw request counts. Mitigation includes hard limits on input and output token counts, timeouts and step limits on any agent loop, rate limiting and cost quotas scoped per user or API key, and queuing or graceful-degradation strategies so one abusive workload cannot starve every other tenant on a shared inference endpoint.

Supply Chain Vulnerabilities

The LLM supply chain includes pretrained model weights, fine-tuning datasets, plugins, vector databases, orchestration frameworks and the open-source packages all of these depend on. A vulnerability or malicious component introduced at any point can compromise every application built on top of it. In production, this surfaces as a compromised dependency in an orchestration library, a model checkpoint downloaded from an unverified source, or a plugin with excessive permissions that was never properly reviewed. Detection means maintaining a software bill of materials for models and the frameworks around them, scanning dependencies continuously rather than only at release time, and verifying model checksums and provenance before deployment. Mitigation favors pinned, signed dependencies, sourcing models only from vetted registries with clear licensing and provenance records, and applying the same vendor risk assessment to AI component suppliers that your organization already applies to any other critical third-party software.

Sensitive Information Disclosure

Models can leak information in two directions: regurgitating sensitive data memorized during training, or exposing data an application fed into its context window, such as another user's records pulled into a retrieval-augmented prompt. In production, this appears as a model answering a question about one customer with details from a different customer's record, or revealing system prompts and internal business logic when asked the right way. Detection combines output scanning for personally identifiable information and secrets, canary-token testing to see whether a model will repeat planted sensitive strings, and regular prompt-leak probing against the deployed system prompt. Mitigation requires strict data segmentation so a given request can only retrieve data the requesting user is authorized to see, output filtering for sensitive data patterns before a response reaches a user, and minimizing how much sensitive data ever enters a prompt or context window in the first place.

Insecure Plugin Design

Plugins and tools extend a model's reach into real systems: email, databases, payment processors, internal APIs. When a plugin accepts free-form input from the model without validation, or exposes more capability than the use case requires, it becomes the weakest link in the chain. In production, an overly permissive plugin lets a model-generated instruction delete records, send unauthorized messages or query data outside its intended scope, often because the plugin trusted the model's output the same way it would trust a human operator's deliberate command. Detection means auditing every plugin's permission scope against what it actually needs, and testing plugins with adversarial inputs the same way you would test a public API endpoint. Mitigation applies strict input validation and schema enforcement at the plugin boundary, scopes each plugin to the minimum set of actions and data it requires, and requires explicit confirmation for any plugin action that is destructive, financial or otherwise irreversible.

Excessive Agency

Agentic systems that can plan, call tools and take multi-step actions are powerful, but excessive agency, granting an agent more autonomy, permission or reach than its task requires, turns small reasoning errors into real-world consequences. In production, this looks like an agent that was asked to draft a refund email instead issuing the refund itself, or a research agent given broad file-system or network access it did not need for its assigned task. Detection involves mapping every permission an agent actually exercises against the permissions it was granted, and flagging any action outside that expected set. Mitigation is primarily a design discipline: grant the minimum permissions needed for a specific task, require human approval for actions above a defined risk threshold, separate the ability to recommend an action from the ability to execute it, and log every tool call with enough detail to reconstruct exactly what the agent did and why.

Overreliance

Overreliance is an organizational risk as much as a technical one: treating model output as authoritative without adequate verification, oversight or user understanding of its limitations. In production, this shows up as generated code shipped without review, a summarization tool whose hallucinated details end up in a compliance filing, or operators who stop questioning an agent's recommendations because it is usually right. Detection is largely behavioral: track how often human reviewers actually edit or reject model output, and watch for declining review rates over time as a warning sign that scrutiny is eroding. Mitigation includes clear user-facing disclosure that content is AI-generated, mandatory human review gates for high-stakes outputs such as legal, medical or financial content, confidence signaling so users know when an answer is less certain, and ongoing training so the people working alongside these systems understand what the model is actually good and not good at.

Overreliance is an organizational risk as much as a technical one: treating model output as authoritative without adequate verification, oversight or user understanding of its limitations.

Model Theft

Model theft covers both outright exfiltration of proprietary model weights and the quieter risk of model extraction, where an attacker queries a model enough times to reconstruct a close functional copy or distill its capabilities into their own system. In production, warning signs include unusually high query volumes from a single account, systematic probing patterns that look like they are mapping the model's decision boundaries rather than using it normally, and abnormal API usage from credentials that should not need that volume of access. Detection relies on usage analytics tuned to spot extraction-style query patterns, not just raw rate limits, alongside strict access logging for anyone with direct access to model weights or fine-tuning pipelines. Mitigation includes watermarking or output rate limiting to make extraction economically unattractive, strong access controls and encryption around model artifacts at rest, and contractual and technical controls on any third party given API or weight access to a proprietary model.