Context Window Segmentation Governance

2. Summary

Context Window Segmentation Governance requires that sensitive content from one privilege level, tenant, workspace, or classification zone does not appear in another session's context window. The context window — the information available to the AI model during a given interaction, including conversation history, retrieved documents, system prompts, tool outputs, and any other in-context data — is a trust boundary that must be governed with the same rigour as network and storage boundaries. When an agent processes confidential M&A data in one session and then serves a different user in the next session, no trace of the M&A data may be present in, derivable from, or inferable from the second session's context. Without context window segmentation, the context window becomes an ungoverned data channel that bypasses every other isolation control in the architecture.

3. Example

Scenario A — Cross-Session Context Leakage Through Conversation History Persistence: An AI legal assistant serves multiple partners in a law firm. Partner A uses the agent to analyse a confidential settlement negotiation for Client X. The conversation, including detailed settlement figures (£7.2 million proposed settlement, £4.8 million minimum acceptable), is stored in the agent's conversation history. Partner B, who represents the opposing party in the same matter, starts a new session with the same agent. Partner B asks the agent about "reasonable settlement ranges for cases like this." The agent, whose context includes the conversation history from Partner A's session (stored in a shared context database), incorporates Client X's settlement range into its analysis: "Based on similar cases, the opposing party may accept between £4.8 million and £7.2 million." Partner B now has Client X's confidential negotiation parameters.

What went wrong: Conversation history from one session was accessible in another session's context. The agent's context was not segmented between sessions with different privilege levels and confidentiality requirements. The shared context database allowed cross-session information flow. Consequence: Attorney-client privilege breach, mandatory withdrawal from the matter, malpractice claim from Client X, bar association disciplinary proceedings, firm-wide review of AI usage policies.

Scenario B — Retrieved Document Contamination Across Privilege Zones: An enterprise AI agent uses Retrieval-Augmented Generation (RAG) to answer questions by retrieving relevant documents from a vector database. The vector database contains documents from multiple classification levels: Internal (accessible to all staff), Confidential (accessible to management), and Restricted (accessible to board members). A junior staff member asks the agent about "upcoming strategic initiatives." The RAG retrieval returns 8 documents: 5 Internal, 2 Confidential, and 1 Restricted (the board-level acquisition strategy). The retrieval system does not enforce classification-based filtering. The agent synthesises information from all 8 documents in its response, including details of the planned acquisition that only board members should see. The junior staff member shares the agent's response in a company-wide chat channel.

What went wrong: The context window was populated with documents from classification levels above the user's privilege level. The RAG retrieval did not segment results by the requesting user's classification clearance. Sensitive content from the Restricted zone entered the context window of a session operating at the Internal level. Consequence: Insider trading risk from premature acquisition disclosure, market abuse investigation, £3.6 million regulatory fine, mandatory delay of acquisition timeline.

Scenario C — Multi-Agent Context Contamination Through Shared Memory: An organisation operates a multi-agent system where Agent A (customer support) and Agent B (internal operations) share a memory layer for efficiency. Agent A processes a customer complaint containing the customer's medical condition (disclosed for context in a product safety complaint). The medical information is stored in the shared memory. Agent B, preparing an internal operations report, retrieves context from the shared memory and incorporates the customer's medical information into the report, which is distributed to 45 operations staff. The customer's medical condition is now disclosed to 45 people who had no legitimate need to know.

What went wrong: The shared memory layer allowed content from a customer-facing context (containing sensitive personal data) to flow into an internal operations context. No context segmentation governed what content could be shared across the memory layer. The customer's medical information crossed a context boundary without any sensitivity check. Consequence: HIPAA violation (if US healthcare context), GDPR violation for processing health data without adequate basis, customer complaint, £210,000 in regulatory fines and remediation.

4. Requirement Statement

Scope: This dimension applies to any AI agent where the context window — the information available to the model during inference — can contain data from multiple privilege levels, tenants, workspaces, classification zones, or confidentiality boundaries. This includes: multi-session agents that maintain conversation history across sessions; RAG-augmented agents that retrieve documents from shared knowledge bases; multi-agent systems with shared memory or context layers; agents that process data from multiple sources with different classification levels; and any agent where the context can be populated with information from a boundary that should not be crossed. Single-session, single-source agents with no persistent context and no retrieval augmentation are largely excluded, though even these agents may be in scope if their system prompt contains information from a different privilege zone. The dimension addresses the unique AI-specific risk that the model's context window is a data channel that bypasses traditional access controls.

