Clean rooms
A clean room is what a workspace becomes when more than one trust domain is in the room. It is not a more secure workspace, and it is not a filter over a shared one. It is a governance overlay with a different assumption underneath: the collaborators do not trust each other, and the room has to hold even if one of them is adversarial.
A new room is created deny-all by default.
What the overlay adds
| Mechanism | What it does |
|---|---|
| Per-room collaborator roles | Admin, contributor, reviewer, runner and observer. Separation of duties inside the room, distinct from workspace roles, so a party can contribute data but never run, or never see output |
| Asset aliasing | The only name another collaborator ever sees is a per-room alias |
| Approval-gated, signed notebooks | Code is reviewed and cryptographically signed by M-of-N reviewers before it can run, and an edit resets approval |
| The egress gate | Every output passes an ordered set of checks, defaulting to deny |
| Output watermarking and hashing | Forensic per-row markers, and an output hash before anything materialises |
| A per-room key with rotation | Crypto isolation per room, minted at creation |
| Signed, hash-chained run audit | Every run is signed and its output hashed, into the room's own tamper-evident ledger |
| Compartment and region constraints | Clearance and placement constraints on where the room may run |
| Governed bindings | An agent, function or pipeline bound into a room has its authority intersected most-restrictive-wins with room policy at execution |
Aliasing happens before compute, not after
This is the mechanism most often done the weak way elsewhere, so it is worth being precise about the ordering.
Notebook bodies are alias-rewritten before they reach compute, so the kernel never sees source table names at all. A result un-aliases only the recipient's own names. A collaborator therefore cannot learn another party's schema by reading an error message, inspecting a query plan, or watching what a job touched, because the true names were never present in the execution context.
The egress gate, in order
Every output crosses the same ordered gate, and the first failure terminates the run rather than trimming the result and continuing.
Figure: the egress gate. Six checks in a fixed order, each able to stop the run. The destination check defaults to deny, so a room releases nothing anywhere until an operator names where. Only output clearing all six is released, and it is watermarked, hashed and signed on the way out.
Table equivalent
| # | Check | What it enforces |
|---|---|---|
| 1 | k-anonymity | No result small enough to re-identify an individual |
| 2 | Max output rows | A hard cap on volume leaving the room |
| 3 | Per-collaborator differential-privacy budget | Each party's cumulative privacy spend |
| 4 | Per-run epsilon ceiling | One run cannot consume the whole budget |
| 5 | Destination allow or deny | Default deny. Nowhere is a valid destination until named |
| 6 | Content inspection | Data-loss-prevention over what is actually leaving |
A privacy budget is a spend, not a setting. Once a collaborator's budget is consumed it is consumed, which is why the room surfaces a differential-privacy budget panel rather than leaving it to be discovered at the gate.
The room is a console, not a sub-page
A clean room opens as a first-class console at its own route, a peer of the workspace rather than a tab inside a catalog listing. Every section is deep-linkable and bookmarkable, with dedicated notebook-review and run-detail pages.
It reuses the same experience registry as a workspace rather than forking it, and tags its own tabs: assets, notebooks, runs, agents, coding, repositories, CI/CD, automation, functions, pipelines, products, health, logs and SIEM.
Four tabs are always on, specifically because they are the room's guarantees: overview, the room's assistant, egress and data-loss prevention, and audit. A persona switch can never take the room's isolation controls off screen. An experience with no tab of its own in a room, consulting for instance, is simply not offered in the switcher, so the switcher only ever offers reachable views.
Supporting surfaces include a parties panel, a governance panel, the differential-privacy budget panel, a signature-chain panel, an audit-chain anchor, a classification context stripe, restricted-access and restricted-scope banners, an activity-ledger viewer and a creation wizard.
Leaving the room
A joint result computed under mutual distrust can be promoted into a governed data product, which is usually the commercially interesting end of a clean-room engagement: the parties keep their raw data and the collaboration produces something with an owner, typed ports and a contract.
Cross-organization transfer of a clean room is default-prohibited without recorded N-of-M consent from every collaborating organization, because one party cannot unilaterally export another party's data and consent context. Per-room keys are re-sealed on a move.
A clean room is policy-based isolation with a signed run chain, not a hardware trusted execution environment. The documented compensation for not having an enclave is that every run is signed and the room's activity ledger is hash-chained and tamper-evident.
A room runs on one cell at a time, so moving one between cells is a cutover rather than a live spread. Cross-cell clone, archive and recovery for rooms are driven operations, and each vets the target fail-closed: the room's differential-privacy budget cannot land reset to full, a room requiring output review cannot land on a cell that will not honour it, a collaborator who has not consented to replication egress blocks the copy, and a target cell not cleared for the room's compartment or outside its region constraint is not a valid target. See clean-room disaster recovery for the two limits that remain: no mid-run re-placement, and the admission gate applying on failover rather than failback.
The room's approval, signing, aliasing and egress machinery is real and describable, and the compute path behind it is complete. No clean-room notebook run has been observed end to end, so describe the governance rather than narrating a run. The governance is the story here and it does not need the run.
The competitive shape
The nearest rival concept is a clean room inside a vendor's cloud. Two differences matter and both are structural.
It is a partition, not a filter. Aliasing before compute, M-of-N signing of the code itself, and an ordered egress gate that terminates rather than trims are properties of how the room executes, not rules applied to results afterward.
It runs where you need it. The room is on-premises capable, air-gap capable, sovereign and multi-cell, because it is an overlay on a cell you own rather than a feature of someone's control plane. A residency regime that forbids pooling data in a vendor's region does not forbid this.
Related
- Choosing a boundary, one trust domain or more than one.
- The boundary model, what a room overlays.
- Monitoring and activity, the room's own ledger and logs.
- Classification, the clearance and compartment constraints a room carries.
- Data products, what a joint result can become.