Retrieval-time authorization is what lets you index the useful corpus
Most internal assistants are grounded on a deliberately dull corpus: published policies, the handbook, the public wiki. Not because those hold the answers people need, but because nobody is confident enough in the permission model to index anything else. The security problem and the usefulness problem are the same problem, and solving it is what turns a demo into something people rely on.
The failure that makes everyone cautious
The standard mistake is an index built by a service account that can read everything, queried by users who cannot. The retrieval layer has no idea who is asking, so it returns the best match regardless of entitlement, and the model summarises it faithfully.
What makes this worse than a conventional permission bug is discoverability. Reaching a document you should not see previously required knowing a path or an identifier. Now it requires knowing how to phrase a question — and a natural-language interface is, among other things, an extremely effective tool for finding things you were not supposed to find.
A permission error that used to require knowing a file path now requires only knowing how to ask.
What correct looks like
Authorization is evaluated at retrieval time, against the identity of the person asking, on every request. Not at index time, not by pre-filtering a cached result set, and not by asking the model to be discreet about what it was given. Entitlements change; an index built against yesterday’s permissions is wrong by definition, and a model instructed to withhold something it can see is one prompt away from not withholding it.
Practically that means the retrieval query carries the requesting user’s identity, the store supports filtering on it efficiently, and access decisions come from the same source of truth the source systems use. Where several services need to agree on those decisions, expressing them as policy — Open Policy Agent is the common choice — stops the rules drifting apart between the application, the index, and the system of record.
Indexed content is untrusted input
The second control is less widely implemented. Any document that can be placed into a corpus by someone outside the trusted set — a shared drive, an inbox, a ticketing system, an uploaded application — can carry instructions aimed at the model rather than the reader.
The defence is architectural rather than textual: retrieved content is treated as data, never as instruction, and the boundary is enforced in how the request is assembled rather than in a line of prompt asking the model to ignore anything suspicious. Anything that can be undone by a sufficiently confident sentence in a Word document was never a control.
The commercial effect
Get this right and the calculation inverts. The corpus that was too sensitive to index is exactly the corpus that answers the questions people actually have — the case files, the contracts, the engineering history, the correspondence. An assistant grounded on it is worth using; one grounded on the handbook is a novelty that gets abandoned in a fortnight.
This is the argument for treating retrieval authorization as an enabling investment rather than a compliance cost. It is not what makes the assistant safe to build. It is what makes the useful version of it possible at all, and that is a different conversation to have with whoever is funding the work.
One index, not one per team
There is a direct cost consequence too, and it is usually larger than the licence line. Where retrieval cannot enforce entitlements, the workaround is a separate index per audience — one for the team allowed to see contracts, another for the team allowed to see case files, a third for everyone else. Each is separately built, separately embedded, separately refreshed, and separately wrong when a document changes.
Embedding and storage costs multiply with that fan-out, but the operational cost multiplies faster, because every silo needs its own ingestion pipeline and its own failure handling. Retrieval-time authorization collapses that back to one corpus with one refresh path, and permission changes then propagate by themselves rather than by rebuilding an index.
The other saving is downstream and harder to see on an invoice. Questions answered from the corpus are questions not raised as tickets, and the categories that dominate internal support volume — where is the policy on this, what did we agree with this supplier, has this come up before — are precisely the ones a well-grounded assistant handles. That deflection only exists if the assistant can reach the documents holding the answers, which returns to the same control.
What to monitor
Conventional controls do not see this behaviour, so instrument for it directly: retrieval patterns that do not match a user’s role, sudden breadth in the documents surfaced to one account, and responses citing material outside somebody’s normal working set. These are cheap to log and are the only signals that distinguish a curious employee from a compromised account using the assistant as a search tool.
