Since T2.3, the text of a tender has stood between <documents> and </documents>, and since T5.1, the sections of the
help stand there too. Back then, it was said: in anticipation of T6. Now comes the reason, and with it three changes. The fence gets exactly the form that
Microsoft documents. There is a single fence for all AI functions, and a test proves for every message that foreign text stands only
there. In addition, the other direction is dealt with: what the model writes back is foreign text too. An image in an answer can
carry data out of the Kladde without anyone clicking.
You need a model in this lesson only at the end, for the second run of your attacks. Everything else is checked by tests with the fake client.
What a fence does and what it doesn't
A fence around foreign text does three things:
- It tells the model what is data. The system message names the markers and says that the text between them comes from outside. A model sticks to that better when the boundary is unambiguous than when the foreign text stands somewhere in a sentence.
- It makes the text visible to the safety check in Foundry. In Foundry, Prompt Shields examines the user text for attacks and, if you turn it on, the documents for indirect attacks. Which part of a message is a document, the service recognizes by exactly this delimiter. Microsoft writes that the detection of indirect attacks depends on it.
- It keeps the structure tight. A text that itself contains
</documents>must not close the fence. That is why the foreign text stands in the fence as JSON, with<and>as<and>.
What a fence doesn't do: it doesn't make the text harmless. The model can still follow a sentence inside the fence, as you saw in T6.1. The fence lowers the probability and makes attacks detectable. What still gets through, the code catches (T6.4).