A Summary of Privileged Material Is Privileged Material

The usual way a wall fails is not that someone opens a door. It is that a summary walks through one. An answer generated from privileged material is a new document, made of the old ones, and if it is stored with looser permissions than any of them then the wall has a copy of everything on the wrong side of it. We had a version of this. We found it by reading what our own system had stored. This is the rule it left behind.

Where an answer's permissions come from

In Yohanun, access is decided before the model is involved: the retrieval query carries the asker's clearances, and the model is shown only what they may see. That is the well-known half. The less obvious half is what happens to the answer afterwards. It is stored, so that the conversation continues and the record is complete, and a stored answer needs labels: which compartment, what classification, who owns it. We do not ask the model for them. The platform computes them from everything the answer was given, not only what it cited, on the principle that a summary of privileged material is privileged material.

Two of the three labels were always right. The compartment is the most sensitive one among the sources. The classification is the highest. Both only narrow. The third label, ownership, is where the mistake was.

The union, and why it leaks

Personal memory in Yohanun is owner-walled: a memory with owners returns only to a principal who is one of them, or who holds a key that is. Owners can be a person, or a shared key, such as a circle's or a set's. For a stored answer, the rule was: the union of the owners of every owned source. It reads sensibly. If my private note and the team's shared note both fed an answer, then the answer belongs to me and to the team.

It is wrong, and the failure is exact. The team could not see my note. The answer, which paraphrases my note, is readable by the team. My note has just been shown to the team by way of a summary, with no door opened. The union of the owners is the set of people who could see some of the sources. A wall for the answer needs the set of people who could see all of them.

Reading what was stored

We found it while building Library for Irenaeus, our deployment for a set of chambers. A member asked Library a question that drew on their own kept work and on the set's shared know-how. The proof passed: the answer was right and cited its sources. Then we read the stored turn on the live walkthrough and looked at its owners, and there was the set's key. Any member of the set could have retrieved a paraphrase of one member's private work.

The lesson we took was about proofs before it was about walls. A proof that reads the stream's output checks the answer. It does not check what the system did with the answer afterwards. Every proof of ours that stores something now ends by reading it back, and by reloading the page, because the page is what a colleague sees a day later.

The rule now, in three parts

First, the intersection. A stored answer carries the owners common to every owned source it drew on. My note and the team's note have no owner in common, so the answer carries neither and falls to the second rule.

Second, the asker alone. Where no key covers every source, the answer belongs to the person who asked and to nobody else. They could see everything the answer was made from; nobody else is known to. The same rule applies when a consumer asks the platform to label the turn: a label can only narrow. If the label and the inherited wall share keys, the answer carries those; if they share none, it is the asker's alone. A question is as private as its answer.

Third, more than one compartment. A memory carries one compartment label. An answer drawn from matters A and B is stored under one of them, and stored tenant-shared it was readable by a colleague cleared for that one matter alone, while paraphrasing the other. So a turn that drew on more than one compartment is the asker's alone, always, and the platform tells the consumer it happened: how many compartments, never which. For a set of chambers this is the case that matters most, and the walkthrough now shows the asker being told.

What we did not do

We did not give a memory several compartment labels. It is the obvious generalisation, and it would let an answer across A and B be labelled with both and read by someone cleared for both. We think it is right eventually and wrong now. It changes the meaning of every gate condition, it needs a decision about what "cleared for both" means when clearances are revoked one at a time, and no deployment has yet asked for it. The asker-alone rule is narrower than ideal and never wrong, and that is the correct place to stand until someone with linked matters is in the room.

The general point

Anyone storing model output next to the sources it was made from has this problem, whether or not they have noticed it. The permissions of a derived document are not the union of its sources' permissions. They are the intersection, and when the intersection is empty they are the author's. It is the same rule a court applies to a summary of a privileged file, which is not a coincidence: the law has been keeping derived documents inside walls for a long time, and we borrow from it whenever we can. The full rule is written into the platform's documentation under "what a stored answer inherits", with the proof that holds it.