Permissions-Aware Retrieval: Access Control Belongs in the Index
If restricted docs enter the context window, filtering the final answer is already too late. Enforce access at retrieval time.
The security review is going fine until someone asks a simple question: can an engineer in Team A retrieve Team B’s HR folder through the assistant? Silence. Someone says the UI hides those sources. That is the moment the project stops being an AI project and becomes a trust project.
Enterprise knowledge systems fail security reviews for a predictable reason: the model can retrieve documents the user should never see, then the UI “tries” to hide them.
Access control belongs in the retrieval path, not as a polite filter after the fact.
Why post-generation filtering fails
If restricted chunks enter the context window:
- The model may leak them in paraphrases
- Logs and traces may store sensitive text
- Prompt injection becomes more dangerous
“We strip forbidden sources from the answer” is not a control. It is damage control. Once the text is in the prompt, you are negotiating with a model instead of enforcing a policy.
Design principles
- Authenticate the user before retrieval
- Resolve entitlements (roles, groups, ACLs) the same way your source systems do
- Filter candidates at search time (metadata filters, ACL-aware indexes, per-tenant indexes)
- Never retrieve what the user cannot open in the source system of truth
- Audit query identity, filters applied, and documents returned
The goal is simple to say and easy to miss: the assistant should not know more than the user is allowed to know.
Implementation shapes
Shared index + strict metadata filters
Store acl, department, sensitivity on chunks. Every query applies filters from the user token. Simple to start. Easy to get wrong if filters are optional, forgotten on a code path, or bypassed by a “debug” endpoint.
Partitioned indexes
Separate indexes per tenant or high-sensitivity corpus. Stronger isolation. More ops cost. Worth it when blast radius between tenants is unacceptable.
Query-time authorization service
Retriever asks a policy service “which doc IDs are allowed?” before ranking. Flexible. Needs low latency and careful caching so you do not invent a new bottleneck.
Pick based on your identity model, not blog fashion. Match how SharePoint, Google Drive, or your product already decide access.
Testing permissions
Add security cases to your golden set. Treat them like unit tests for trust:
- User A must not retrieve User B’s documents
- Cross-department queries return empty or allowed subset only
- Admin paths are explicit, not accidental
Treat failures as release blockers. A pretty answer that leaks a salary band is still a failed release.
Related reading
Checklist
Before you call knowledge AI “production ready”:
- Same authn/authz as source systems
- Retrieval filters are mandatory, not best-effort
- Sensitive corpora isolated or strongly tagged
- Traces redact or control sensitive context
- Permission regression tests in CI
If you are designing knowledge AI over messy enterprise sources, discuss your use case.
Written by Syed Sartaj
Founder of Neurocell. Builds production AI for growth-stage and mid-market teams: agents, knowledge systems, and product features that ship and stay reliable.
Keep going
