Mark the Text the Model Should Never Trust
Spotlighting tags untrusted content so the model can tell data from instructions — a cheap, high-value prompt-side control that lowers injection odds but never proves a boundary.
The Conventional Framing
A model can't defend a boundary it can't see. When retrieved documents, tool output, and web pages are pasted into the same context window as your instructions, the model has no reliable way to know which spans are data to reason about and which are instructions to follow. Spotlighting, introduced by Microsoft, makes that distinction visible: it transforms untrusted content so the model can spot it and treat it as inert.
There are three variants, in increasing strength. Delimiting wraps untrusted text in randomized, opaque markers and tells the model everything between them is data. Datamarking interleaves a special marker character between every word of the untrusted block so the boundary is present on every token, not just at the edges. Encoding transforms the untrusted content entirely — base64, ROT13 — so injected instructions never appear as fluent, followable natural language in context.
The reported numbers are strong: on GPT-family models, Microsoft measured indirect-injection attack success dropping from over 50% to under 2%, with little loss of task quality. For a change that lives entirely on the prompt side — no new services, no re-architecture — that is an exceptional return.
Why This Helps — and Why It Is Not a Boundary
Spotlighting raises the cost of an attack; it does not close the door. Every variant works by steering the model's behavior with a signal in the prompt, and a signal in the prompt is a probability, not an enforcement mechanism. Be precise about the limits:
- It is probabilistic. Under 2% success on the tested models is not zero. A determined attacker who lands in the residual is through, and nothing structural stopped them — the model simply chose, this time, to treat the marked span as data.
- It is model-dependent. The numbers come from GPT-family models. A different or smaller model may honor the marking far less reliably, and there is no way to prove it will hold before you test it in situ.
- It degrades on some tasks. Encoding untrusted text into base64 or ROT13 hurts the model on jobs that need to read the content closely — nuanced summarization, translation, code review. The strongest variant is the one you can least often afford.
- The marker can leak or be spoofed. If an attacker learns or guesses the delimiter scheme, they can forge the closing marker and inject text the model reads as trusted. Randomized, per-request markers help, but the property still rests on secrecy, not structure.
This is a prompt-side control. It has no view of what the agent can do with a successful injection. That is the job of privilege separation and least-privilege tooling, and spotlighting sits beneath them — never in place of them.
Architecture
Components:
- Delimiting— wraps untrusted text in randomized, opaque markers; model is told everything between them is data
- Datamarking— inserts a special marker char (e.g. ^) between every word so the boundary is present on every token
- Encoding— transforms untrusted content wholesale (base64 / ROT13) so injected instructions never read as fluent prose
- Downstream controls— privilege separation and least privilege that hold the line when the probabilistic marking fails
Trust Boundaries
- Untrusted content → transform — every external span is spotlighted before it enters the prompt; nothing untrusted goes in raw
- Transform → prompt — the soft boundary — marking makes the model likely, not guaranteed, to treat the span as data
- Prompt → tools — the hard boundary must exist below spotlighting; a residual injection lands on least-privilege tooling
Threat Surface
| Threat | Vector | Impact |
|---|---|---|
| Residual bypass | An injection in the small percentage the model still obeys | Marked span is followed as instructions |
| Model swap | Deploying on a model that honors marking less reliably than GPT-family | Success rate silently rises above the tested baseline |
| Marker spoofing | Attacker learns or guesses the delimiter and forges a closing marker | Injected text is read as trusted instructions |
| Task degradation | Encoding hides content the task needs to read closely | Team weakens or drops spotlighting, restoring exposure |
The ZIVIS Position
- •Turn it on — it is cheap and it works.Prompt-side, no new infrastructure, and it cut GPT-family injection success from >50% to <2%. There is almost no reason not to have it.
- •It is a probability, not a boundary.Marking steers the model; it does not constrain it. Never present spotlighting as a control you can prove, because you can't.
- •Layer it beneath privilege separation.Defense in depth only. The boundary that stops a leaked injection from acting is least privilege and dual-LLM — spotlighting sits under them.
- •Match the variant to the task.Datamarking is the workhorse. Reserve encoding for tasks that tolerate it; delimiting alone leans on marker secrecy, so randomize per request.
- •Re-measure on your model.The <2% figure is GPT-family. Benchmark spotlighting against your actual model and content before you rely on the number.
What We Tell Clients
Ship it. Spotlighting is one of the best returns on the board: a prompt-side change with no new services that measurably collapses indirect-injection success on the models most teams run. If you ingest external content into a model context and you are not marking it, that is a gap worth closing this sprint. Datamarking is the sensible default; move to encoding only where the task can tolerate transformed input.
Then hold the line on what it is. This is a probability, not a boundary — it lowers the odds an injection is obeyed, and it has no idea what your agent can do when one slips through. We have watched teams treat a strong benchmark number as a solved problem and drop privilege separation. Don't. Put spotlighting beneath dual-LLM, least privilege, and egress control, so that the residual bypass — and on a long enough timeline there is one — lands on a system that has nothing to steal and nowhere to send it.
Related Patterns
- Input Filtering— the detection-side control spotlighting complements — both are probabilistic
- Context Isolation— keeping untrusted spans structurally separated in the context window
- Prompt Hardening— the system-prompt instructions that tell the model to trust marked data as inert
- Structured Output & Validation— constraining and checking what the model emits after it reads marked content
References
Frequently Asked Questions
What is spotlighting and how does it defend against prompt injection?
Spotlighting, introduced by Microsoft, transforms untrusted content so the model can tell data from instructions inside a shared context window. It has three variants of increasing strength: delimiting wraps untrusted text in randomized opaque markers, datamarking interleaves a marker character between every word, and encoding transforms the content entirely into base64 or ROT13 so injected instructions never read as fluent, followable language.
How effective is spotlighting?
On GPT-family models, Microsoft measured indirect-injection attack success dropping from over 50% to under 2%, with little loss of task quality, all from a prompt-side change with no new services. That is an exceptional return, but under-2% is not zero and the numbers are model-dependent.
Is spotlighting enough on its own?
No. Spotlighting is a probability, not a boundary: it steers the model's behavior with a signal in the prompt but does not enforce anything. It is model-dependent, degrades on tasks that need close reading of encoded content, and can fail if an attacker spoofs the delimiter. It has no view of what the agent can do with a successful injection, so it must sit beneath privilege separation and least privilege, never in place of them.
How should spotlighting fit into defense in depth?
Turn it on as a cheap, high-value prompt-side layer, with datamarking as the sensible default and encoding reserved for tasks that tolerate transformed input. Then place it beneath dual-LLM, least privilege, and egress control so that the residual bypass lands on a system that has nothing to steal and nowhere to send it. Re-measure the success rate on your actual model, since the under-2% figure is specific to GPT-family models.