Why RAG Systems Should Filter Permissions Inside the Query, Not After It

A developer behind the open-source project vaultrag has highlighted a subtle but serious security flaw common in retrieval-augmented generation (RAG) systems built on Postgres and pgvector. The typical approach retrieves the top-k nearest vector chunks first and then removes results the user is not permitted to see, which creates two problems: relevant permitted content may never enter the candidate set, and upstream components like logs or caches can inadvertently expose forbidden data. The recommended fix is to embed access-control logic directly inside the SQL query using a common table expression (CTE) that restricts the chunk universe before any ranking or limiting occurs. A document-level ACL table maps content to user IDs or group principals, and those principals are resolved server-side to prevent clients from asserting their own permissions. With this structure, unauthorized chunks are never selected, ranked, or held in memory at any stage of the retrieval pipeline.