OWASP Top 10 for LLM Applications: What Every Enterprise Must Defend Against

The OWASP Top 10 for Large Language Model Applications is the first serious attempt to catalogue the security risks specific to LLM-powered systems. If you're deploying AI in a regulated enterprise — banking, healthcare, critical infrastructure — this isn't optional reading. It's your threat model.

But the OWASP list describes what can go wrong. This article focuses on how to defend against each vulnerability at the infrastructure level, mapped to the regulatory frameworks (EU AI Act, NIS2, DORA) that make these controls mandatory, not aspirational.

LLM01: Prompt Injection

The most discussed and least solved vulnerability. An attacker manipulates the LLM's behaviour by injecting instructions through user input (direct) or through data the LLM processes (indirect).

Infrastructure defences:

• Input sanitisation layer — a pre-inference gateway that detects and strips injection patterns before they reach the model. Not foolproof, but raises the bar significantly.
• Privilege separation — the LLM should never have direct access to sensitive operations. Tool calls go through an authorisation layer that validates actions against user permissions, regardless of what the model requests.
• Output validation — post-inference checks that verify model outputs conform to expected schemas before execution. An LLM suggesting a SQL query should have that query validated against an allowlist of operations.
• Instruction hierarchy — system prompts should be architecturally privileged over user inputs. Some frameworks now support this natively; for others, it must be enforced at the orchestration layer.

LLM02: Insecure Output Handling

LLM output is treated as trusted by downstream systems. If the model generates JavaScript, SQL, shell commands, or HTML that gets executed without sanitisation, you have a classic injection vulnerability — just with an LLM as the vector.

Infrastructure defences:

• Output encoding — all LLM outputs rendered in web interfaces must be HTML-encoded. All outputs used in database queries must be parameterised. This is web security 101, but teams forget it when the source is "their own AI."
• Content Security Policy — strict CSP headers prevent execution of LLM-generated scripts in the browser.
• Sandboxed execution — if the LLM generates code that must run (code assistants, data analysis), execute it in isolated containers with no network access and minimal filesystem permissions.
• Schema validation — define strict output schemas (JSON Schema, Pydantic models) and reject any model output that doesn't conform.

LLM03: Training Data Poisoning

Manipulation of training data to introduce backdoors, biases, or vulnerabilities into the model. For enterprises using fine-tuned models, this is a supply chain risk.

Infrastructure defences:

• Data provenance tracking — every piece of training data should have a documented origin, processing history, and quality score. This isn't just good practice; it's an AI Act requirement for high-risk systems.
• Data validation pipelines — automated checks for anomalies, distribution shifts, and suspicious patterns in training datasets before they reach the training pipeline.
• Access controls on training infrastructure — who can modify training data? Who can trigger fine-tuning runs? These should be as tightly controlled as production deployments.
• Model provenance — if using third-party or open-source models, verify model checksums and document the supply chain. SBOM (Software Bill of Materials) practices should extend to ML models.

LLM04: Model Denial of Service

Crafted inputs that cause the LLM to consume excessive resources — extremely long contexts, recursive generation, or inputs designed to maximise inference time.

Infrastructure defences:

• Input length limits — enforce maximum token counts at the API gateway, not at the model level. Reject oversized requests before they consume GPU resources.
• Request timeouts — hard timeouts on inference calls. If a request takes longer than N seconds, kill it. Agentic loops need iteration caps.
• Rate limiting — per-user, per-API-key, and per-IP rate limits at the inference gateway. Differentiate between authenticated and unauthenticated traffic.
• Resource quotas — Kubernetes resource limits on model serving pods. A single runaway request should not starve other workloads.
• Auto-scaling with ceiling — scale up to handle legitimate spikes, but set absolute maximums to prevent cost explosions from DoS attacks.

LLM05: Supply Chain Vulnerabilities

Compromised model weights, poisoned training pipelines, vulnerable dependencies in the ML stack, or malicious plugins/tools that agents interact with.

Infrastructure defences:

• ML-SBOM — maintain a software bill of materials that includes model provenance, framework versions, and dependency trees for the entire ML pipeline.
• Container image scanning — model serving containers should go through the same vulnerability scanning as application containers. GPU driver versions matter.
• Model signing — cryptographic signing of model artifacts. Verify signatures before deployment. This prevents tampering between training and serving.
• Plugin/tool sandboxing — for agentic systems, third-party tools and plugins must run in isolated environments with minimal permissions. One compromised plugin shouldn't compromise the agent.
• Dependency pinning — pin all ML framework versions. A malicious update to a popular library (like the PyTorch nightly incident) can compromise your entire pipeline.

LLM06: Sensitive Information Disclosure

The model reveals confidential data from its training set, RAG context, or system prompts. This includes PII leakage, proprietary data exposure, and system prompt extraction.

Infrastructure defences:

