An organization runs five different agents that share a common external vector store for memory. Agent 1 stores sensitive security findings; Agent 2 stores general code style notes; Agent 3 stores HR-related information. A developer is concerned that Agent 2 could retrieve Agent 1's security findings or Agent 3's HR data through semantic similarity searches. Which memory isolation approach MOST effectively prevents cross-agent memory leakage?
Select an answer to reveal the explanation.
Short Explanation
You need isolation the agent can't talk its way around. Namespace filtering at the vector store query layer makes cross-agent retrieval impossible, even if the agent gets tricked. Soft prompts and encryption alone don't stop the store from handing back the wrong records.
Full Explanation
Memory security in shared vector stores requires enforcement at the storage layer, not the application layer. Application-layer controls (instructions, metadata conventions, system prompts) are soft boundaries that can be circumvented by model misbehavior, prompt injection, or misconfiguration.
Encrypting all memory entries so that agents without the decryption key cannot read each other's data is a confidentiality control but not an access control. If Agent 2 cannot decrypt Agent 1's entries, it sees garbage — but the encrypted records are still returned in search results, consuming context window space, potentially leaking metadata (existence of an entry, vector similarity), and creating a fragile dependency on key management. Encryption alone does not prevent vector similarity retrieval from returning records from other agents' namespaces.
Implementing namespace-based isolation where each agent writes to and reads from a namespace keyed by agent identity, enforced at the vector store query layer so that retrieval filters are mandatory and cannot be overridden by the agent, is the correct architectural pattern: every write operation tags the memory entry with the writing agent's namespace, and every read operation mandates a namespace filter that restricts results to the requesting agent's own namespace. Critically, this filter is enforced at the vector store infrastructure level — the agent cannot issue a query that bypasses it, even if its context is manipulated. This is the same principle as row-level security in relational databases: the enforcement is below the application layer.
Adding a metadata field 'owner_agent' to each memory entry and instructing agents via system prompt to only use entries where owner_agent matches their own identity is the dangerous half-measure. System prompt instructions are soft controls: they work when the agent behaves normally but fail under adversarial conditions (prompt injection, jailbreak, confused model state). An agent instructed to 'only read your own data' can still submit a query without a namespace filter if its system prompt is overridden.
Giving each agent its own separate vector store instance to provide complete physical isolation provides complete isolation but at significant operational cost: five separate databases to provision, monitor, scale, back up, and maintain. This is appropriate for very high-sensitivity separation (e.g., HR agent) but is operationally expensive as a general policy for all agents sharing commodity data.