The Context Window as a Trust Boundary

Ask where an LLM keeps the difference between your trusted system instructions and a hostile sentence it just read off a web page, and the uncomfortable answer is: nowhere. Both live in the same place — the context window, the flat sequence of tokens the model attends to. It has no notion of privilege, provenance, or ring levels. Treating that window as a trust boundary, and understanding that it is one with no enforcement, is the key insight behind almost every prompt-injection story.

Why the window looks the way it does

A transformer model processes one sequence of tokens at a time. To give it everything it needs to answer, the application concatenates several sources into that single sequence: the system prompt (your rules), the conversation history, the current user input, any retrieved documents, and the outputs of tools it has called — plus, in an agent, the tool descriptions themselves. This is not a design flaw; it is how the model consumes information. There is one buffer, and useful behaviour requires filling it with material from very different levels of trust.

Here is the consequence people miss: within that buffer, every token has equal standing. The model weighs your system instruction and a line of text from an untrusted PDF using the same attention mechanism. There is no hardware-enforced separation, no equivalent of user space versus kernel space. The delimiters and "the following is untrusted data" markers that frameworks add are advisory — hints the model usually respects and an attacker can try to talk it out of.

What follows from the boundary having no enforcement

Once you see the window this way, the standard attacks stop being surprising:

• Direct injection is the user writing instructions into the same buffer as your rules, then asking the model to prefer theirs. Nothing structurally stops it — only the model's learned tendency to obey the system prompt.
• Indirect injection is the same move made through retrieved or tool-returned text, so the malicious tokens arrive from content the user never typed.
• Context overflow and eviction. Windows are finite. Flood the buffer with content and earlier tokens — often your safety instructions — get pushed out or diluted, weakening the very rules you were counting on.
• Instruction ordering games. Because position and phrasing affect attention, attackers exploit where in the buffer their text lands relative to yours.

Living with an unenforced boundary

You cannot make the window enforce privilege — the architecture does not offer it — so you compensate around it. The realistic controls accept that anything in the buffer might act as an instruction and limit the damage when it does:

• Minimise what enters. Every extra untrusted token is attack surface; retrieve less, and only what the task needs.
• Preserve and reinforce provenance. Clearly delimit untrusted content and keep critical instructions positioned to survive long inputs — advisory, but it raises the bar.
• Never let position in the buffer equal authority to act. Enforce authorization outside the model, on the action, so a token that talked its way past the model still hits a real check.
• Constrain the output side. Validate and allowlist what the model's response can trigger, so winning the buffer does not automatically win a privileged action.

The context window is the trust boundary of an LLM system, and it is a boundary the architecture refuses to enforce for you. Every serious control — authorization on actions, output validation, least privilege — exists to compensate for that one fact. Accept that the buffer is undefended, put your real checks outside the model, and the demos lose their teeth. But you can only defend the windows you know are open, which is why discovering every LLM and agent in your environment is where the work begins.