An agent handles both general technical questions (public information) and proprietary architecture discussions (classified as internal confidential). Within a single session, the conversation transitions from a confidential architecture review back to answering general technical questions. A security review flags the risk that confidential architecture details could surface in the general-audience responses. Which memory management practice BEST mitigates this risk?
Select an answer to reveal the explanation.
Short Explanation
Think of classification boundaries like a clean room—you don't carry contaminated material back out. When the agent moves from confidential architecture review to general technical questions, flush the memory context and treat each classification level as its own isolated memory domain. That keeps confidential details from surfacing in public responses.
Full Explanation
The correct practice is to clear (flush) the memory context when transitioning from a confidential classification boundary to a lower-classification context, treating each classification level as a separate memory domain. When a conversation crosses from a confidential context back to a public or lower-classification context, the accumulated memory from the confidential phase must be cleared. This prevents the model from inadvertently referencing, paraphrasing, or being influenced by confidential architecture details when answering general questions. The principle is analogous to security-clearance compartments: information from one compartment does not flow to another. In practical implementation, the agent detects the classification transition event and invokes a memory flush before proceeding in the lower-classification domain.
The shared-store approach that labels each entry with its classification level and instructs the model to avoid referencing high-classification entries in low-classification responses is wrong because labeling and instructing the model is a soft control that relies on the model's instruction-following behavior. Models can and do blend context from across their context window, even when instructed not to. The label-based approach does not provide a hard boundary; it is a behavioral guardrail, not an architectural isolation. Security engineers refer to this class of failure as 'context bleed.'
The encryption approach that encrypts confidential memory entries using a separate key and configures the agent to decrypt them only when the session is operating in confidential mode is wrong because encryption is an access control for data at rest or in transit, not a memory isolation mechanism. Encrypted entries that are decrypted and loaded into the active context window when 'in confidential mode' still live in the same context as the public-mode conversation history. Encrypting entries does not prevent them from influencing the model's outputs if they are in the same prompt context.
The separate-agents approach that deploys separate agents for each classification level and routes users to the appropriate agent based on the classification of their request describes a valid architectural pattern, but the question specifically asks for a memory management practice. Using separate agents is an infrastructure design decision, not a memory management technique. It also does not address the scenario as stated, which involves a single session transitioning between contexts.