Vector databases do not understand entitlements. They understand distance. When you build a retrieval-augmented system on a shared corpus, you are trusting that semantic similarity won't surface documents a user shouldn't see. That trust is routinely misplaced.
The Access Control Sequencing Problem
A typical RAG pipeline executes in this order:
- Embed the user's query
- Search the vector index for top-K semantically similar chunks
- Apply metadata filters (access level, department, classification)
- Pass the surviving chunks to the LLM
The vulnerability sits between steps 2 and 3. Vector search ranks documents by cosine similarity. Access control runs after ranking. This means confidential documents are scored, retrieved, and placed in a candidate set before the system checks whether the requesting user should see them at all.
In most hosted vector store implementations (Pinecone, Weaviate, Qdrant with default configuration), metadata filtering is a post-retrieval operation. A document excluded by a filter was still included in the similarity computation — and in some implementations, still consumes your top-K budget before being dropped.
The consequence: a low-privilege user can craft a query that is semantically adjacent to confidential content and recover that content in the LLM's response — even if the document is nominally filtered.
Engagement Example
During a LogicLeak assessment of a legal technology platform, the client had structured their Pinecone index with three document tiers: public, matter (visible to solicitors assigned to a specific case), and partnership (visible only to partners).
Access control was enforced via a metadata field: access_tier. The application applied a filter { access_tier: { $in: ["public", "matter"] } } for standard solicitor queries.
We demonstrated retrieval of partnership-tier documents using a solicitor-level account with the following approach:
Step 1: Probe for semantic adjacency. We queried with variations of: "billing rate structure for senior clients" and "partner compensation benchmarks." The metadata filter correctly excluded direct hits. But the LLM's responses contained paraphrased content that matched partnership-tier documents — fragments surfaced via documents that bridged both tiers.
Step 2: Cross-tier bridging documents. The corpus contained matter-level documents that summarised or cross-referenced partnership-level content. These bridge documents passed the access control filter but carried enough semantic content from the confidential documents to reproduce material in the model's output.
Step 3: Direct filter bypass via chunking artefact. The ingestion pipeline split documents on paragraph boundaries. A partnership document had been partially quoted in a matter-level summary. The quoted chunk inherited the summary's access_tier: matter tag. It retrieved and rendered in full.
Three distinct leakage mechanisms — semantic adjacency, cross-tier bridging, and chunking artefacts — each independently sufficient. All three present in the same production system.
Why Standard Remediation Fails
"Just add stricter filters" doesn't address semantic adjacency or bridging. A document that legitimately belongs to the matter tier and legitimately references partnership content will always be a leakage vector if the LLM can synthesise from it.
"Separate the indexes" solves the problem but is rarely operationally viable. Maintaining isolated vector stores per access level multiplies infrastructure costs and eliminates cross-tier search entirely — which often destroys the use case.
"Redact the source documents" prevents chunking artefacts but requires re-ingestion of the entire corpus and ongoing enforcement on new documents. It does not address the semantic adjacency mechanism.
Effective Mitigation Architecture
The correct fix is pre-retrieval access control — filtering the candidate set before similarity scoring, not after. Most managed vector stores support this via namespace isolation or pre-filtered ANN indices. The implementation cost is non-trivial but the security property is categorical.
The architecture we recommend has three components:
Namespace-per-tier indexing maintains separate logical indexes per access level. A query from a matter-tier user never touches the partnership namespace at the ANN layer. Similarity scoring and access control are unified, not sequential.
Chunk provenance tagging records the complete access chain of every source document in every derived chunk. A chunk produced from a summary that quotes a partnership document inherits partnership as its effective access tier — regardless of the summary's own classification.
LLM output scanning runs the model's response through a classifier trained on sensitive content patterns before delivery. This is a last-resort control, not a primary one — by the time output scanning fires, retrieval has already occurred. Its value is in catching synthesis that upstream controls missed.
What This Means for Your Deployment
If your RAG system shares a vector index across users with different privilege levels and applies access control as a post-retrieval metadata filter, you are operating with a structural leakage vulnerability. The severity depends on the sensitivity differential between tiers and the semantic overlap between documents at different access levels.
Assessing that overlap requires adversarial testing — synthetic queries designed to probe the semantic boundary between tiers, not just functional testing of the filter logic.
LogicLeak assesses RAG permission boundaries as part of every RAG & Semantic Perimeter engagement. Request an assessment →