There is a quiet way to leak information that never shows anyone a document: show them a number. A regional compliance manager asks the system how many open investigations exist. The engine counts everything, 86, then dutifully hides the case rows she is not cleared for, listing her 11. She sees both figures. She now knows 75 investigations exist that someone decided she should not see, and since her own region accounts for the 11, she knows the rest sit somewhere beyond her scope.
No file was opened. The permissions all held. The disclosure travelled through the count.
If a total includes rows the viewer cannot see, the total is the leak.
Filter-then-count, not count-then-filter
The failure has one root: the aggregate was computed over everything and the filtering applied afterwards, to the presentation. Every variant of afterwards is the same bug. Hiding rows after totalling, redacting documents after retrieval, trimming a chart after the rollup. In each case the sensitive population has already shaped what the viewer receives.
The correct order is absolute. The viewer's entitlements are applied first, inside the query, at the data layer, and every downstream number, list, ranking and answer is computed within that boundary. Her honest total is 11. A colleague with broader scope asks the identical question and honestly receives 86. One number, per viewer, and neither number betrays the other's existence.
Three design consequences follow, and they are where implementations usually fail:
- Every aggregate is scoped: counts, sums, averages, trend lines and the totals used for pagination. A pager reading "1 of 8" above a filtered list of 11 rows is the same leak in a smaller font; the eight pages were computed over the full 86.
- Sort order and ranking are scoped. A "top risks" list computed over everything and then trimmed still ordered itself using data the viewer cannot see.
- There is exactly one path. If a filtered endpoint and an unfiltered legacy endpoint both exist, the unfiltered one will eventually serve a viewer it should not. The predicate lives in one place, and everything queries through it.
Security that is applied to the presentation can be forgotten once. Security that is a property of the query cannot be skipped at all.
Why AI raises the stakes
Retrieval-augmented assistants industrialise this problem. An assistant with a service account's broad access, answering questions from users with narrow access, is an exfiltration tool with a chat interface: it will happily summarise documents the asker could never have opened, and the summary launders the breach. The public conversation about enterprise AI security focuses on prompts and jailbreaks; the plumbing question, whose permissions does the retrieval run under, matters more and is checked less.
The standard has to be that the assistant sees exactly what the asker sees. Permissions from the source systems, enforced at retrieval, per query, per viewer. If you cannot see it at the source, you cannot see it, or feel its shape through a total, in the answer.
This is also, not incidentally, a trust property rather than only a safety one. An answer computed inside your entitlements is an answer you can repeat in a meeting, file in a report and defend to an auditor. An answer computed over the whole estate and trimmed for you is a number nobody can account for.
Prophesee's Nexus engine enforces viewer scope at the data layer for every count, ranking and cited answer, entirely on-premises. Test it against your own permission model. Start here.