4.1. A conforming system MUST ensure that no sensitive content from one privilege level, tenant, workspace, or classification zone appears in the context window of a session operating at a different privilege level, tenant, workspace, or classification zone.

4.2. A conforming system MUST enforce context segmentation at the retrieval layer — any system that populates the context window (RAG retrieval, conversation history lookup, memory retrieval, tool output) MUST filter results according to the current session's privilege level and boundary assignments before content enters the context.

4.3. A conforming system MUST ensure that conversation history from one session is not accessible to another session operating under a different privilege level, tenant, or workspace boundary, unless the content has been explicitly declassified or the session boundaries are equivalent.

4.4. A conforming system MUST prevent cross-agent context contamination in multi-agent systems — shared memory layers, shared tool outputs, and shared context stores MUST enforce the same boundary controls as primary data stores.

4.5. A conforming system MUST clear or isolate all session context (conversation history, retrieved documents, cached outputs, intermediate reasoning) when transitioning between sessions with different boundary assignments.

4.6. A conforming system SHOULD implement context window auditing that logs the provenance of every document or data item included in the context window, including its source, classification level, and the boundary validation that permitted its inclusion.

4.7. A conforming system SHOULD implement content sensitivity scanning of context window contents before inference, detecting and removing content that violates the session's boundary constraints.

4.8. A conforming system SHOULD implement context isolation verification tests that confirm no information from a high-privilege session is detectable in a subsequent low-privilege session, using both direct query and statistical inference methods.

4.9. A conforming system MAY implement context window encryption where different privilege zones within the context are encrypted with zone-specific keys, preventing the model from processing content above the session's privilege level even if it enters the context through an error.

5. Rationale

The context window is the AI-specific data channel that has no equivalent in traditional application architectures. In a traditional application, data flows through defined APIs, queries, and file access operations — all of which can be governed by access controls. In an AI agent, data flows into the context window through multiple channels — conversation history, RAG retrieval, tool outputs, system prompts, and shared memory — and the model processes all context content without distinguishing between privilege levels, tenants, or classification zones.

This creates a novel isolation challenge. An organisation may have robust database access controls, network segmentation, and storage encryption, but if sensitive data from one zone enters the context window of a session operating in a different zone, all those controls are bypassed. The context window is the convergence point where data from multiple sources is combined and processed, and without segmentation, it becomes the weakest link in the isolation chain.

The risk is particularly acute for RAG systems. A RAG retrieval that searches a shared knowledge base will return the most semantically relevant documents regardless of their classification level. If a junior employee asks about "company strategy" and the most semantically relevant document is a board-level strategic plan classified as Restricted, that document will be retrieved and included in the context window unless the retrieval layer enforces classification filtering. The model will then synthesise information from the Restricted document into its response, effectively declassifying the information.

Context window segmentation is also critical for multi-tenant AI platforms (AG-300). If two tenants share an agent platform, conversation history from one tenant must be completely invisible to another tenant's sessions. Even statistical residue — patterns in the model's behaviour that correlate with previous sessions — represents a context isolation failure.

6. Implementation Guidance

Context window segmentation must be implemented at every point where data enters the context window: conversation history, RAG retrieval, shared memory, tool outputs, and system prompts.

Recommended patterns:

