Cybersecurity glossary

What is Prompt Injection?

Learn what prompt injection is, how untrusted text hijacks an LLM’s instructions, how it differs from jailbreaks, and which application controls reduce the risk in chat, RAG, and agent workflows.

AI and LLM securityUpdated August 13, 2026
Also known asLLM prompt injectionInstruction injectionPrompt hijacking

Definition

Prompt injection is an attack in which untrusted text is concatenated into an LLM’s context so the model follows the attacker’s instructions instead of the developer’s—changing answers, leaking context, or triggering tools.

Why prompt injection matters

Traditional apps parse structured input. LLM apps paste prose into a shared context window and hope the model will obey the developer’s section more than the user’s. Prompt injection is the name for when that hope fails.

OWASP ranks it as the top risk for LLM applications because it is not a single bug in one library. It is a property of mixing instructions and data in natural language. Any feature that lets untrusted text reach the model—chat, email summarization, ticket bots, browsing agents—inherits this class.

How prompt injection unfolds

1

Find a model-visible field

Chat input, uploaded files, retrieved docs, or tool results all land in the prompt.

2

Plant competing instructions

The attacker writes ‘ignore previous rules’ or hides the same idea in polite, task-shaped language.

3

Win the context window

Later, longer, or more specific text often outweighs a distant system prompt.

4

Change model behavior

The completion follows the attacker: leak context, change answers, or emit a tool call.

5

Ride application trust

If the app executes tool calls or renders HTML from the model, injection becomes action.

6

Stay inside normal UX

The user may only see a helpful answer while the side effect already happened.

Direct versus application impact

Policy override

The model drops product rules: tone, language, or ‘never mention internal tools.’

Secret extraction

Injection asks the model to repeat the system prompt, retrieved documents, or prior user data.

Tool abuse

The model emits arguments that send mail, create users, or query data the attacker could not call directly.

Downstream injection

Crafted Markdown, URLs, or code in the completion exploit browsers or interpreters after generation.

Why ‘just tell the model not to’ fails

ControlWhat it actually doesLimit
System prompt rulesSteers typical behaviorNot reliably stronger than user or document text
Input classifiersCatch known jailbreak and injection phrasesEasy to paraphrase, encode, or hide in files
Output filtersBlock secrets and disallowed topics in the replyMisses tool calls and encoded exfiltration
Least-privilege toolsCaps blast radius when the model is hijackedDoes not stop the hijack itself
Human approvalRequired for irreversible actionsUsers can be socially engineered by the same model
  • Assume any text the model can see may contain instructions, including files and web pages.
  • Keep authorization and business rules in application code, not only in the system prompt.
  • Give tools the narrowest APIs possible; prefer allowlisted IDs over free-form queries.
  • Separate untrusted retrieved content (for example with delimiters and ‘untrusted data’ labels) and never execute tools solely because the model asked.
  • Require out-of-band confirmation for email, payments, deletions, and credential use.
  • Detect unexpected tool sequences, destination URLs, and attempts to print hidden prompts.
  • Test with direct chat injection and with documents designed for indirect injection.
  • Treat successful injection as a product incident, not a user misusing a chatbot.

The practical takeaway

Prompt injection happens when untrusted language shares a context window with developer instructions and the model obeys the wrong author. You cannot fully parse it away the way you escape SQL.

Design LLM features so that even a fully hijacked model cannot exceed the user’s permissions, cannot fire high-impact tools alone, and cannot turn completions into executable output. Then add detection—knowing that filters are a speed bump, not a lock.

Related security terms

Frequently asked questions

What is prompt injection in simple terms?

The attacker writes text that the model treats as a new program. Because prompts are natural language, that text can sit in a chat message, a PDF, or a webpage the app retrieved.

How is prompt injection different from SQL injection?

SQL injection exploits a parser that mixes code and data. Prompt injection exploits a model that cannot reliably separate developer instructions from user or document text once both are in the same context window.

Is prompt injection the same as a jailbreak?

Jailbreaks target safety policies (produce disallowed content). Prompt injection targets application control (ignore the system prompt, leak secrets, call tools). The techniques overlap; the goals differ.

Can a stronger system prompt stop it?

Better instructions help against casual attempts, but they are not a security boundary. Models still follow later or more specific instructions, especially when tools or retrieved text reinforce them.

What does successful injection look like in a product?

The assistant ignores product rules, reveals the system prompt, emails data to an attacker, or calls a tool with attacker-chosen arguments while sounding helpful to the user.

Does using RAG make injection worse?

RAG adds indirect paths: any retrieved chunk can carry instructions. Direct chat injection still exists even without RAG.

How do you reduce prompt injection risk?

Minimize trust in model-followed policy, constrain tools, isolate untrusted content, require human approval for side effects, and monitor for unexpected tool calls and policy violations.

References

Explore authoritative guidance and frameworks related to prompt injection.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary