How Lanternfish keeps answers permission-aware

A research tool that reads everything your team wrote has one obvious way to go wrong: showing someone a document they were never meant to see. Most of the engineering work behind Lanternfish goes into making that impossible by design, not by policy. This post walks through how it works.

Copy the access list with the content

Lanternfish never gives anyone more access than they already have. When you ask a question, the search runs as you. It can only read documents, channels and tickets that you can already open in the original tool. If you cannot open a file in Notion, it will not appear in your answer.

That sounds simple, and the principle is. The hard part is keeping the rule true while thousands of permissions change every day.

When a connector reads an item, it stores two things: the content, and the list of people and groups allowed to see it. The second part is as important as the first. A document stored without its access list would have to be treated as public, which is the one thing we cannot do.

Each connector translates its tool's own model into that list. A Slack channel becomes its members. A shared drive becomes its groups. A ticket becomes the people on the account. The list is kept in a form that is cheap to check, so the next step can afford to run on every question.

Check on every answer

We do not check access once, when a file is first read. We check it each time an answer is built. The sequence looks like this:

• Find candidate passages across the sources that match the question.

• Drop every passage whose access list does not include the person asking.

• Write the answer using only what is left.

• Attach a receipt to each sentence, pointing at the passage it came from.

Because filtering happens before writing, a restricted document never influences the wording of an answer, even indirectly. The receipt step then gives you a way to verify that claim: every source in an answer is one you can open yourself.

When permissions change

Access changes sync back from each tool within about ten minutes. Remove someone from a Slack channel or a shared drive, and it stops appearing in their answers on roughly that schedule. Until the sync lands, the original tool remains the source of truth: if a receipt points at something you can no longer open, the side panel shows it as unavailable instead of showing the text.

Two consequences are worth knowing about. Two people asking the same question can get different answers, because they can open different sources. And admins can manage connectors but cannot read content they could not already open themselves.

Answers can also leave the app, in a thread or in a scheduled brief. To keep the rule intact there, a shared answer only contains sources that every recipient can open. If one reader could not open the source of a sentence, that sentence is left out for everyone.

You can check our work yourself. Ask the same question as two people with different access, then open the receipts. The sources should differ, and every one of them should open for the person who sees it. That is the test we run ourselves, and it takes about five minutes.