
A generated answer may appear correct, cite relevant documents, and still represent a critical security vulnerability: all it takes is for the retrieval pipeline to feed the model a passage the requesting user was never authorized to read.
This vulnerability frequently occurs when pipelines perform dense vector search across the entire global index, select the top 20 nearest chunks, and attempt to filter permissions post-retrieval—as if stripping citations from the response erases the unauthorized data leak into the context window.
Even when post-filtering occurs before assembling the prompt, searching globally and discarding forbidden candidates degrades retrieval quality: unauthorized documents crowd out legitimate candidates in the top-k result set, starving the prompt of valid context.
In a multi-tenant platform, the operational order must be inverted: authenticated identity determines the authorization scope, the vector and lexical search queries enforce that scope at query time (pre-filtering), the reranker scores only pre-authorized candidates, and finally the context builder constructs the prompt.
This authorization scope rarely reduces to a simple tenant_id. Users within the same organization often have granular access controls partitioned by role, project, department, or individual document ACLs. Query filter predicates must enforce the effective authorization policy, not coarse organization-level assumptions.
The subtle exposure window lies in secondary pipelines: lexical search indexes, hybrid retrieval caches, reranker logs, vector store snapshots, and tracing spans can inadvertently transport or expose sensitive chunks even when the primary API endpoint appears secure.
Permissions evolve dynamically between indexing and query time. A robust architecture revalidates document access before prompt injection and defines deterministic cache invalidation upon privilege revocation, never relying on stale vector metadata to make authorization decisions.
It is tempting to insert instructions like "do not reveal confidential information" into the system prompt, but prompt instructions do not replace authorization. An LLM's role is to synthesize evidence that the backend has already verified, not to decide who is permitted to view it.