RAG Access Control: Permission-Filtered Retrieval Simulator

Requesting User's Permissions

Publicalways granted

Engineering

Legal

Confidential

Retrieval Strategy

Query

Top-K retrieved 6

Live Metrics

Chunks scanned–

Blocked chunks skipped–

Leaked chunks in result–

How it works

Each chunk sits at a unit vector on the embedding sphere; similarity to the query is the cosine of the angle between them:

sim(q, c) = (q · c) / (|q||c|) = q̂ · ĉ   (unit vectors)

Chunks about the same topic land near each other regardless of who is allowed to read them — a public FAQ and a confidential incident report about the same outage sit close in embedding space. That is exactly why naive "top-K by similarity" retrieval is a security hole in production RAG systems:

No filter — the vector search just returns the K nearest chunks. Any of them the user lacks permission for gets leaked straight into the LLM's context window.
Pre-filter — the ANN index query itself carries a metadata filter (e.g. Pinecone/Weaviate/pgvector WHERE acl IN (…)), so unauthorized chunks are never even candidates. Safe, but a heavily filtered namespace can under-fill K if few authorized chunks exist nearby.
Post-filter + backfill — rank the full unrestricted candidate list, then walk down it, discarding unauthorized hits and pulling in the next-best authorized one until K slots are filled. Also safe, but it has to scan deeper than K whenever the top matches are disproportionately restricted — the "chunks scanned" counter tracks that extra cost directly.

Toggle permissions off and switch to "No filter" to watch confidential chunks flash red and get pulled into the result; switch strategy to see the same query resolved safely instead.

Public Engineering Legal Confidential Query vector

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.