Why is a larger context window an attack budget, not only a capability gain?

## The claim being corrected The common senior answer is that context length is a capability axis: longer windows mean whole repositories, whole books, whole transcripts in one request, and the interesting questions are about how well the model uses them. All true, and incomplete. **Context length is also a budget the attacker spends.** The reason is specific to how the crowding-out family works. It does not rely on a phrasing, a persona or an argument. It relies on accumulating enough mutually consistent demonstrations that in-context evidence about how this exchange goes outweighs the trained propensity to decline. The effect grows with the number of demonstrations that reach the model. So the quantity that bounds the attempt is not the attacker's ingenuity — it is **how much text this deployment will carry.** ## Consequences that follow directly **1. The family scales on somebody else's roadmap.** Almost every other technique degrades over time: the phrasings get published, land in safety and screening data, and stop working. This one has no phrasing to train out, and each increase in the window raises its ceiling without any new invention. A method whose strength tracks a number the industry competes on is a different kind of asset from one that depends on a string. **2. The cost model changes who can run it.** The attacker pays in tokens, money and latency rather than expertise. That makes it unglamorous and highly repeatable — well suited to bulk abuse of an API, poorly suited to a single dramatic demo. **3. The feature and the carrier can be the same field.** Consider an enterprise batch-classification API whose entire value proposition is that a customer sends a block of their own labelled examples alongside a page of items to classify. The product exists to accept a large, caller-authored, mutually consistent block of demonstrations. There is no separate injection point to find; the documented request body is the carrier, and the size the product advertises is the budget. **4. The obstacle is the assembler, not the model.** What actually bounds a given attempt is the application's own budget and how it composes a prompt from the caller's text plus its own instructions plus the items. A generous model window matters only insofar as the application passes the text through. ## What this does not claim Be precise here, because the overstatements are easy to make. - It does **not** claim a long window is itself a vulnerability. It claims one attack family's ceiling is proportional to it, which is a property to be reasoned about, not a defect to be filed against the number. - It does **not** claim more tokens always means more effect. How usefully a model attends across a very long prompt is its own subject with its own literature; the point here is narrower — the block has to be accepted and carried before any of that is relevant. - It does **not** mean every long-context feature is equally exposed. A window filled by the operator with its own documents is a different situation from one a caller fills with arbitrary text. **Who supplies the tokens is the whole question.** ## The framing to carry into an interview A useful way to say it: for most attack families the interesting variable is what the attacker writes; for this one the interesting variable is **how much the product lets them write, and who they are.** That reframes a capability metric as a shared resource, and it is the reasoning an interviewer is checking for. It also predicts where you would go looking: any field documented as accepting bulk caller text — an exemplar block, a pasted transcript, an uploaded corpus of the caller's own examples — is where this family lives, and it lives there by design rather than by oversight.