Permission-Trimmed Search
Permission-trimmed search restricts search results to what the searching user is actually allowed to see, applying access checks before ranking rather than filtering an already-ranked list afterward — so nothing unauthorized is ever scored, shown, or briefly visible.
A naive search implementation indexes everything and filters results after ranking — which sounds safe but has a subtle failure mode: ranking algorithms, snippet generation, and caching layers can all incidentally expose fragments of content (a title, a preview line) before the permission filter ever runs, or through a code path that forgot to apply it.
Permission-trimmed search applies the access check before a document is scored or ranked at all, so an unauthorized result never exists in the candidate set the ranker sees — there's no window, however brief, where it's computed but not yet filtered. A result the searcher can't access should show up as nothing, or as a clearly locked "you don't have access" placeholder — never a partial title or snippet.
Getting this right matters more as search scope grows: a search index that spans messages, files, transcripts and linked entities across an entire organization is a much larger permission surface than a single channel's history, and any gap in trimming becomes a real information-disclosure bug rather than a cosmetic one.
Permission-Trimmed Search, in the product
Aanty's hybrid search — keyword, semantic, and faceted by type/entity/person — trims by permission at query time, before ranking, across messages, files, canvases and transcripts in one index. A denied result renders a locked empty state, never a partial title, and the same row-level security the database enforces elsewhere backs the trimming.
Related terms and pages
See Permission-Trimmed Search in a real workspace
Bring a channel from wherever your team works today. In fifteen minutes we'll show what permission-trimmed search looks like on a real conversation, not a slide.