Skip to main content
Two controls against indirect prompt injection, both measured on six frontier models. One is ours and ships off by default because it rewrites the request your provider sees. The other is a parameter in your own API call that, on three of five models we tested, did more than ours did. Read the limits before relying on either.

​
The problem these address

A detector reads the retrieved document and decides whether it looks like an attack. That puts the answer inside content the attacker controls, so accuracy is empirical and an attacker who can iterate finds the gap — the argument Capability Containment makes at length. Marking takes a different route. It never asks whether text is an attack. It marks where the text came from, which the gateway already knows structurally from role="tool" messages and tool-result blocks. Nothing reads prose, so nothing can false-positive on a support runbook — the failure mode that makes instruction-shaped benign documentation score as an attack. The technique is spotlighting, from Hines et al., Defending Against Indirect Prompt Injection Attacks With Spotlighting (Microsoft).

​
What it does to your request

Every untrusted span is wrapped, and one instruction is added explaining the markers:
Your own system prompt is appended to, never replaced. If a request contains no tool content, nothing is added at all — markers with no block to explain would spend tokens on every request and train the model to expect something that is not there.

​
Coverage by request shape

The instruction goes where each API actually reads it, and spans are found where each API actually puts them:
Non-text blocks are not covered, and the response says so. An image or audio block inside a tool result cannot be delimited without corrupting the payload, so it is skipped and counted. Check X-PromptGuard-Spotlight-Skipped — “marking is enabled” is not the same as “everything untrusted in this request was marked”.

​
Enabling it

Off by default, deliberately. Every other check in the gateway inspects and either forwards or blocks; this one modifies the payload your model receives. That makes it a behavioural change to your prompt, so you opt in. It is also suppressed automatically in monitor mode — observe-only must not rewrite an outbound request.

​
Knowing it happened

Absent when nothing was marked. If you are debugging a reply that surprised you, these tell you whether the gateway was a variable in your prompt.

​
What it buys, measured

Ten adaptive injections written knowing the defence exists — six forging or mutating the closing marker, four arguing the rule does not apply — against four real documentation hosts, scored by exact canary-token match with no LLM judge in the loop. The gemini-2.5-pro row was later re-measured at three times the sample size: plain delimiting is 36.7% (44/120) rather than 47.5%. The table above is left at its original n=40 because every row shares that sample size; the mode table below carries the tighter figures. No measurable utility cost. A separate pass planted a unique token in clean documents and had the user ask for it — the mirror image of the canary, so a model that had merely stopped reading the document would fail it. All six models: 100% recall in both conditions, zero refusals, and no significant change in how much of the source survived into a summary.
Earlier guidance based on open models put the reduction at 18–23% and did not recommend this. That number holds for those models and does not transfer to frontier models — which is why this page exists. The most capable model tested is also the best defended.

​
Choosing a mode

Attack success by mode, measured:
There is no globally best mode, and the ranking is not intuitive: datamarking alone is the strongest option on Opus and nearly useless on Gemini, where only the combination works. Pick against the model your project actually calls, not by picking the “strongest-sounding” one.
Both datamark modes cost +120% tokens on marked content — measured on real documentation, ×2.20 token count. You pay that on every request containing tool output. It is worth it where delimiting is weak and worth nothing where delimiting already reaches zero, which is why it is not the default. Pick it against the model your project actually calls.

​
Reasoning effort is a security control

This is the finding worth acting on first, because it costs you nothing and it is entirely in your hands. Raising reasoning_effort from off to low roughly halves the attack class that survives marking: Per model the effect is large and uneven:
If you are running a retrieval or tool-using agent on a small or mid-tier model, this is the cheapest security change available to you, and on three of the five models where it can be varied it did more than our own defence did.
gemini-2.5-pro cannot disable reasoning at all, so it has no “off” row — its 47.5% is with reasoning already working in its favour.

​
Neither of these is a fix

Marking reduces indirect injection. It does not stop it.
  • gemini-2.5-pro still complies with 13.6% of adaptive attacks on datamark_delimit (95% CI 8.5–20.9%, n=118), and 36.7% on plain delimit. If you run Gemini on retrieved content, use datamark_delimit — and still gate the consequential action rather than relying on marking alone.
  • Forging the closing marker is the attack that survives — 19.4% pooled, against 10.4% for attacks that argue semantically. The gateway strips markers the document supplies itself, which prevents the document from ending the block, but stripping the escape sequence leaves the instruction behind and capable models follow it anyway.
  • Nasr et al., The Attacker Moves Second, broke twelve published defences at over 90% attack success. Any single mitigation, including this one, should be assumed bypassable by an attacker who can iterate.
Treat marking as defence in depth. The controls that do not depend on guessing an attacker’s text are the ones to build your architecture on:
  • Capability Containment — derive the envelope from the trusted objective, so an injection cannot widen it
  • MCP Security — the toolset your agent holds, and the Rule of Two check on whether that combination is safe at all
  • AI Agent Traps — the failure patterns these controls exist for