Pre-Retrieval vs Post-Retrieval Authorization

A retrieval-augmented pipeline has two natural places to enforce access: inside the vector query, before results come back (pre-retrieval), and in your application after the search returns (post-retrieval). Most teams pick one without naming the choice, and then inherit that option's failure mode. This is a short reference architecture for where authorization actually belongs, and what goes wrong at the other two spots.

Pre-retrieval filtering: enforce inside the query

Pre-retrieval filtering pushes a metadata predicate into the search itself: tag every vector with a classification or department, then add a filter like classification = internal to the query. It is appealing because it is cheap. The vector store does the work, fewer rows come back, and there is no extra round trip.

The problem is what happens when a tag is missing. A vector with no classification does not match a restrictive filter the way you hope; depending on how the filter is written, an untagged chunk is either invisible or, far more often, treated as unrestricted. That is fail-open: the one document nobody remembered to label is the one that leaks. Correctness also lives in application code, so every team that queries the store has to write the same filter correctly, forever. There is no deny-by-default, and no audit trail of what the filter let through.

Post-retrieval filtering: enforce after results come back

Post-retrieval filtering does the opposite: fetch the top-k most similar chunks, then drop the ones the user is not allowed to see in application code. It feels safer because the decision is explicit and lives in your service, not in a query string.

It has two failure modes of its own. The first is top-k starvation: if you ask for the ten closest chunks and seven are denied, you are left with three, and the authorized results that ranked eleventh and twelfth never had a chance to appear. Answer quality collapses precisely for the users with the narrowest access. The second is exposure: the denied content was already pulled into your process memory, so a stray log line, an error payload, or a trace span can leak what the filter just removed. And because the check sits in one code path, the second service that queries the same store tends to forget it.

The pattern that survives: authorize at retrieval time

The durable pattern is to authorize at the retrieval boundary, in a layer that can see both the principal and the candidate chunk at the same moment. That is where Gateco sits. It resolves the policy-relevant metadata for each candidate through a fallback hierarchy, inline from the vector payload, from a SQL view, or from its own sidecar registry, so the decision never depends on the query author having remembered to add a filter.

Two behaviors come out of that placement. Deny-by-default: a chunk with no matching allow is denied, so the untagged document fails closed instead of open. And refill: when denials crowd out the top-k, Gateco fetches a wider window and re-evaluates, up to a bounded cap, so authorized results still surface instead of starving. The application receives a clean, already-filtered set of chunks and never holds the denied content at all.

Late binding: a policy change applies on the next query

Because enforcement happens at retrieval time rather than at index time, revoking access takes effect on the very next request. No re-embedding, no re-indexing, no redeploy. A filter baked into the index, or an ACL copied into the payload at ingestion, cannot do that: it is only as current as your last ingestion run.

The practical rule

Enforce where the principal and the chunk are both visible, fail closed, and log every decision. Pre-retrieval filtering and post-retrieval filtering each give up one of those three. We covered the access surface this protects in the RAG authorization gap, and the enforcement model, latency budget, and audit spec are documented on the security page.