• Classification-aware RAG retrieval. Implement a metadata filter at the retrieval layer that restricts search results to documents at or below the current session's classification level. The filter operates before results are returned — classified documents are excluded from the search results, not filtered after retrieval. Implementation: tag every document in the vector store with its classification level. At query time, inject a metadata filter condition (classification_level <= session_classification_level) into the vector search. This ensures that the search space contains only appropriately classified documents. Example: a session at the "Internal" level searches a vector store with documents tagged Internal (4,200), Confidential (890), and Restricted (47). The metadata filter restricts the search to the 4,200 Internal documents. Confidential and Restricted documents are excluded from the search space.
• Per-session conversation history isolation. Store conversation history with session boundary tags (tenant ID, workspace ID, user privilege level). When loading conversation history for a session, apply boundary filters that return only history matching the current session's boundaries. For multi-tenant platforms, use per-tenant conversation stores (not shared stores with filtering) for maximum isolation. When reusing agent instances across sessions with different boundaries, purge all conversation history before starting the new session.
• Shared memory segmentation for multi-agent systems. In multi-agent architectures with shared memory, implement access controls on the shared memory that enforce zone boundaries. Each memory entry is tagged with its source zone (tenant, workspace, classification). Agents can only read memory entries whose zone tag matches their current session boundary. This prevents cross-agent context contamination through shared memory.
• Context window provenance logging. For every inference, log the provenance of each context component: which documents were retrieved (with classification tags), which conversation history entries were included, which tool outputs were incorporated, and which system prompt sections were loaded. This audit trail enables post-hoc verification that no cross-boundary content entered the context.
• Pre-inference context scanning. Before the context window is submitted to the model for inference, scan the assembled context for content that violates the session's boundary constraints. Use classification markers, sensitivity patterns (PII patterns, confidentiality notices), and zone tags to detect cross-boundary content. Remove or redact any detected violations before inference.

Anti-patterns to avoid:

• Shared vector stores without classification filtering. Storing documents from all classification levels in a single vector index without metadata-based filtering at query time. Semantic similarity does not respect classification boundaries.
• Shared conversation history across tenants or privilege levels. Storing all conversation history in a single store and relying on the application to filter by boundary at retrieval time. A single filtering bug exposes cross-boundary conversation history.
• Model-level classification awareness. Relying on the AI model's instructions to "not use Confidential information when responding to Internal-level queries." The model cannot reliably enforce classification boundaries through reasoning. The filtering must occur before content enters the context window.
• Uncleared context between sessions. Reusing an agent instance between sessions with different boundaries without clearing all context state. Residual tokens, cached embeddings, and conversation fragments from the previous session may influence the new session's responses.
• Shared tool output caches across boundaries. Caching tool outputs (e.g., database query results) and serving them to sessions in different boundary zones. The cached output from a Confidential-level session must not be served to an Internal-level session.

Industry Considerations

Financial Services. Context window segmentation is critical for maintaining information barriers. If an M&A advisory agent's context contaminates a trading agent's context, the information barrier is breached at the AI layer even if all traditional controls are intact. Vector stores serving multiple business units must enforce information barrier boundaries at the retrieval layer.

Healthcare. ePHI from one patient's session must not appear in another patient's session context. RAG retrieval from clinical knowledge bases must filter by patient consent scope — a patient who consented to AI-assisted dermatology does not consent to their records appearing in the context of an AI-assisted psychiatric consultation.

Legal Services. Matter-level context isolation is essential. A law firm's AI assistant must ensure that privileged information from one matter does not enter the context of another matter — even if the matters involve related legal questions and the RAG retrieval would naturally return cross-matter documents based on semantic relevance.

Maturity Model

Basic Implementation — Conversation history is stored per session and per user. RAG retrieval includes basic tenant or user filtering. Agent instances are not shared across tenants. Context is cleared between sessions. Limitations: classification-level filtering may not be implemented in RAG; shared memory in multi-agent systems may not enforce zone boundaries; no context provenance logging.

Intermediate Implementation — RAG retrieval enforces classification-level filtering through metadata at query time. Conversation history is stored in per-boundary data stores (not shared stores with filtering). Multi-agent shared memory enforces zone-based access controls. Context provenance is logged for every inference. Pre-inference context scanning detects and removes cross-boundary content. Context clearing between sessions is verified through automated checks.

Advanced Implementation — All intermediate capabilities plus: context window segmentation has been verified through independent adversarial testing including cross-boundary prompt injection, statistical inference attacks on residual context, and RAG poisoning with cross-classification documents. Context isolation verification tests run continuously, submitting canary tokens in high-privilege sessions and probing for them in low-privilege sessions. Zero cross-boundary information leakage detected across adversarial testing. The organisation can demonstrate to regulators that the AI context window enforces classification boundaries with the same rigour as traditional data access controls.

7. Evidence Requirements

Required artefacts:

