Permission aware retrieval: why the access check must come before the model

The failure mode

Enterprise assistants are often given a service account that can read every repository, because that is the quickest way to index everything. The model is then asked to avoid sharing sensitive content. That instruction is not a control. A model can be wrong, can be manipulated and can summarise content in ways that expose it without quoting it.

The pattern that holds

1. Store the source permissions with each indexed passage: users, groups and sensitivity labels.
2. At query time, resolve the asking user's identity and groups.
3. Apply the permission filter inside the retrieval query, so restricted passages are never returned.
4. Only then pass the permitted passages to the model.
5. Log which passages were used for each answer.

The model never sees what the user may not see, so it cannot reveal it, however it is prompted.

Keeping permissions current

Permissions change more often than content. Propagate group changes and document sharing changes into the index on a schedule that matches your risk, and measure the lag. When someone leaves a project, the time between the change and the index reflecting it is a security exposure window.

Testing it

• Create test users in different groups and ask questions whose answers exist only in restricted documents.
• Test cross tenant and cross department queries.
• Test documents with changed permissions, and confirm the lag.
• Include prompt injection inside documents, such as text telling the assistant to reveal other content.

Make these checks a release gate. The Knowledge Intelligence Hub demonstration on this site shows the pattern with synthetic data: switch roles and watch the sources hidden by permissions change.

Related services

• Enterprise Search and AI Knowledge Assistants
• AI Application Testing