Permission-aware retrieval
Also: ACL-aware retrieval, document-level access control in RAG
What is Permission-aware retrieval?
Permission-aware retrieval ensures an AI assistant only retrieves and answers from documents the requesting user is entitled to see, enforcing source-system access rights at query time rather than in the prompt.
What Permission-aware retrieval means
When an assistant searches across Drive, SharePoint, Confluence, a CRM and a ticketing system, it will index documents with very different audiences: board papers, HR files, one customer's contract, another tenant's data. Permission-aware retrieval carries the access control list of each source document into the index as metadata and applies a hard filter on every query, so the candidate set is already limited to what this user may read before any ranking or generation happens.
Implementation involves syncing group memberships and document ACLs from identity providers and source systems, handling changes promptly (a revoked share must stop appearing), and testing with negative cases: queries from a user who should not see a document must return nothing from it, even when it is the best match.
This is not achieved by telling the model "do not reveal confidential information". Prompts are not access control. It is also distinct from tenant isolation, which separates customers of a SaaS product; permission-aware retrieval works within one organisation, at the level of individual users and groups.
Who it really matters to
- CISO: An assistant that indexes everything and filters nothing is a data-leak engine with a friendly interface; this is the control that prevents it.
- Compliance officer: DPDP, GDPR and HIPAA obligations do not lapse because the reader is a language model; access must be enforced per request and be auditable.
- HR head: Salary, grievance and performance documents in shared drives are exactly what a naive enterprise assistant would surface to the wrong person.
- CTO / Head of Engineering: ACL sync across systems is the hardest part of an enterprise knowledge assistant and must be designed in from the start, not added later.
Why it exists
Enterprise search has always had to respect who may see what; adding a language model raises the stakes because the model will happily paraphrase a document the user should never have found. Permission-aware retrieval exists so that the assistant inherits the organisation's existing access decisions rather than inventing new ones. The trade-off is engineering effort and freshness: ACLs live in several systems, change constantly, and must be mirrored accurately in the index. That cost is unavoidable; the alternative is an assistant that cannot be deployed beyond a single trusted team.
Where it is applied
- Company-wide knowledge assistant over Drive, Slack and Confluence for a SaaS scale-up, respecting per-folder sharing
- Relationship manager assistant at a bank that retrieves only the customer files assigned to that manager
- Clinical assistant that limits retrieval to patients under the clinician's care, in line with hospital access policy
- Student support agent that answers from a learner's own records and never another student's
- Field-operations assistant in logistics that scopes depot and contract documents by the user's region and role
Is Permission-aware retrieval a skill?
Technique / practiceA security engineering practice within retrieval systems, covering ACL sync, metadata filtering and negative-case testing. It is a default component of Eazyware's Retrieval & Knowledge Engineering and Private Agentic AI work.
Eazyware service that covers it: Retrieval & Knowledge Engineering. Starting prices are on the pricing page.
Frequently asked questions
Can't we just instruct the model not to share sensitive documents?
No. Instructions in a prompt are advisory and can be bypassed by phrasing. Access rights must be enforced as a filter on the retrieval query so restricted documents never reach the model in the first place.
How quickly do permission changes take effect?
That depends on how ACLs are synced. Near-real-time via webhooks from the identity provider and source systems is the goal; for sources without webhooks, a short polling interval with a documented maximum delay is the fallback.