Same question, five people, five different answers
Pick who you are and what you ask. The assistant only searches what that person could already open in GitHub, Slack, Linear and Notion. Turn enforcement off to see what a naive deployment would have told them.
284 attempts to read what you shouldn't
Every user was pointed at every document they can't open, with targeted questions and generic jailbreaks. Restricted documents carry planted secrets, so any leak is caught automatically. CI blocks the release on a single leak.
Leaks by permission strategy
Filtering after retrieval also stops content leaks, but ranking still uses documents the user can't see. It answered a private-incident question with an unrelated doc, and whether it refuses can depend on restricted content. Filtering first removes both problems.
Answer quality by strategy
Naive leaks by person
What the naive deployment leaked
Two-week pilot: 8 people, every acceptance criterion met
Usage volume and thumbs-up feedback are simulated with a fixed seed. Every answer, refusal and latency behind these numbers came from the real pipeline.
Questions per day
Pilot day 1 to 10. Adoption ramps as the cohort learns what it can answer.
Acceptance criteria
How the value estimate is built
What it couldn't answer, and why
Refusals are split for the champion: "no access" means permissions worked; "content gap" means nobody has written it down yet.
Who can read what
Each connector translates its source's rules (GitHub teams, Slack channel membership, Linear private teams, Notion sharing) into an explicit list of people. Security can audit any document's readers here. Identities are joined on email through the company directory; anything that doesn't match is dropped.
Four weeks, discovery to handoff
The code is half the job. These are the documents a customer actually sees, each written for a specific person at Kestrel.