What Is Prompt Injection?

A concise definition

Prompt injection is a class of attack in which content that reaches a language model causes it to follow instructions the application owner did not intend. Application instructions, user input and external content become part of the same model-visible context, though providers may represent roles or channels differently. There is no reliable, built-in mechanism that keeps instruction-like text in data from influencing its behavior.

NIST describes prompt injection as an attack that exploits the concatenation of untrusted input with a prompt constructed by a higher-trust party such as the application designer. That wording captures the essential point: the problem arises where trust levels are mixed into one model-visible context.

Why prompt injection exists

Classic injection bugs such as SQL injection exist because code and data share a channel. For that class, parameterized queries provide a hard separation between code and data. Language models have no equivalent general-purpose separation: instructions and data are both natural language, and the model decides what to treat as an instruction based on learned behavior, not on a grammar the application controls.

Role markers, system prompts and formatting conventions help models prioritize, but they are behavioral signals. They shift probabilities; they do not create an enforced boundary. This is why the site treats every model-visible input as potentially influential, whatever its position in the prompt.

Direct and indirect prompt injection

The two common variants differ in where the influencing text comes from.

Indirect prompt injection is often the more serious concern in agentic systems, because the attacker does not need access to the application at all. For depth, see Direct Prompt Injection and Indirect Prompt Injection.

Instruction-control failure vs security impact

It helps to separate two questions that are often blurred:

1. Did the model follow unintended instructions? This is an instruction-control failure. It is a property of model behavior.
2. Did anything security-relevant happen as a result? This is security impact. It is a property of the application: what data was exposed, which action ran, where content went.

A chatbot with no tools, no private data and no persistent memory can be steered into odd answers with limited direct confidentiality or integrity impact. The same model inside an agent that can read mail and send messages can turn an identical control failure into data exfiltration. Severity is decided by architecture, not by the injected text.

Model-visible text does not become trusted

Content does not gain authority because it appears in the model's context, because it is placed near the system prompt, or because it was fetched by a trusted tool. A retrieved web page is still third-party content after it has been concatenated into a prompt. An email is still the sender's text, even if the mail server authenticated the sender.

Trust is a property the application establishes with system evidence: authenticated identity, verified origin, access-controlled storage, recorded provenance. Those facts live in application-controlled metadata, not in the prose the model reads. The Trust Boundaries and Model Context article develops this idea in detail, and Data Provenance covers how origin is recorded.

A model response is a proposal, not authorization

When a model suggests a tool call, a message, a file change or a destination URL, that output is a proposal. It is variable data shaped by everything in context, including content an attacker may have influenced. It does not become authorized because the model produced it confidently or because it matches a valid format.

Deterministic checks outside the model decide whether an action is permitted for this user, resource and destination. See Agent Authorization, Information Flow Control and Output Validation. Validation checks format; authorization checks permission; neither turns model-authored content into trusted content.

Where prompt injection becomes security-relevant

Prompt injection becomes materially relevant when the model's output can reach something that matters. Useful questions:

If the answer to all of these is no, the realistic impact is limited to the response itself. Each yes widens the blast radius and calls for a deterministic control at that point.

A short synthetic example

This example is conceptual. It shows the shape of the problem, not a technique.

The control failure happened inside the model. The security outcome was decided by the authorization check outside it.

Prompt injection vs jailbreak

The two terms overlap and are not used uniformly across vendors, researchers and standards bodies. A common working distinction:

• Jailbreaking usually refers to attempts to make a model ignore its safety behavior or usage policies, often by the person using it.
• Prompt injection usually refers to content that subverts the application's intended instructions, and it is especially relevant when that content comes from a third party.

Some sources treat jailbreaking as a form of prompt injection; others keep them separate. There is no universal terminology standard, so this site states which meaning it uses rather than claiming one is authoritative. What matters for security engineering is the same in both cases: where the text came from, and what the application lets the resulting output do.

See the dedicated comparison: Prompt Injection vs Jailbreaking.

Hidden context is not a secret

System prompts and other hidden instructions can sometimes be disclosed, inferred or partially reconstructed through model output. They should never contain credentials or act as the only control. See System Prompt Extraction for the full treatment.

Why defenses are layered

No single classifier, filter or prompt wording reliably separates instructions from data in natural language. Microsoft's guidance for indirect prompt injection recommends a defense-in-depth strategy that layers probabilistic and deterministic mitigations. The site follows the same principle:

1. 01
   Know the origin

   Record where each piece of content came from, outside model-visible text.

2. 02
   Observe

   Inspection and detection produce probabilistic signals that route, flag or narrow authority.

3. 03
   Constrain

   Least privilege limits which data and tools a workflow can reach at all.

4. 04
   Decide deterministically

   Authorization and information flow control decide each action and destination.

5. 05
   Handle output safely

   Output validation and sink-specific handling before output is used.

Common misconceptions

Try it in a controlled lab

The Direct Prompt Injection Basics lab is a guided simulation. It shows model-visible context, competing instructions and an authorization decision outside the model, without connecting to real models or systems. The Direct vs Indirect Prompt Injection lab then practices classifying scenarios by origin and path and judging impact as a separate question.

Standards and sources

Frequently asked questions