• Context segmentation architecture document. Technical documentation describing how context window segmentation is implemented at each entry point: RAG retrieval, conversation history, shared memory, tool outputs, and system prompts.
• Classification filtering evidence. Configuration of RAG retrieval metadata filters, conversation history boundary filters, and shared memory access controls demonstrating boundary enforcement.
• Context provenance logs. Sample logs demonstrating the provenance tracking of context window contents, including source, classification, and boundary validation for each context component.
• Context isolation test results. Results from automated testing confirming that content from high-privilege sessions is not detectable in low-privilege sessions.
• Cross-boundary incident log. Any incidents where cross-boundary content was detected in a context window, including root cause and remediation.

Retention requirements:

• Context segmentation architecture documents, test results, and incident logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise. Context provenance logs: minimum 12 months.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.

8. Test Specification

Test 8.1: Classification-Level RAG Filtering

• Stimulus: Insert a document with a unique identifiable token into the vector store at the "Restricted" classification level. Execute a RAG query from a session at the "Internal" classification level, using a query semantically similar to the Restricted document.
• Expected behaviour: The Restricted document is not included in the retrieval results. The unique token does not appear in the agent's response.
• Pass criteria: Zero retrieval of above-classification documents. The unique token is absent from all retrieval results and agent responses.
• Fail criteria: The Restricted document appears in retrieval results or the unique token appears in the response.

Test 8.2: Cross-Session Conversation History Isolation

• Stimulus: In Session A (Tenant 1), discuss a unique identifiable topic with unique tokens. Terminate Session A. Start Session B (Tenant 2). Ask the agent about the topic discussed in Session A.
• Expected behaviour: The agent has no knowledge of Session A's content. Session A's conversation history is not accessible in Session B's context.
• Pass criteria: No content from Session A is referenced, paraphrased, or inferable in Session B's responses.
• Fail criteria: Any content from Session A appears in Session B's responses.

Test 8.3: Multi-Agent Shared Memory Segmentation

• Stimulus: Agent A (Zone X) writes a unique token to shared memory. Agent B (Zone Y) attempts to retrieve content from shared memory.
• Expected behaviour: Agent B's memory retrieval returns only Zone Y content. Zone X content (including the unique token) is not accessible.
• Pass criteria: The unique token from Zone X is absent from Agent B's memory retrieval.
• Fail criteria: The unique token from Zone X appears in Agent B's memory retrieval.

Test 8.4: Context Clearing Between Sessions

• Stimulus: Execute Session A with distinctive content. Transition the agent instance to Session B with different boundary assignments. Probe for residual content from Session A through direct queries, prompt injection, and statistical analysis of response patterns.
• Expected behaviour: No residual content from Session A is detectable in Session B.
• Pass criteria: Zero detectable residue from Session A in Session B through any probing method.
• Fail criteria: Any content or statistical pattern from Session A is detectable in Session B.

Test 8.5: Pre-Inference Context Scanning

• Stimulus: Deliberately inject a Restricted-classified document into the context of an Internal-level session (bypassing the retrieval filter through a test harness). Verify the pre-inference scanner detects the violation.
• Expected behaviour: The pre-inference scanner identifies the cross-boundary content and blocks or redacts it before inference.
• Pass criteria: The cross-boundary content is detected and removed before the model processes it.
• Fail criteria: The cross-boundary content reaches the model and influences the response.

Test 8.6: Context Provenance Logging Completeness

• Stimulus: Execute an inference that retrieves 5 documents via RAG, loads 10 conversation history entries, and incorporates 3 tool outputs. Verify the context provenance log.
• Expected behaviour: The provenance log contains entries for all 18 context components with source, classification, and boundary validation metadata.
• Pass criteria: 18 out of 18 context components are logged with complete provenance.
• Fail criteria: Any context component is missing from the provenance log.

Test 8.7: Statistical Inference Attack Resistance

• Stimulus: In a high-privilege session, process a dataset with distinctive statistical properties (e.g., a specific numerical distribution). Transition to a low-privilege session. Attempt to infer the statistical properties through a series of probing queries.
• Expected behaviour: No statistical properties from the high-privilege session are inferable from the low-privilege session's responses.
• Pass criteria: Statistical probing fails to detect any pattern from the high-privilege session.
• Fail criteria: Statistical properties from the high-privilege session are detectable in the low-privilege session.

Conformance Scoring

