Wrapping untrusted code or logs in tags such as a code or document element helps the model tell your instructions from the material to analyze, and it improves answer quality. It is not a security boundary. Text inside the tags can still steer the model, so pair tagging with limited privileges and checks outside the model.
What tags are good for
Anthropic's prompting guidance says XML tags help the model parse complex prompts unambiguously, especially when a prompt mixes instructions, context, examples, and variable inputs. Putting each kind of content in its own tag reduces misinterpretation.
For security work that is a real benefit. A review prompt might carry a policy, a diff, and a list of known false positives. Without clear separation, the model can treat a line from the diff as part of the policy.
<instructions>Review the diff for authorization problems. Quote the code for each finding.</instructions>
<known_false_positives>Calls from the internal scheduler skip the user check on purpose.</known_false_positives>
<diff>
...untrusted change goes here...
</diff>
The guidance also suggests wrapping each document in its own element with source metadata, which helps when you compare several files and want findings to name the source.
What tags cannot do
The UK NCSC makes the key point: unlike SQL injection, where parameterised queries keep data separate from instructions, a language model has no such hard boundary, so prompt injection may never be fully mitigated. Its advice does include separating data from instructions, for example by wrapping external content in XML tags or marking it as data, but only as a way to make injection harder.
OWASP's cheat sheet says the same from another angle: prompt labels alone do not enforce the boundary between trusted instructions and untrusted data.
A hostile diff can include a closing tag followed by new instructions. It can also just say, in plain language, what it wants the reviewer to conclude. Escaping the closing tag helps a little and should not be your plan.
What to add
- Limit what the model can do. A review assistant that can only read and comment cannot be tricked into pushing code.
- Validate output in code. If you expect JSON with a fixed set of fields, reject anything else.
- Keep humans on consequential actions. Approval should name the operation, target, and arguments.
- Log inputs, outputs, and tool calls so odd behavior is visible.
A reasonable rule of thumb
Use tags for quality, and design as if the tags will fail. If a successful injection into the review step would still be harmless, the design is sound. If it would let an attacker approve a malicious change, fix the design before polishing the prompt.
For the broader question, see can a system prompt stop prompt injection.
Quick check
Should I escape angle brackets in pasted code?
It can reduce accidental tag confusion, but treat it as hygiene. A determined attacker does not need your tags to be broken.
Sources
- Prompting best practices (Anthropic)
- Prompt injection is not SQL injection (UK NCSC)
- LLM Prompt Injection Prevention Cheat Sheet (OWASP)
Last reviewed: 19 October 2026.
