Tiered data access and the answer you cannot give

Enterprise AI systems increasingly sit on top of tiered data. A junior analyst can see the public filings and the team's working notes. An executive can see those plus the board deck, the pipeline forecast, and the deal terms. Both are legitimate users. Both will ask the system strategic questions, sometimes the same question on the same afternoon.

The mechanism everyone reaches for is row-level security: retrieval returns only the records the user is authorized to see, and the model answers from what it was given. This is correct as far as it goes, and I have built it more than once. Authorization travels with the run; the model never sees a row the user could not have pulled themselves.

The junior analyst asks, "Should we pursue this opportunity?" The executive asks the same. The system, answering honestly from each user's evidence, produces two materially different recommendations. The executive's is better, because the executive's evidence is better.

The question that kept me up was not whether the junior analyst should get the executive's answer. Obviously not. It was what the system owes the junior analyst about the fact that a better answer exists.

Say nothing, and the analyst acts on an answer the system knows to be incomplete. Say "a better answer may exist," and you have created what the multilevel-secure database literature called an inference channel thirty years ago: the analyst asks enough questions, notes where the disclaimer appears and where it does not, and maps the shape of the restricted data without ever reading a restricted row. A selective disclaimer leaks everything. A blanket disclaimer on every answer leaks nothing and means nothing.

This is an old problem. Polyinstantiation was the classic answer: the lower tier receives a coherent record that is true at its level and never learns another version exists. What is new is the language model. Retrieval can be locked to the user's tier perfectly, and the model can still interpolate toward the withheld conclusion from public context, because it has read a great deal of public context about how deals like this one tend to go. The boundary is no longer the retrieval layer. It is the model's ability to reason past the evidence it was handed.

Three rules, in order of how much they cost me to accept.

First, answers are tier-complete and tier-silent. The junior analyst's answer is composed from the junior analyst's evidence and says so in its receipt, listing what was consulted. It does not say what was not consulted, and it does not vary that silence by question. The disclaimer, if you want to call it that, is structural and constant: every answer on every tier shows its evidence. That is polyinstantiation with a citation trail.

Second, the model is not allowed to conclude past its evidence. Every factual sentence must trace to a selected record, and a validator enforces it. This is the same discipline that keeps the assistant on this site honest, applied to a harder problem. The model may synthesize; it may not extrapolate to a recommendation the records do not carry. Where the evidence runs out, the answer says the evidence runs out, and that sentence is identical whether the missing evidence is restricted or simply does not exist.

Third, the interesting questions get a human. When the system detects that the same strategic question is being asked across tiers, that is not a security event. It is a signal that the organization has a decision to make and the people making it are not looking at the same facts. The right output is a flag to the executive, not a cleverer answer to the analyst.

The option I rejected was tier-aware generation: let the model see the restricted evidence and write a redacted answer for the lower tier. It is tempting because the redacted answer would be better calibrated. It is wrong because a model that has read the restricted rows will leak them in emphasis, in what it chooses not to say, in the confidence of its hedges. You cannot redact a model's state.

The junior analyst gets a worse answer than the system could produce, and does not get told so. I have made peace with that by remembering what the alternative does to the restricted data, but it is a real cost, borne by the person with the least power in the room.

The validator that stops the model from concluding past its evidence also stops it from being insightful past its evidence. Some of the best things a model does are exactly the leaps this rule forbids. Inside a tiered enterprise system, that is the right trade. It would not be the right trade everywhere.

And the third rule means building a path to a human, which is an organizational commitment, not a feature. Systems that flag decisions to executives only work when an executive has agreed to be flagged.

Row-level security answers "what may this user retrieve." It does not answer "what may this system conclude." Once a model is in the loop, those are different questions, and the second one is where the leak is.

Design the answer for the lowest tier first, make every answer show its evidence, and never let the disclaimer vary with the question. The information you are protecting is not in the rows. It is in the pattern of what you decline to say.