The Security Context You Know
Security context is a permission boundary. When a user authenticates, the resulting session carries a context: identity claims, group memberships, assigned roles, granted scopes. Every access decision the system makes is evaluated against that context. The context defines the edges of what the system is allowed to see, not just what it happens to see. Change the context — elevate privilege, switch roles, reduce scope — and the access decisions change with it. The enforcement is structural.
That's the mental model that fires when someone says "context" in an enterprise security conversation. It's a good model. It just doesn't describe what a context window is.
What a Context Window Actually Is
A context window is the total input a model can process in a single call, measured in tokens. Tokens are roughly word-fragments — a useful approximation is that 1,000 tokens maps to about 750 words of English text, though the ratio varies by language and content type. Everything the model "sees" during a task — the system prompt, the conversation history, retrieved documents, tool outputs, user instructions — has to fit inside this window. What falls outside it, the model cannot access. There is no memory that persists across calls unless something explicitly manages it.
Current publicly documented context window sizes give you a sense of the scale: Claude 3.5 Sonnet supports 200,000 tokens, GPT-4o supports 128,000 tokens, and Gemini 1.5 Pro has been documented at 1,000,000 tokens in certain configurations. For reference, 200,000 tokens is roughly the length of a substantial government acquisition document package — a full RFP with attachments, technical evaluation criteria, and past performance requirements, all in a single model call.
Where the Analogy Holds
The misfire is understandable. Both a security context and a context window define the boundary of what a system can "see" at a given moment. In both cases, something outside the boundary is invisible to the system. In both cases, the boundary has operational consequences — what the system can reason about, what it can act on, what it can return. The structural similarity is real.
Which is precisely why the break point matters.
Where It Breaks
A context window is a capacity limit. A security context is a permission boundary. These are categorically different things, and the difference has direct consequences for enterprise AI deployment.
A security context has an enforcement mechanism. The RS checks the scope. The policy engine evaluates the attribute. If the token doesn't carry the right claim, access is denied — not discouraged, not deprioritized, denied. The boundary is enforced by the system, not by the content inside it.
A context window has no enforcement mechanism. A system prompt can instruct a model to ignore certain content, to treat certain information as out of scope, to refuse to act on specific inputs. But that instruction is processed by a probabilistic language model, not evaluated by a policy engine. "Ignore the classified attachment" is not a scope check. It is a request to a system that may comply, usually does comply, but cannot be audited for compliance the way an access control decision can be audited.
For a public sector buyer, this is a live architectural concern. An agent processing a 200,000-token context that contains both Controlled Unclassified Information and routine administrative content is not enforcing compartmentalization between them. The model sees everything in the window. Whether it acts on everything in the window is a separate question, and the answer depends on training, prompting, and runtime behavior — none of which map cleanly to the access control frameworks a federal security architect is used to reasoning about.
The Data Governance Conversation You're About to Have
Longer context windows are being marketed as a capability improvement, and they are. They're also a data governance surface area expansion. Every token in that window is data in a model call — subject to whatever data handling agreements govern the deployment, potentially logged, potentially retained, potentially subject to disclosure requirements depending on the agency's legal framework.
When a CAIO asks about context window limitations, they may be asking a performance question. They may also be asking a data classification question without knowing the vocabulary for it yet.
What to Do Tuesday
Ask what they're trying to govern. If the concern is about what an agent can access, that's an authorization architecture conversation — and your IDAM background is directly relevant. If the concern is about what data ends up in a model call, that's a data classification and handling conversation, and the context window size is one of the inputs to that analysis.
Sellers who can distinguish between those two questions, in the buyer's language, get to have both conversations. The one who conflates context window with security context will eventually be corrected by someone on the buyer's team — in a meeting where you'd rather be the expert than the student.
Capacity and permission are different things. The buyer who understands AI already knows that. Now you have the framing to meet them there.