A RAG system serves a Fortune 500 company's internal Q&A platform with strict access control: employees should only receive answers grounded in documents they are authorized to access. The document corpus has 50,000 documents across 200 access control groups. Current architecture: all documents share a single vector index; access control is enforced by post-retrieval filtering (retrieve k=50, filter to authorized, pass top-5 to Claude). Security audit finds that with k=50 retrieval and heavy access filtering, Claude occasionally synthesizes information from filtered-out documents that appeared in earlier sessions and were cached in Claude's context window. What is the correct architectural fix?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — per-user vector index partitioning (or per-access-group index) is the correct architectural fix for the described security vulnerability. The audit finding is that the current post-retrieval filtering approach retrieves unauthorized documents, passes them to a filtering step, and assumes they never reach Claude — but the security finding is about Claude's context from earlier sessions, not the current session's retrieval.
Full explanation below image
Full Explanation
Per-user vector index partitioning (or per-access-group index) is the correct architectural fix for the described security vulnerability. The audit finding is that the current post-retrieval filtering approach retrieves unauthorized documents, passes them to a filtering step, and assumes they never reach Claude — but the security finding is about Claude's context from earlier sessions, not the current session's retrieval. The real vulnerability is that post-retrieval filtering doesn't prevent unauthorized documents from appearing in Claude's context if they were retrieved (even if filtered) in ways that populate context. The architectural fix is pre-retrieval access control: partition the vector index so unauthorized documents are never retrieved, never appear in any intermediate step, and cannot possibly influence Claude's output. Option C misunderstands the vulnerability — the audit finding about 'earlier sessions' and 'cached context' likely refers to multi-turn conversations where filtered documents appeared in context, not literal API context caching. Fresh API calls help but don't address the core issue of unauthorized documents entering the retrieval pipeline. Option A (larger k) worsens the problem by retrieving more unauthorized documents before filtering. Option D (token-appended embeddings) is not a real access control mechanism — appending tokens to embeddings does not reliably encode access control as a geometric property.