Context window
The context window is the token budget a model attends to in one request. It is also the security boundary that does not exist: it is all one token stream.
The context window is the maximum number of tokens a model can process in a single request: system prompt, conversation history, retrieved documents, tool definitions, tool results and the current user turn, plus the space reserved for the answer.
It is a capacity limit, and it is treated as one in most engineering discussions. It is worth understanding as a security concept too, because of what it does not contain.
There are no privilege levels inside it
Everything in the context window is one sequence of tokens. The system prompt is not protected memory; a retrieved document is not marked as data; a tool result is not sandboxed. Some providers give roles (system, user, assistant, tool) and models are trained to weight them differently, but that weighting is a learned tendency, not an enforced boundary. A sentence in a retrieved PDF competes with the system prompt on the same footing.
This single fact is the root cause of prompt injection, of system prompt leakage, and of the general failure of "just tell the model to ignore instructions in the documents".
Practical consequences
- Every byte you place in the window is trusted by the model. The security question for a RAG system is therefore not "is the model safe" but "who can write to the corpus".
- Longer windows enlarge the attack surface. More retrieved content means more third-party text sharing the instruction channel, and dilution effects mean a system prompt's influence does not scale with the window.
- Cost and latency are attacker-influenced, because both scale with tokens. See denial of wallet.
- Overflow is a correctness risk. When the window fills, something is dropped or summarised — often the oldest turns, which may include the instructions and the constraints. A control that lives only in the system prompt can silently fall out of a long conversation.
The design rule
Decide what is allowed into the window, per request, on the server, and log what actually went in. That log is the only thing that will let you reconstruct an incident afterwards, and the decision is the only place a real boundary can be enforced — because there is not one inside the window.