Spotlighting / Data Marking

Security Objective

Data marking changes how untrusted external content is represented in a model's context so that its source and role are easier for the model to recognize. System components add boundaries, labels, continuous marks, transformations or separate message channels to content that came from documents, web pages, email, retrieval or tools.

The objective is to reduce the chance that instruction-like text inside that content is treated as an instruction. It is a mitigation for indirect prompt injection, applied before or during context assembly, and it works only through the model's interpretation.

Threat Model

An attacker controls some content that a system later places into model context: a shared document, a web page, an email body, an indexed record or a tool response. The attacker cannot change the system prompt or the application code, but can write text that looks like instructions. The risk is that the model follows that text because, once concatenated, it looks like any other part of the prompt.

Marking assumes the attacker may know that marking exists and may try to imitate or disrupt it. It does not address a malicious user typing into their own session, which is direct prompt injection and needs other controls.

Ownership Boundaries

Data provenance decides what content is and where it came from. Input / content inspection produces probabilistic signals about it. Marking only changes how it is presented to the model.

Marking Is Not Trust

Trust Model

The marking component and its output are separate objects. The component runs under system control; the representation it produces carries attacker-influenced text and stays variable.

The model and planner run as system processes, but what they produce is a variable proposal. Authorization and information flow control decide whether it has any effect, independently of how the input was marked.

Why Concatenated Text Blurs Source Roles

A language model receives one sequence of tokens. When system instructions, a user request and a retrieved document are joined into that sequence without clear separation, nothing inherent in the text tells the model which part carries authority. Instruction-like text inside the document can then compete with the real instructions. Marking aims to restore some of that lost role information in a form the model can use.

Provenance Signal Versus Provenance Truth

A mark is a signal about provenance, not the provenance itself. The system must decide what to mark from authoritative metadata recorded outside the payload, never from labels or claims inside the content. A document that declares itself trusted is still external content and is marked as such.

Marking Points

Marking at context assembly sees the final representation and is usually the most reliable point. Marks stored at ingestion can be lost or altered by later transformations.

Marking Strategies

Approaches fall into a few conceptual categories. They can be combined, and none is a security boundary on its own. This page describes categories only and does not publish specific strings, token formats or encoded samples.

Delimiting

Delimiting places boundary markers around external content and tells the model, in system-level instructions, that text between them is data. It is simple and cheap. Its weakness is that it signals only at the edges: if a boundary can be predicted, reproduced inside the content or lost during truncation, the signal weakens. Boundaries chosen by the system per request are harder to imitate than fixed ones.

Datamarking

Datamarking spreads a mark throughout external content rather than only at its edges, giving the model a continuous signal about which text is data. Because the signal persists across the whole span, it can survive partial truncation better than edge boundaries. The cost is that the text the model sees differs from the original, which can affect tasks that depend on exact wording.

Encoding and Transformation

Encoding represents external content in a different form, so it is visibly separated from natural-language instructions. The model must still be able to read the transformed form, which depends on model capability. Encoding usually increases token count, can push long content past input limits, and can reduce quality on tasks that need close reading. It changes representation, not meaning.

Structured Envelopes, Message Roles and Field Boundaries

Where an API supports distinct message roles or structured inputs, external content can be passed in a channel that is separate from system and user instructions. Structured envelopes can carry role and source metadata in fields that the content cannot edit. The metadata comes from provenance; the payload inside the envelope remains untrusted however it is wrapped.

Content Types

See website, email, document, RAG, tool output and multimodal prompt injection for the entry paths.

Model-Visible Representation and Transformation Lineage

What matters is the representation that actually reaches the model. Record which marking method and version produced it, and keep a link to the unmarked source. Without that lineage an investigator cannot tell whether a mark was applied, lost or altered before the model saw the content.

Interaction with Input / Content Inspection

Inspection and marking are independent. A policy may choose stronger marking for content with risk signals, but a clean inspection result is never a reason to skip marking that policy requires, because not detected does not mean safe. Inspection should analyze the same representation the model will see, which may be the marked one.

Interaction with Data Provenance

Marking consumes provenance and never establishes it. The decision to mark content as external comes from authoritative metadata about its entry path and source. Marking itself should be recorded as a transformation in the lineage so derived artifacts can be traced back.

Marking Policy

A policy outside the model decides which content is marked, with which method, at which point. Typical inputs are entry path, source type, workflow risk tier and model capability. External content in workflows with tools or side effects is the usual default for marking. The policy should be versioned so results can be tied to the rules in force.

Marker Integrity

Marks lose value if content can imitate them, if they collide with legitimate text, or if content can cause them to be removed. Conceptually: markers should be chosen by the system, not predictable from outside, applied after any content-controlled processing, and verified in the final representation. This page intentionally does not describe how markers can be bypassed.

Preservation Through Transformations

Derived content that re-enters context should be marked again based on the provenance of its inputs, not on whether the derived text still looks marked.

Trade-Offs

Marking can reduce utility on tasks that need exact text, increases tokens and latency for some methods, depends on the model's ability to interpret the chosen representation, and can confuse users if the model mentions the marking. Measure these costs for your models and tasks rather than assuming them.

Limitations and Failure Modes

Worked Scenario

Synthetic example. A support assistant summarizes a ticket and can draft and send replies. Retrieval adds a customer-provided document whose text contains synthetic instruction-like content asking to forward internal notes externally. No payload text is shown here.

In a controlled test, the same synthetic case runs with and without marking on the same model and task, and the rate of influenced proposals is recorded for each. Both numbers are reported, together with benign task quality.

What the Scenario Proves and Does Not Prove

It shows where marking sits, how its effect can be measured against a matched control, and that the harmful effect is prevented by authorization and flow control. It does not show that marking prevents influence in general, that results carry over to other models or content, or that marked content became trustworthy.

Telemetry and Evidence

Incident Response

Controlled Testing

Use synthetic markers in bounded, labelled test sets. Compare matched marked and unmarked runs on the same model, task and content. Test every transformation path where marks can be lost. Re-run tests when models, marking methods or context assembly change. Do not maintain a reusable attack payload library.

Metrics

Each measure keeps its own denominator. There is no composite score. Marking detects nothing, so no detection metric is attributed to it.

Common Mistakes

Standards, Research and Vendor Context

On source use: OWASP LLM01:2026 is the current classification for prompt injection. Microsoft Research introduced spotlighting as a family of prompt engineering techniques that use transformations of input to give a continuous signal of its provenance, and reported it as an effective defense with limited impact on task quality in its evaluated GPT-family setups; those findings are specific to the configurations tested. Microsoft Learn's guidance on indirect prompt injection is vendor guidance that lists spotlighting, using data marking and metaprompting, as one layer in a defense-in-depth strategy. Microsoft's security response blog describes delimiting, datamarking and encoding modes at a conceptual level. Microsoft Foundry documents a product feature named Spotlighting (preview) that transforms document content for document-attack protection, with documented token cost, API scope and default-off behavior; that is one product's current behavior, not a description of the general technique.

Frequently Asked Questions