Working through the OWASP Top 10 for LLM Applications

Teams are building and shipping LLM applications quickly. Comprehensive security practice for them has not spread at the same rate.

The OWASP Top 10 for Large Language Model Applications exists to close that gap — mapping the distance between ordinary application security principles and the problems LLMs introduce that those principles do not cover.

Here is each item, framed around how it shows up in a real application and what to do about it first.

LLM01: Prompt injection

Top of the list, unsurprisingly. Malicious input that makes the model behave in ways it was not meant to.

Two forms:

• Direct — the attacker overrides or exposes the system prompt. Often called jailbreaking
• Indirect — the attacker plants instructions in a source the model will read (a web page, a file) and the model treats them as commands

The danger escalates sharply when the prompt path is connected to a data store or backend, because now you have a route to unauthorised access and privilege escalation.

In priority order:

1. Access control on the backend. Give the LLM its own token, with least privilege
2. Require explicit human approval for irreversible actions like deletion
3. Do not drop untrusted content into prompts unexamined

Input filtering — blocklists, topic classification — is worth adding, but it is a supporting layer. It is not a reason to skip the access control.

LLM02: Insecure output handling

Passing model output into a function, shell, SQL query or HTML without validating it first.

Natural-language querying is a genuinely good experience to build. But since the prompt can steer the model, the output has to be treated as untrusted input. Feed model output to eval and you have built arbitrary code execution.

The fix is conventional: validate and escape according to the destination, and separate execution privileges.

LLM03: Training data poisoning

Injecting malicious data into training or fine-tuning sets to distort the model’s behaviour itself.

What makes this hard is that there is nothing to see at runtime. Defences are provenance verification for your data, control over the ingestion pipeline, and behavioural testing after training.

LLM04: Model denial of service

Flooding the system with computationally expensive requests to exhaust capacity or deliberately inflate costs. Because per-request cost is high, this works as a financial attack, not just an availability one.

Rate limiting, input length caps, and per-user cost ceilings.

LLM05: Supply chain vulnerabilities

Pre-trained models, datasets, plugins, libraries — an LLM application is largely assembled from other people’s artefacts. You need to be able to answer where a model came from and whether it has been tampered with.

Conceptually this is the familiar software supply chain problem. What is new is that models and datasets are now in scope.

LLM06: Sensitive information disclosure

The model emits confidential information from its training data. In practice this looks like an internally-trained model answering an unauthorised user’s question about internal matters.

Remove or mask sensitive fields before training, filter outputs, and revisit whether that data needed to be in the training set at all.

LLM07: Insecure plugin design

Plugins that fail to validate input properly, or run with more privilege than they need. The plugin is the boundary between the model and your backend — if it is loose, LLM01 and LLM02 convert directly into real damage.

Define parameter types and ranges strictly, and scope privileges per plugin.

LLM08: Excessive agency

The model has been given too much capability, permission or autonomy. Did the access granted so it could read email also let it send email? This becomes critical in agent architectures.

Keep capabilities minimal. Put a human in the loop for high-impact actions.

LLM09: Overreliance

Accepting output without verification. This is a process failure rather than a technical vulnerability, which is exactly why it gets overlooked.

Design on the assumption that output is uncertain, and build human review into decisions that matter.

LLM10: Model theft

Theft of proprietary model weights, or replication of behaviour through bulk API querying (model extraction). Beyond the intellectual property loss, a stolen model gives an attacker an offline environment to develop attacks against you in.

Access control, rate limiting, and monitoring for anomalous query patterns.

The point

Read the list end to end and about half of it is applied conventional security. Least privilege, validating input and output, managing dependencies — unchanged.

The genuinely new thinking sits in prompt injection, training data poisoning and excessive agency. The principle that takes the most adjustment is treating model output as untrusted input, because it inverts where most developers instinctively place the trust boundary.

Start by auditing which of the ten your own application is currently exposed to.