Longer context windows are usually discussed as a capability improvement: a model that can process more documents, longer conversations, and bigger codebases at once. That capability comes with a security tradeoff that gets discussed less often, because a longer context window is also more room for untrusted content to accumulate, and more content for a human reviewer or an automated filter to miss something buried within it.
More content means more injection surface per request
A short context window naturally limits how much external content a single request can include, which incidentally limits how much untrusted content an attacker can smuggle in at once. A long context window removes that incidental limit, allowing many more documents, pages, or messages to be processed in a single pass. Each additional piece of content is another potential carrier for an injection attempt, and the sheer volume makes manual review of everything entering a single request increasingly impractical.
Buried instructions are harder to notice
An injection attempt placed early or in the middle of a very long context is easier to overlook, both for a human reviewing logs after the fact and, in some cases, for automated scanning tools tuned to look at content near the edges of a request rather than deep within a large body of text. This is not a guarantee that models handle content differently based on position, but from a practical detection standpoint, a short, obviously placed injection attempt is easier to catch during review than the same attempt buried inside a hundred pages of otherwise legitimate content.
More sensitive data can accumulate in a single context
Longer context windows encourage including more information per request, entire documents instead of relevant excerpts, full conversation history instead of a summarized version, entire codebases instead of the specific file being discussed. This convenience comes with a data exposure cost: more sensitive data present in a single context means more that could be exposed through a single successful leak, injection, or misconfigured logging capture, compared to a system that deliberately includes only what a specific task needs.
Long conversations accumulate risk across turns
In multi-turn conversations enabled by longer context retention, content introduced early in a conversation, including any injection attempt that was only partially or unsuccessfully executed at the time, can remain present and potentially become more effective later, once additional supporting context has accumulated. This is part of why testing single-turn injection resistance is not sufficient; a technique that fails on turn one might succeed on turn fifteen, once the model's context contains more material an attacker can build on.
Cost and performance implications compound the risk
Processing very long contexts is more expensive and slower than processing short, focused ones, which means a system that habitually includes more content than necessary is also more exposed to resource-based abuse: an attacker who can trigger requests that maximize context length can drive up cost and latency more effectively than in a system with a naturally constrained context size. This connects the security tradeoff of long context windows to the operational risk of cost and availability discussed elsewhere in AI security.
The fix is not avoiding long context windows
None of this means long context windows should be avoided; their capability benefits are real, and many legitimate use cases genuinely need to process substantial amounts of content at once. The fix is applying the same discipline that should already apply regardless of context length: include only what a task actually needs, rather than defaulting to maximum context simply because the capability allows it, and treat every piece of content in a long context the same way you would treat a single piece of content in a short one, as untrusted unless it comes from a source explicitly trusted for that purpose.
Testing needs to account for context length specifically
Injection and data exposure testing should include scenarios that place adversarial content at various positions within a long context, not only near the beginning or end, and should include realistic long-conversation scenarios where content accumulates across many turns, since these scenarios can produce different results than the same tests run against a short, single-turn context.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary applies the same regardless of how much context led up to a given request, which means a tool call resulting from an injection buried deep in a long context still has to pass the same authorization check as one resulting from a short, direct request.
Deciding how much content genuinely needs to enter a given request's context, and testing for injection risk specific to long-context and multi-turn scenarios, remains application-level design and testing work.
A short checklist
- Include only what a specific task needs in context, regardless of how
large the available window is.
- Treat every piece of content in a long context as untrusted unless
explicitly from a trusted source.
- Test injection resistance with adversarial content placed at various
positions in long contexts.
- Test multi-turn scenarios where risk accumulates across many turns, not
just single-turn requests.
- Monitor for cost and latency patterns consistent with context-length
abuse.
Longer context windows are a real capability gain, but they also expand how much untrusted content and sensitive data can accumulate in a single request, and the discipline of including only what is needed matters more, not less, as the available window grows.