LLM01 prompt injection: how it works, with real examples

Prompt injection happens when text given to a language model changes its behavior in ways its builders did not intend. It sits at LLM01 in the OWASP Top 10 for LLM applications because models cannot reliably separate instructions from data. You reduce the damage with limits on what the model can do, since you cannot fully prevent it.

What are the two types?

OWASP defines direct prompt injection as a user's own prompt altering the model's behavior, whether intentionally or not. Indirect prompt injection happens when the model accepts input from external sources such as websites or files that contain instructions the model then follows.

The distinction matters for defenders. Direct injection comes from a person at the keyboard. Indirect injection comes from content your system fetched on someone's behalf, including content written by third parties months earlier.

What do real examples look like?

OWASP lists scenarios that show the range:

• A support chatbot is told to ignore its rules, query private data and send email, which works when the bot has those abilities.
• A webpage contains hidden instructions. A model asked to summarize it adds an image link that leaks the conversation.
• A tampered document in a retrieval repository steers the model toward misleading answers.
• A job posting asks employers to flag AI-written applications, and a candidate's resume, written with an LLM, triggers the check. OWASP calls this unintentional injection, since no attacker was involved.
• OWASP cites CVE-2024-5184, a vulnerability in an LLM-powered email assistant that allowed access to sensitive information and editing of email content.

None of these needs cleverness. They need a model with access to something valuable and an input channel that someone else controls.

The UK NCSC makes a useful point here. Prompt injection is not like SQL injection, because SQL injection can be fixed with parameterized queries that separate data from instructions, and LLMs enforce no such separation. The NCSC describes the model as an inherently confusable deputy, and says defenders can at most reduce likelihood and impact.

What reduces the damage?

OWASP states it is unclear whether fool-proof prevention exists and lists measures that lower impact:

1. Constrain the model's role and behavior in the system prompt.
2. Define expected output formats and validate them with deterministic code.
3. Filter inputs and outputs for disallowed content.
4. Enforce least privilege: keep functions in application code and give the model only the access it needs.
5. Require human approval for privileged operations.
6. Segregate and label untrusted external content.
7. Test adversarially, treating the model as an untrusted user.

The NCSC adds a design rule worth printing: when a model processes information from a party, its privileges should drop to that of the party. It also advises logging inputs, outputs, tool use and API calls, since failed tool calls may show someone probing.

What to do

1. List every input channel your LLM app reads: chat, files, web pages, emails, tickets, repositories.
2. Mark each channel as trusted or untrusted, and treat untrusted content as data only.
3. Inventory every tool the model can call and remove what it does not need.
4. Put a human approval step in front of sending, deleting, paying or sharing.
5. Validate outputs with code before they reach another system.
6. Log prompts, retrieved content and tool calls with user identity.
7. Add prompt injection cases to your regular test suite, using harmless marker text rather than real attack tooling.
8. Avoid relying on a single product that claims to stop prompt injection.

Quick check

Sources

• OWASP GenAI: LLM01 Prompt Injection, fetched 18 October 2026.
• NCSC: Prompt injection is not SQL injection, fetched 18 October 2026.

Last reviewed: 18 October 2026.