Organisations spend years getting their access model right. Which department sees which procedure, which membership tier unlocks which archive, which role may read the file at all. Then an AI search tool arrives, indexes everything into one pile, and quietly hands that model back its own worst assumption: that everyone is allowed to see everything.
What permission aware actually means
Permission aware retrieval means the set of content a user can retrieve is restricted by their identity before any search happens, using the same rules that govern the rest of the system. It does not mean the model has been told to be careful. It does not mean answers are filtered afterwards. It means restricted content is never a candidate in the first place.
The test is straightforward. If a user with limited rights asks a question that could only be answered from restricted material, the correct response is the same one they would get if that material did not exist at all.
Three approaches that look right and are not
Each of these appears in real products, and each fails under pressure:
- Telling the model. Putting "only use content this user is allowed to see" in the system prompt puts a language model in charge of a security boundary. Models are helpful by design and they can be talked around. This is the most common mistake by a distance.
- Filtering after generation. Retrieving everything, generating an answer, and then checking whether it should have been shown. By that point the restricted content has already been processed, and the answer that gets suppressed still reveals that something was there.
- One index per role. This is at least a real boundary, but it collapses as soon as permissions are more granular than a handful of roles, and it duplicates content endlessly. It also breaks the moment a single user holds multiple roles.
How it should work
The workable pattern is to store access information alongside every indexed passage, and to filter on it at query time. In a Drupal context that means capturing roles, node access grants, Group memberships, or subscription tiers as metadata on each passage when you index it.
When a question arrives, the server reads the current user's entitlements from the session, translates them into a filter, and passes that filter to the vector database as part of the query. The database returns only matching passages. The model then receives a set of passages that is already correct, and its instructions are about writing a good answer rather than about keeping secrets.
One implementation detail decides whether this holds up: the filter must be built server side from the session, never from anything supplied by the client. A user identifier passed in a request body is not an entitlement, it is an input.
Keeping permissions current
Access changes. Someone leaves a department, a subscription lapses, an article moves from public to restricted. Your index has to follow, and the failure mode is silent: nobody notices that a former employee's role is still attached to indexed passages until an audit finds it.
Two mechanisms cover this. Re-index a node's access metadata whenever its access settings change, which entity hooks make straightforward. And evaluate the user's entitlements per question rather than caching them for a session, so a change takes effect on the next question rather than the next login.
How to verify you have it
This is not something to take on faith from a vendor. Four tests are worth running before go live, and worth repeating after any significant change:
- Ask a restricted question as a low privilege user and confirm the system declines rather than answers.
- Try to talk the chatbot into it. Claim to be an administrator, ask it to ignore its instructions, ask it to summarise "everything it knows" about the topic. A correctly built system is unmoved, because it does not have the content.
- Change a user's role and confirm the effect is immediate on the next question.
- Pull the audit log for a session and confirm you can see which sources were used and that the user was entitled to each one.
If a vendor cannot help you run these, that answers your question about the architecture.