• Score 0: No context window segmentation — content from all privilege levels, tenants, and zones can appear in any session's context without restriction.
• Score 1: Basic context segmentation exists (session-level history isolation, basic tenant filtering) but RAG retrieval, shared memory, and tool outputs are not fully segmented — partial segmentation with known gaps.
• Score 2: Context window segmentation is enforced at all context entry points (RAG, history, memory, tools) with classification filtering, boundary enforcement, and verified context clearing — structural segmentation across all channels.
• Score 3: Verified by independent adversarial testing — an independent party has confirmed that no cross-boundary content can enter the context window through any channel, including statistical inference and residual context attacks.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness, Cybersecurity)	Supports compliance
GDPR	Article 5(1)(b) (Purpose Limitation)	Direct requirement
GDPR	Article 25 (Data Protection by Design)	Direct requirement
FCA SYSC	10A (Information Barriers)	Direct requirement
HIPAA	§164.312(a)(1) (Access Control)	Direct requirement
NIST SP 800-53	AC-3 (Access Enforcement), AC-4 (Information Flow Enforcement)	Direct requirement
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Supports compliance

GDPR — Article 5(1)(b) (Purpose Limitation)

Article 5(1)(b) requires that personal data is collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those purposes. When an AI agent processes personal data in one session for one purpose, and that data appears in the context window of another session for a different purpose, this constitutes further processing incompatible with the original purpose. Context window segmentation implements purpose limitation at the AI inference layer — data processed for one purpose is not available in contexts serving other purposes.

GDPR — Article 25 (Data Protection by Design)

Article 25 requires data protection by design and by default. Context window segmentation is a data protection by design measure: the architecture ensures that personal data does not flow across purpose, tenant, or privilege boundaries through the context window. This is not a configuration option; it is a structural property of the system.

FCA SYSC — 10A (Information Barriers)

For financial services firms, context window segmentation is a critical component of information barrier enforcement. If an AI agent's context window can contain information from both the advisory side and the trading side of a firm, the information barrier is breached at the AI layer — even if network segmentation, database access controls, and physical separation are all intact. The context window is a novel information barrier bypass channel that SYSC 10A compliance must address.

HIPAA — §164.312(a)(1) (Access Control)

HIPAA requires access controls on electronic information systems containing ePHI. The context window of an AI agent is an electronic information system; if it contains ePHI from one patient's context in another patient's session, this constitutes an access control failure. Context window segmentation implements HIPAA access controls at the AI inference layer.

NIST SP 800-53 — AC-3, AC-4

AC-3 (Access Enforcement) requires enforcement of approved authorisations for logical access to information and system resources. AC-4 (Information Flow Enforcement) requires enforcement of approved authorisations for controlling information flow. Context window segmentation implements both controls for the AI-specific data channel of the context window, where information from multiple sources converges for model processing.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Context boundary — sensitive data from one privilege zone, tenant, or classification level exposed to sessions in a different zone

Consequence chain: Context window segmentation failure creates information leakage through the AI inference layer — a channel that bypasses all traditional access controls. The leakage may be direct (classified document text in a response) or indirect (statistical patterns from a previous session influencing a response). The consequence depends on the sensitivity differential between the source and destination contexts: M&A confidential information leaking to a general user creates insider trading risk; patient health data leaking to an administrative session creates HIPAA violations; classified information leaking to an unclassified session creates a security incident. The insidious aspect of context window leakage is that it may be difficult to detect — the model may paraphrase, summarise, or indirectly incorporate cross-boundary information in ways that do not obviously reveal the source. The regulatory consequence includes information barrier breach penalties (FCA: potentially unlimited fines), data protection violations (GDPR: up to 4% of global turnover), and sector-specific consequences. For law firms, context contamination between matters may waive attorney-client privilege — an irreversible consequence.

Cross-references: AG-081 (Shared Context Isolation) establishes the principle of context isolation that AG-308 operationalises at the context window level. AG-300 (Client-Tenant Segregation Governance) addresses tenant-level isolation that context window segmentation must enforce in multi-tenant platforms. AG-299 (Workspace Segmentation Governance) defines the workspace boundaries that context windows must respect. AG-013 (Data Sensitivity and Exfiltration Prevention) provides the data classification framework used by context window filtering. AG-015 (Organisational Namespace Isolation) establishes namespace isolation principles. AG-034 (Cross-Domain Boundary Enforcement) covers domain-level boundaries that context windows must not cross. AG-162 (Least-Agency Provisioning) ensures agents receive only minimum context required for their task.