Permissions that can only narrow: the intersection rule

The hardest problem in putting a firm's documents behind an assistant is not reading them. It is that the answer must be different for different people, and must be different in the right direction, every time, including in cases nobody thought about.

The usual approach is to retrieve, then filter: assemble the best answer, then remove the parts the asker should not see. This is the approach that leaks. Not because the filter is badly written, but because by the time it runs the sensitive thing has already influenced the answer — it shaped a summary, contributed to a total, or is implied by what remains. You cannot reliably subtract a document from a paragraph written with it in view.

Where does visibility come from?

From the source, at the moment of capture. A document in a SharePoint library that only the deal team can open arrives carrying that fact, and the fact is stamped onto the observation rather than looked up later. The same is true of a Drive file's sharing, a Slack channel's membership, a mailbox's owner.

Not every source can do this, and the honest version matters: some are read firm-wide. Salesforce and HubSpot are read at organisation scope, so what they contribute is visible to everyone in the memory regardless of who could see the record in the CRM. That is stated on those pages, in the behaviour table and again in a section of its own, because it is exactly the thing a security review is looking for and exactly the thing a vendor is tempted to leave vague.

What is the intersection rule?

A derived fact inherits the narrowest visibility of everything it was derived from.

Work an example. A fact is built from two documents: a board deck the whole firm can read, and a committee minute only four people can. The resulting fact is visible to those four. Not to the firm, not to some union of the two, not to whoever happens to have been running the extraction. The narrowest input decides, and it decides at every step, so a fact three derivations deep is still bounded by the tightest thing at the bottom of it.

The direction is what makes this useful. Composition can narrow and cannot widen. There is no arithmetic in the pipeline that produces a wider audience than its inputs had, which means no amount of summarising, digesting or re-deriving can turn a restricted document into a general one.

A permission can only ever narrow. That is a property of how derivation composes, not a rule somebody remembered to enforce.

Why is it applied in the query rather than afterwards?

Because filtering a finished answer is the failure described above. Instead, the asker's resolved principals are a clause in the query that assembles the answer, so restricted evidence is never in the working set to begin with. The answer a junior receives is not a redacted partner's answer; it is the answer the permitted evidence supports, which is a different sentence.

And it fails closed. If the principal set cannot be resolved, nothing comes back. The failure mode of the identity layer is silence rather than disclosure, which is the only acceptable direction for that particular bug.

What about revocation?

This is where the honest part goes. When access is withdrawn at the source, the next poll notices and the document leaves that person's world — and, importantly, the facts already derived under the old permission are tombstoned rather than left readable. Revocation reaching derived facts was a defect once. It is not now.

What remains is a narrow race, and we would rather name it than round it off: work already in flight when the narrowing lands can write a row citing a document that has just been taken away. It is limit two of seven, published in our own words, with the window it applies to.

There is also a scope limit worth knowing before you connect anything. The per-item story only applies where the source keeps per-document permissions at all — Drive, SharePoint, OneDrive, Box, Confluence, Slack, Gmail. For the firm-wide sources it is not narrowing anything, because there was nothing per-person to inherit.

Does narrowing ever produce a worse answer?

Yes, and it is the right failure to have. A digest built for a restricted audience draws on less evidence than one built for a wide audience, so it can be thinner — occasionally thin enough that a reader with narrow access gets less than they could usefully have had.

That is an over-trim, and it is categorically different from a leak. One means somebody sees less than they might; the other means somebody sees what they must not. Any system that composes permissions by intersection will over-trim sometimes, and the moment you start tuning that away you are trading the property the whole design exists to guarantee against a marginal improvement in answer quality.

So the answer is to make over-trims visible rather than to relax the rule — a reader who can see that evidence exists which they cannot open is in a position to go and ask for access, which is the correct organisational outcome.

How would you check any of this?

Two accounts and one document. Give one person access to something the other cannot open, ask both the same question, and read the answers side by side. The restricted evidence should not merely be absent from the second answer — the second answer should be a different answer, built without it, and its citations should name only documents that person can open.

That is the test we would run, and it is why the security page describes isolation as a model rather than a promise: one schema and one object-store prefix per firm, optionally enforced by database roles, with visibility composed inside that. The mechanism should be checkable by someone who does not trust us, because that is the only kind of check worth anything.