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 and Infographic
A soft rule that says 'only look at your own data' is only as strong as the agent's obedience — and an adversarial input or a prompt injection could override it. Isolation must be enforced at the infrastructure layer, not the application layer. Namespace filtering at the query layer means the vector store physically cannot return another agent's records, regardless of what the agent asks for.
Full explanation below image
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.
Option A (encryption) 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.
Option B is correct. Namespace isolation at the query layer 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.
Option C (metadata field + system prompt instruction) 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.
Option D (separate vector store per agent) 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.