The single most important design decision in RAG access control is where authorization happens relative to retrieval. Filter candidate documents by the requesting user's actual permissions before ranking by relevance, and you get a system that simply can't surface unauthorized content, because that content never makes it into the candidate pool to begin with. Filter after the fact, or lean on the model to disregard unauthorized content it's already been handed, and you get a system that depends on the model correctly following an instruction it might not reliably follow. That's not a security boundary. That's a hope.
Pre-filtering versus post-filtering
Pre-filtering restricts the candidate set before similarity ranking ever runs, so the retrieval system only considers documents the requesting user is actually authorized to see. It's the more reliable approach, because it removes unauthorized content from the process entirely rather than trying to clean up after it. Post-filtering, checking authorization after documents are ranked and selected, or worse, after they've already landed in the prompt sent to the model, leaves a window where unauthorized content has already shaped the retrieval result or already reached the model's context, even if it gets technically stripped out before the final response reaches the user.
Pre-filtering asks more of the architecture, since it usually means the retrieval system has to know the requesting user's permissions and apply them as part of the query itself, not as a bolted-on step afterward. That upfront cost is worth paying. It's the difference between an enforced boundary and a filter that anything reaching the model before it runs can just walk straight past.
Carrying forward existing permission models
Most organizations already have a permission model for their documents: role-based access in a document management system, department scoping in a wiki, classification labels on files. RAG access control should carry that model forward into the retrieval index, rather than inventing a separate permission scheme that then has to be kept in sync with the original source by hand, forever. When a document's underlying permissions change, the retrieval index's understanding of who can access it needs to catch up fast, or a user who lost access to something elsewhere in the organization can still pull it up through the AI assistant like nothing happened.
Row-level and attribute-based filtering for structured metadata
For document collections with finer-grained access rules than a single role, filtering by attributes like department, classification level, or a specific project association gives you more control than one blunt permission check. This works well as long as documents in the retrieval index carry consistent metadata reflecting those attributes, which means the ingestion pipeline has to capture and preserve that metadata accurately from the original source, not just the document's text content.
Handling documents with mixed or unclear ownership
Some documents just don't map cleanly to one well-defined access rule, content shared broadly once upon a time without careful classification, or documents whose ownership has drifted into ambiguity as teams and projects reshuffle. Resist the temptation to default these to broadly accessible just because classifying each one individually takes real time. Default to a more restrictive access level instead, and require deliberate reclassification before folding them into a broadly retrievable index, since under-classifying a sensitive document tends to cost a lot more than the inconvenience of over-restricting an unclear one.
Testing access control specifically for retrieval
Testing needs scenarios where a user with narrow permissions asks a question likely to surface content outside their access, and then verifies the retrieval system actually excludes that content from the candidate pool, not just from the final response. That distinction matters, because a system that only scrubs unauthorized content from the final answer, while still including it during ranking or some intermediate step, can still leak information indirectly, through timing, through partial context quietly shaping an unrelated part of the response, or through a bug in whatever filtering step runs later.
Auditing retrieval access over time
Beyond point-in-time testing, periodically audit what content specific users' queries have actually retrieved. It catches access control gaps individual test scenarios miss, and it gives compliance reviews something they usually want anyway: evidence of how retrieval access control actually operates, not just a description of how it's supposed to.
Where TELEON fits
TELEON's audit trail can record what content was retrieved and by whom as part of broader agent activity logging, applied through the gateway or supported middleware, supporting periodic access audits and investigation of a suspected access control gap.
Implementing pre-filtering itself, and carrying forward the underlying document permission model into the retrieval index, is pipeline-level architecture work that has to be built specifically for the retrieval system and its data sources.
A short checklist
- Filter candidate documents by the requesting user's permissions before
ranking by relevance, not after.
- Carry forward existing document permission models into the retrieval
index, kept in sync with the source.
- Use attribute-based filtering for document collections with finer
access rules than a single role.
- Default ambiguous or unclassified documents to restrictive access.
- Test that unauthorized content is excluded from the candidate pool, not
only from the final response.
- Periodically audit actual retrieval access patterns, not just point-in-
time test scenarios.
Access control for RAG only works as a security boundary if it filters before retrieval happens, using the same permission model that already protects the underlying documents. Anything less leaves a gap between what the organization believes is protected and what the retrieval system actually enforces.