Access rules are enforced when the answer is written.
Each person receives only what they are permitted to see, enforced at the point of retrieval, not filtered afterward. The points below explain exactly how, and name the one trade-off we make, because a security story you can trust is one that doesn't hide its edges.
Six things that hold
Each one is how the system works, not a setting.
Each one is a property of how the system is built, not a setting an operator can switch off.
Everyone sees only what they're allowed to
Each person's update is built only from what they're permitted to see. The default is to share nothing, and a restriction always wins over a grant.
For your security team
Permission is enforced at retrieval, not by an app-layer post-filter. The per-person access-control list lives inside the single retrieve() SQL: an EXISTS allow-check combined with a NOT EXISTS deny-overrides check, where an empty grant set is default-deny. There is never a superuser read path and nothing is ever filtered out after the fact: retrieve()is the sole reader of the shared documents, so content a person isn't permitted to see never enters their result at all.
Nothing is made up
Every line traces back to a real source. Anything that can't be backed up is left out, and a maybe is never reported as a done deal.
For your security team
A deterministic source-validation stepdrops any claim whose source excerpt isn't in the requesting person's permitted set, so the model can never "fill in" an unsupported line, and can never surface an excerpt the person wasn't allowed to retrieve. Modality is preserved (an unconfirmed item stays unconfirmed; a verbal yes is never reported as a signed contract), and gaps are computed outside the model so a missing update is shown as a gap rather than smoothed over.
We never guess who someone is
If we can't tell which person something belongs to, we ask you. We never guess and never quietly hand out access.
For your security team
An ambiguous identity is routed to a person for reviewrather than resolved automatically. The system never auto-attributes content to a person and never auto-grants access on a best-guess match. Until a human confirms the identity, the content stays unattributed and out of everyone's scoped view.
Removing someone is immediate and verified
Remove a person and their access is cut off at once and pulled from every future update. We verify it's gone before giving you a receipt.
For your security team
Offboarding fails closed. In one operation it deactivates the person, revokes their linked identities, writes a durable hard-deny, and then verifies the result by re-running the retrieval query as the removed person and confirming it returns nothing, before the receipt is issued. If any step fails, the receipt is not produced; access is never left half-revoked.
Your company's data stays yours
Nothing crosses between companies.
For your security team
Every query is per-tenant scoped, and the schema carries composite tenant foreign keys so a row can only ever be joined within its own tenant. As defense-in-depth, row-level security (RLS) is available for multi-tenant deployments, so the isolation is enforced at the database layer as well as in application queries.
A full audit trail
Every update we deliver is traceable to where it came from, and from your operator console you can re-check it against today's permissions.
For your security team
Each render records per-render provenance (which source excerpts backed which lines) and supports a logged-vs-current replay: you can re-run a past render against the current permission state and diff what would be included now versus what was included then, so a permission change is auditable after the fact.
One trade-off, in the open
If a permission is changed in a linked system, such as an HR system or shared calendar, there can be a brief window before that change is reflected here. We flag every such case to you as a count, never the content. Known removals are always immediate.
For your security team
A stale permission from a linked system is, by deliberate design in the current pilot period, flagged to you rather than withheld silently: the affected items are surfaced to you as a count, never as content. A known revocation always fails closed (see immediate, verified offboarding above). The leak-invariant test suite, which proves no denied excerpt can reach a scoped update, is a required CI check, so this trade-off is the one stated exception rather than an unbounded gap.
Live demonstration
Two people, the same documents, two different views.
The live demo runs the exact permission-aware retrieval path production uses: two people ask the same system over the same shared documents and get different scoped views. What one person cannot see is simply absent from their result; it is never present and then removed.