• PII detection on outputs — scan all model outputs for PII patterns (names, emails, phone numbers, addresses, financial identifiers) before returning to users. Redact or block.
• RAG access controls — retrieval must respect document-level permissions. User A should never see chunks from documents they don't have access to, even if those chunks are semantically relevant.
• System prompt protection — treat system prompts as secrets. Don't include sensitive information in system prompts; use them for behaviour instructions only. Sensitive context should come through authenticated retrieval.
• Differential privacy — for fine-tuned models trained on sensitive data, apply differential privacy techniques during training to limit memorisation of individual data points.
• Output logging with PII scrubbing — log model outputs for audit purposes, but scrub PII from logs. You need the audit trail without creating another PII exposure surface.

LLM07: Insecure Plugin Design

LLM plugins and tools accept unvalidated inputs from the model, have excessive permissions, or lack proper authentication. When the LLM calls a tool, it should go through the same security controls as any API call.

Infrastructure defences:

• Tool authentication — every tool/plugin call must include authentication credentials scoped to the requesting user, not a shared service account.
• Input validation on tools — tools must validate their inputs independently of the LLM. The model's output is untrusted input to the tool.
• Least privilege — each tool gets the minimum permissions it needs. A "search documents" tool should not have write access. A "send email" tool should not have access to the contacts database.
• Approval workflows — high-risk actions (financial transactions, data modifications, external communications) should require human approval, regardless of what the agent requests.
• Tool call logging — every tool invocation should be logged with the full context: who requested it, what the model generated, what the tool received, what it returned. This is your audit trail under DORA and NIS2.

LLM08: Excessive Agency

The LLM system has more capabilities, permissions, or autonomy than necessary. This is the agentic AI risk — systems that can take real-world actions with insufficient guardrails.

Infrastructure defences:

• Capability minimisation — start with zero capabilities and add only what's needed. If the use case is "answer questions about HR policies," the agent doesn't need email, calendar, or file system access.
• Action classification — categorise all available actions by risk level (read-only, write, financial, external communication) and apply proportional controls.
• Rate limits on actions — an agent that can send emails should have send limits. An agent that can modify records should have modification caps per session.
• Human-in-the-loop gates — for high-risk actions, require explicit human approval. The EU AI Act mandates human oversight for high-risk AI systems (Article 14). This is where you implement it.
• Session boundaries — agent sessions should have defined scopes, time limits, and action budgets. A runaway agent loop should hit a ceiling, not run indefinitely.

LLM09: Overreliance

Users trust LLM outputs without verification, leading to incorrect decisions, hallucinated citations, or fabricated data entering business processes.

Infrastructure defences:

• Confidence indicators — surface retrieval confidence scores and source attribution alongside model outputs. Users should see where the answer came from.
• Citation verification — for RAG systems, automatically verify that cited sources actually contain the claimed information. Flag ungrounded claims.
• Fact-checking pipelines — for high-stakes use cases (medical, legal, financial), route model outputs through automated fact-checking before presenting to users.
• Disclaimers and provenance — clearly mark AI-generated content. The AI Act requires this (Article 52). Implement it at the UI layer consistently across all AI touchpoints.
• Feedback loops — make it easy for users to flag incorrect outputs. Feed corrections back into retrieval quality monitoring and prompt engineering.

LLM10: Model Theft

Unauthorised access to proprietary model weights, fine-tuning data, or model behaviour through extraction attacks (querying the model systematically to reconstruct its capabilities).

Infrastructure defences:

• API authentication and authorisation — no anonymous access to model endpoints. Period. Even internal endpoints need service-to-service authentication.
• Query rate limiting — model extraction attacks require thousands of queries. Aggressive rate limiting makes extraction impractical.
• Output perturbation — for particularly sensitive models, add controlled noise to outputs that doesn't affect usefulness but makes extraction harder.
• Access logging and anomaly detection — monitor query patterns for extraction signatures: systematic variation of inputs, unusually high query volumes, automated access patterns.
• Model artifact security — model weights should be encrypted at rest, access-controlled, and never stored in general-purpose file shares. Treat them like source code — because they are.

Mapping OWASP LLM Top 10 to Regulatory Requirements

Building the Defence Stack

These 10 vulnerabilities have a common pattern: they're infrastructure problems, not model problems. You can't fix them by choosing a "more secure" model. You fix them by building the right controls around whatever model you deploy.

The defence stack for production LLM systems looks like this:

1. API Gateway layer — authentication, rate limiting, input validation, request logging
2. Pre-inference layer — prompt injection detection, input sanitisation, PII scanning, context curation
3. Inference layer — resource limits, timeouts, model isolation
4. Post-inference layer — output validation, PII redaction, schema enforcement, citation verification
5. Action layer — tool authentication, permission enforcement, human-in-the-loop gates, action logging
6. Observability layer — latency metrics, quality monitoring, drift detection, anomaly alerting, audit trails

Each layer is independent. Each layer assumes the others might fail. Defence in depth isn't a buzzword — it's the architecture.

The organisations that treat LLM security as an afterthought will learn the hard way. The OWASP Top 10 for LLM Applications gives you the threat model. The infrastructure is your response.