Tokenize user content with add_special_tokens=False so strings like <|system|> stay literal text instead of becoming the real special token ids that break the trust boundary.
Imagine a theater where saying the phrase 'lights out' really kills the stage lights, because the crew is trained to obey it. Now a heckler in the audience shouts 'lights out' and the room goes dark, because the crew could not tell the heckler apart from the director. The fix is a rule: anything an audience member says is just words, never a command. In a language model, the dangerous command-words are special tokens like the system marker. Setting add_special_tokens to False is that rule, so a marker typed by a user is treated as plain text rather than a real instruction the model obeys.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
This question rewards knowing the real API rather than the most security-sounding word. Three of the four options are fabricated parameter names chosen to look plausible, and only add_special_tokens=False exists and does the job. The lesson is that defending an LLM means understanding the exact layer where the risk lives.
Special Token Injection is not an exotic attack. It falls out of a default that is convenient for the common case and dangerous for the untrusted-input case. Walking through what the flag actually toggles makes both the answer and the defense pattern obvious.
The broader skill being tested is layer awareness. A security control only works if it operates where the attack does. STI resolves when text becomes token ids, so a defense that lives in the browser, in output formatting, or in an imagined safety mode cannot touch it. Recognizing that mismatch is what lets you reject three plausible decoys and keep the one real knob.
What add_special_tokens actually does
On a HuggingFace tokenizer, add_special_tokens is a boolean argument to encode() and to __call__(). It controls two related behaviors.
First, it decides whether recognized marker strings are promoted to their special token ids. With the flag True, a string like <|system|> that the tokenizer registers as special becomes the dedicated system id. Second, it decides whether sequence-boundary tokens such as BOS are auto-prepended.
The default is True because that is what you want when you are tokenizing a properly formed prompt that you assembled. The danger appears only when the text being tokenized is not yours, which is exactly the case for user messages.
A useful way to internalize the flag is to decode with special tokens kept visible after encoding. Run the same user string through the tokenizer twice, once with True and once with False, and print the decoded ids. Under True you will see the marker collapse into a single special id; under False you will see ordinary subword pieces. Seeing the two outputs side by side makes the parameter concrete rather than a name to memorize, and it is the same check you would use to verify a fix in production.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- HuggingFace Transformers exposes add_special_tokens on tokenizer.encode and __call__, and the docs warn against minting special ids from untrusted input.
- LangChain and similar orchestration layers that build prompts from user fields can leak markers if the underlying tokenize step keeps the default add_special_tokens=True.
What an interviewer would ask next. Try answering before peeking at the approach.
QEven with add_special_tokens=False, how could a developer still reintroduce the injection risk?
Think about a later re-tokenization or string-join step that runs under the default flag value.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Picking a plausible-sounding flag like sanitize_special_tokens or escape_html. Those are not real tokenizer parameters; the real knob is add_special_tokens.
60 second bullets to scan on the way to the call.
What the add_special_tokens flag controls during encoding
Why the default True value is unsafe for untrusted input
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.