Spotlighting Prompt Injection Defense: Mark Untrusted Input Before Inference

A retrieval pipeline usually combines application instructions with a user request, then appends external text to the same token stream. Indirect prompt injection exploits that merge. A sentence hidden in a web page or PDF reaches the model beside the real task, and the model has to infer which text deserves authority.

Microsoft Research calls one response spotlighting: transform or mark untrusted input before it enters the prompt, then tell the model how to interpret that marked region. The technique improves source separation inside inference. It still needs independent authorization around any action the model proposes.

TL;DR

• Spotlighting gives untrusted text a persistent provenance signal before the text enters the model context.
• Microsoft Research describes marking techniques alongside encoding.
• The 2024 experiments started above 50% attack success and finished below 2% in the evaluated GPT-family tasks, with results tied to that test corpus and model set.
• Treat spotlighting as one inference-layer defense. Keep tool calls and outbound requests behind separate policy checks. Apply the same checks to response handling and sensitive model routes.
• Test clean and injected documents before rollout. Include encoding failures, nested delimiters, downstream action attempts, and other expected attack cases.

Spotlighting changes the prompt the model receives

The Microsoft Research publication starts with a structural problem. LLM applications combine text with different trust levels, while the model receives a single sequence of tokens. Retrieved content can therefore carry instructions that look similar to the application's own instructions.

Spotlighting adds a signal across the untrusted block. The application first transforms or marks the external text. It then adds system instructions that explain the mark and tell the model to treat the marked material as data. The research paper evaluates this pattern on GPT-family models and a synthetic corpus of 1,000 documents containing keyword-payload attacks.

The authors report attack success starting above 50% and falling below 2% in their experiments. That figure belongs to the published test rather than every production deployment. Model version and task both change the outcome. So do the prompt template, attacker strategy, and transformation.

Delimiting draws a boundary around untrusted text

Delimiting places chosen tokens before and after the document. The system instruction identifies everything inside that boundary as untrusted content for a defined task such as summarization.

This is the least invasive form of spotlighting. It preserves the source text and adds little processing. It is also the weakest boundary of the three because a hostile document can contain delimiter-like strings or counter-instructions designed to confuse the model about where the region ends.

A production implementation should generate delimiters outside the document's expected character set and escape collisions. Keep the system template under version control. Store the delimiter value and template version with the inference event. Include the source identifier and content hash in the same record. A reviewer should be able to open one request record and see the exact bracket pair that surrounded the retrieved page.

The indirect prompt injection defense guide covers the downstream containment problem when source marking fails.

Datamarking carries provenance through the document

Datamarking interleaves a special marker throughout untrusted text rather than relying on two edge tokens. In the Microsoft paper's example, whitespace is replaced with a chosen character. The system prompt explains that marked words belong to a document and must be processed only for the assigned task.

The repeated signal is harder for an embedded instruction to escape through a single boundary collision. It also changes tokenization and can affect code or structured data. Multilingual text, optical character recognition output, and exact quotations can also change. Those effects belong in the test plan.

My opinion is that teams should skip a glossy benchmark slide until they have inspected token counts on their own worst documents. A ten-page contract with footnotes and a broken OCR layer is a better test than a clean paragraph. Include copied email headers in that test. Record task quality beside attack success. A defense that breaks extraction accuracy will be disabled during the first operational incident.

Encoding creates stronger separation at a higher cost

The third form transforms untrusted content with an encoding such as Base64 before placing it in context. The model receives instructions to decode the data conceptually for the assigned task while ignoring instructions inside it.

Encoding can create a pronounced separation between application instructions and document content. It increases token cost and depends on model capability. It also makes request inspection harder for a human operator. Binary-looking text filling a console pane is a concrete warning: an analyst may miss the hostile sentence because the visible request no longer resembles the source.

Use encoding only after measuring model comprehension and latency. Measure token expansion and failure behavior as well. Reject malformed encodings before inference. Keep the original source in controlled evidence storage and log the transformation version. Never decode hostile content in an unsafe helper that executes active content or embedded objects. Active content includes macros and scripts.

Test spotlighting as a versioned security control

Start with a fixed evaluation set. Include benign documents and direct instructions. Add hidden-text attacks and nested delimiter attempts. Cover long-context attacks, multilingual content, tool-use requests, and other expected cases. Each case needs an expected model response and an expected downstream policy result.

Run the set against every supported model and prompt-template version. Measure attack success and task accuracy separately. Preserve the source hash and transformed input hash. Record the model and template, along with the transformation and response. Keep the grader outcome in the same record. The prompt injection test cases guide provides a wider set of cases for request and response controls.

Microsoft's Prompt Shields documentation makes another useful distinction. Detection can classify user-prompt and document attacks, while the application decides how API results affect routing or blocking. Combine source marking with a detector where the deployment supports it, then test disagreement between the two controls.

Authorization contains failures after inference

Spotlighting influences model behavior. A determined attacker may still produce a successful injection, especially after a model update or against an untested task. The application should therefore treat every proposed tool call and outbound model request as a fresh authorization decision.

Bind the decision to the authenticated user or agent and the requested action. Check the target and data classification against the policy version. Reject destinations and operations outside that identity's approved scope. Keep the policy result independent of the model's explanation. A model saying that a transfer is necessary carries zero authorization weight.

This layered design matches the prompt injection defense in depth guide. Source treatment and model-side resistance address the prompt. Request and response inspection cover the HTTP exchange. Action authorization and evidence address what happens after inference.

DeepInspect

DeepInspect applies policy to authenticated HTTP traffic between users or agents and LLM endpoints. When an application sends a spotlighted prompt through that route, DeepInspect can evaluate application-supplied identity and role before forwarding the request. It can also evaluate the data classification, model destination, and policy version. Response policy runs on the returned HTTP traffic, and each decision produces an independent audit record.

The application still owns retrieval and source marking. It also owns prompt construction and tool execution. DeepInspect covers only the model calls routed through its HTTP boundary. Local inference and local file parsing remain with application, endpoint, and runtime controls. The same applies to STDIO tools and actions that bypass the governed route.

Book a technical deep dive at deepinspect.ai.