Permission-aware retrieval

Permission-aware retrieval means that a search over company content returns only what the person asking is allowed to see. The filter uses the user's rights in the source system, not a separate copy of the rights. An agent that searches on behalf of a user must apply the same filter, or it becomes a way around the access controls the company already has.

The risk is easy to miss in a demonstration, where the person asking is usually allowed to see everything. It appears in production, when a junior employee's question returns a senior manager's document.

In practice

I design the filter before the index. The index stores each passage with the identity or group that may read it, and the search applies the requester's identity at query time. The rights are read from the source system or synchronised from it, with a time limit on how stale they may be. I test the filter with accounts that have restricted access, and I record those tests in the evaluation set.

The agent's own tools need the same rule. A tool that reads a record must check the requester's rights as well, not only the search.

Example

[Composite] A knowledge assistant indexed a shared drive for speed. Testing with a restricted account showed that salary bands in a finance folder were returned in answers. The fix was to store the folder's permissions with each passage and filter the results by the requester's groups, and the restricted-account test became a permanent regression check.

Common mistakes

• Copying the content into an index with no permissions attached.
• Applying the filter after the answer is written, rather than before the search.
• Testing only with an administrator account.