Permission-Aware Retrieval

Permission-aware retrieval is the practice of making a retrieval system return only the material the person asking is entitled to see, enforced at query time rather than assumed from how the index was built. It is the difference between a search layer that reflects the access model of the organisation and one that quietly bypasses it. The problem appears almost by accident. Indexes are usually built by a service account with broad read access, because that is the simplest way to crawl every source. Once the content is embedded, the original permissions are gone: a vector is not a document with an owner, it is a numeric address in a space where similarity is the only relationship that survived. Ask a question and the system returns what is closest, and closeness has no opinion about whether the asker was ever allowed to read it. What makes this failure particularly bad is that it is invisible from the outside. Nothing errors. The system answers fluently, cites a source the user cannot open, and the leak is discovered when somebody reads an answer containing information they recognise as not theirs. Compensation packages, unannounced restructurings and legal matters are the classic examples, because they are exactly the documents that live in systems where permissions are tight and crawlers are not. The mechanism is straightforward even if the plumbing is not. Access metadata travels with each chunk into the index — the groups, roles, tenants or document identifiers that govern the original — and the query carries the asker's identity so the search is filtered before results are ranked. Filtering after ranking is the common shortcut and it is wrong twice: it leaks through result counts and it silently shrinks the result set, so a user with narrow access gets fewer and worse passages rather than the best passages they are entitled to. The hard part is keeping the labels current. Permissions change constantly and an index is a copy, so a revoked share, a role change or a departure has to propagate to the index rather than only to the source. Most designs handle this by re-checking authorisation against the source system at answer time for the small number of documents actually being used, which is affordable precisely because it is a handful of items rather than a whole corpus. Multi-tenant products face the same problem in a harsher form, where a filter mistake crosses a customer boundary rather than an internal one. Separate indexes or hard tenant partitions are worth the extra operational weight there, because a single missing filter in a shared index is a cross-customer disclosure, and the query that exposes it can be entirely innocent.