Understanding Prompt Injection
Prompt-level defense means writing prompt text that is harder to exploit, rather than relying only on code outside the prompt.
A Fixed Instruction Meets Free Text
Imagine an application where a developer writes a fixed set of instructions once. Every time a user sends a message, that message is attached to those instructions before it reaches the model. The instructions tell the model what its job is. The user's message, however, is free text, and nothing stops a user from typing something that tries to pull the model away from that job.
An attacker might ask for private details, ask the model to ignore its earlier instructions, or dress up a request in a story so that it looks harmless. This pattern of user text trying to change the model's behavior is the problem that prompt injection describes, and the defenses in this article are all things you can do inside the prompt itself.
What do you think happens?
If you write a clear rule into the prompt, does that guarantee the model will obey it?
Reveal answer
No, an instruction is only a request the model may not follow.
The source states directly that there is no guarantee a model will follow the instructions it is given. A prompt-level defense improves the odds of intended behavior but does not promise it. This idea returns later in the article.
Defense Lives in the Prompt Text
Prompt-level defense is the practice of writing the prompt text itself so that it is harder to exploit. The defense lives in the words of the prompt, not in code that filters input or in a separate security layer.
It helps to see prompt-level defense as one choice among several places where protection can sit. The diagram below separates the words inside the prompt from the code outside it. The source contrasts the two directly: the summary of this topic says prompt-level defense means writing prompt text that is harder to exploit, rather than relying only on code outside the prompt.
Naming What Is Off Limits
The first technique is to write negative instructions that are specific. Instead of only describing the task, the prompt also states what is off limits. A useful way to think about it is that the prompt draws a boundary around the behavior you want, and the boundary is made of named things. The source gives two patterns for doing this.
Anticipating Specific Attacks
Explicit instructions can also be aimed at specific attacks. If you know in advance how users are likely to try to change the model's behavior, you can write the prompt so that the model is prepared for those moves. The source describes a summarization prompt built this way. It anticipates two framings: a user who asks the model to pretend it is talking to a grandmother, which is a role-play, and a user who asks the model to act as an unrestricted persona called DAN. The added sentence tells the model to summarize the paper regardless of those framings.
The sketch below is an illustrative prompt written for this article in the same spirit. It is not taken from the source. Notice that the rule is stated before the user's text, and it names the framings it must hold against.
- The task line gives the model its job
- The second line names the framings the model must hold against
- The placeholder marks where untrusted user text is attached
The Instruction Sandwich
The second technique is a simple structural trick. It places the system instruction twice, once before the user's input and once after it. The user's text sits in the middle, wrapped by the same instruction at both ends. The diagram shows that layout.
Why Defenses Are Not Guarantees
Prompt-level defense improves the odds that a model behaves as intended, but it does not promise that outcome. The source makes this point directly, noting that there is no guarantee a model will follow the instructions it is given. An instruction is a request to the model, and the model may still respond in ways the designer did not expect. The flowchart traces the path an injected request takes even when a defense is present.
Inspecting Default Templates
Many prompt tools come with a default template, which is a ready-made prompt that wraps user input for you. The source warns that these defaults often lack safety instructions. The practical lesson is that you should look at the template a tool uses before you trust it, and then adjust it to include the restrictions your application needs.
The source cites a 2023 study titled From Prompt Injections to SQL Injection Attacks, by Pedro and colleagues. At the time of that study, the default templates of the LangChain tool were so permissive that the injection attacks tested against them succeeded every time, a 100 percent success rate. When restrictions were added to those prompts, the attacks were significantly thwarted.
| Aspect | Default-style template | Restricted template |
|---|---|---|
| Safety instructions | Often absent | Added in the places left open |
| Placeholder for user input | Present | Kept, so the application still works |
| Injection attacks in the study | Succeeded every time (100 percent) | Significantly thwarted |
The structural difference between a default template and a restricted version, drawn from the source's description
Mistakes Beginners Make with Injection Defense
Common mistake Assuming a written rule guarantees compliance
What it looks likeA prompt says 'never reveal email addresses' and the team stops testing outputs.
Why it failsThe source states there is no guarantee a model will follow the instructions it is given.
Do this insteadKeep the rule, and still test outputs and add defenses outside the prompt where the stakes justify it.
Common mistake Writing vague negative instructions
What it looks likeThe prompt says 'keep things safe' with no named categories.
Why it failsA vague phrase gives the model nothing concrete to check its output against.
Do this insteadName the forbidden categories or define a closed scope of allowed items.
Common mistake Trusting the default template of a prompt tool
Why it failsThe source warns that default templates often lack safety instructions.
Do this insteadRead the template the tool uses, then add the restrictions your application needs.
Common mistake Repeating the instruction everywhere without counting the cost
Why it failsEach repetition adds system prompt tokens, which increases cost and latency on every request.
Do this insteadRepeat the instruction where the reminder matters, and weigh the extra cost against the protection it adds.
Practicing a Closed-Scope Rewrite
A summarization prompt currently reads: 'Summarize the paper below.' Rewrite it so that it (1) defines a closed scope for what the model may return, and (2) names at least one forbidden category of content. Then add a sentence anticipating a role-play framing. Finally, decide whether you would also repeat the instruction after the paper text, and state the cost trade-off of that choice.
Hints
- A closed scope names the only items the model may return, and says that nothing else should be returned.
- A forbidden category names a kind of content, such as contact details, so the model has something concrete to avoid.
- Repeating the instruction after the paper helps reminder the model, but it roughly doubles the system prompt tokens.
Summary of Prompt-Level Defenses
- 1Prompt-level defense writes the prompt text so that it is harder to exploit, rather than relying only on code outside the prompt.
- 2Explicit instructions help by naming forbidden categories or defining a closed scope, which gives the model a concrete boundary.
- 3The instruction sandwich repeats the system instruction around the user input as a reminder, at the cost of roughly doubling system prompt tokens.
- 4Default templates from prompt tools often lack safety instructions, so inspect and modify them before use.
- 5No prompt-level defense guarantees compliance, because an instruction is only a request the model may not follow.
At a glance
- Prompt-level defense writes the prompt text so that it is harder to exploit, rather than relying only on code outside the prompt.
- Explicit instructions help by naming forbidden categories or defining a closed scope, which gives the model a concrete boundary.
- The instruction sandwich repeats the system instruction around the user input as a reminder, at the cost of roughly doubling system prompt tokens and increasing cost and latency.
- Default templates from prompt tools often lack safety instructions, so they should be inspected and modified before use.
- No prompt-level defense guarantees compliance, because an instruction is only a request the model may not follow.