Skip to main content

Clean-room governance

A clean room is not a different product from a workspace. It is the same console with a governance layer on top, and the platform is deliberate about that: a clean room is the workspace experience, and the only difference is that it is clean.

That design decision has a consequence worth stating first: everything in the workspace catalog is present inside a room, scoped to the room. What follows is what is added, and what changes.

Two ways into a room

A room is reachable from the clean-room console, which carries the full workspace tool set plus the governance layer below, and from the catalog listing, which opens a narrower detail view built around the governance surfaces, assets, notebooks, runs and the bindings.

If a tool described in the workspace catalog is not where you expect it, check which of the two you are in. The governance layer below is present in both.

The governance layer​

Seven surfaces exist only in a room.

SurfaceWhat it does
ConnectThe governed access recipe, led by its constraints rather than by a connection string
PartiesThe collaborator manifest: who is in the room and in what role
Privacy budgetThe differential-privacy ledger that gates, not a report
Egress & DLPAllowed and denied destinations, the default action, the row cap, whether loss prevention is required, and output watermarking
Graph governanceCross-party edge denials, and the audit of what was refused
RunsGoverned run history with export anchors and the privacy budget each run burned
AuditThe tamper-evident chain, with a per-row anchor

Connect leads with the constraints​

The access surface presents the k-anonymity threshold, the privacy-budget ceiling, the per-collaborator budget, whether loss prevention is required, the maximum rows and the watermark before it presents an endpoint.

Enforcement is in the wire, at query time. Aggregates flow; raw rows and results below the anonymity threshold are refused deny-closed, with a standard permission-denied code rather than a silently truncated result.

The endpoint is shown only if it is actually advertised. Where it is not, the surface says so rather than displaying an address that will not answer.

The privacy budget is a ledger, not a report​

This is the most carefully built thing in the room, and the reason is a single design decision worth understanding.

The budget is summed from per-collaborator consumption records, deliberately not from the run list.

The run list is paginated and excludes deleted runs. Computing the budget from it would mean that deleting a run gives budget back, and privacy loss does not work that way. Once a query has revealed information, deleting the record of it does not un-reveal it.

So the ledger is authoritative, the runs view is a view, and the two cannot be made to disagree by an administrative action.

The surface shows total, consumed and remaining, with tone changes as the budget approaches exhaustion, and a per-participant breakdown.

Egress is default-deny, and denial always wins​

The room's defining guardrail:

ControlBehaviour
Allowed destinationsAn explicit allow list
Denied destinationsAlways wins over the allow list
Default actionDeny is the recommended setting
Maximum output rowsA hard cap on what can leave
Loss preventionCan be required on every result
WatermarkingForensic provenance stamped on output

Editing the policy requires a strictly higher permission than reading it. A collaborator who can work in the room cannot widen the room.

Assets are aliased​

A contributed asset is visible to other collaborators by its alias. The source identifier is never shown.

That is what makes a room usable between parties who are willing to compute together but not to reveal their schema, their naming, or where the data came from. The alias is the contract surface; the source stays with its owner.

Notebooks are reviewed, and editing resets approval​

Clean-room notebooks move through a state machine rather than being run: draft, pending, approved or auto-approved, or rejected. Each carries its version and a version hash.

Approval is keyed to the version hash. Submitting a new version invalidates every prior approval.

There is no path by which a notebook is approved, quietly edited, and then run. Approval requires a threshold of distinct approvers, configurable per room, alongside auto-approval rules for cases that do not warrant a human, such as a short notebook with no egress.

Reviewers see a full diff and approve or reject with a comment.

Runs carry a signature chain​

A run's output is anchored: an output hash and a runner signature, presented as verified, pending or missing rather than assumed.

The detail view shows the whole chain, from the notebook version hash, through the reviewer signatures, to the runner signature, to the output hash. Each link is checkable, so "this output came from that reviewed notebook" is a verifiable statement rather than a workflow assumption.

Each run also records the privacy budget it burned, which is what connects execution to the ledger above.

Graph governance​

Cross-party graph work has its own surface, because joining two parties' graphs is exactly where a clean room can leak.

It records the edges that were refused across the party boundary, denies external backends closed, and audits write-back. A denial is a first-class, recorded event rather than an absence in a result.

Bind, never re-author​

The room's model for capability is consistent and worth calling out, because it is what stops a room becoming an ungoverned copy of the estate.

Agents, teams, automations, assistant sessions, functions and pipelines are bound into a room, not authored inside it. Each binding carries a role and a visibility, and for automations the binding also carries an authority scope that acts as the firing cap.

A binding can only narrow. It never widens the room's allow list.

So a capability that exists outside the room enters it under the room's rules, rather than the room acquiring its own parallel version with its own governance.

What changes about the shared tools​

The tools from the workspace catalog behave the same way inside a room, with specific, deliberate differences:

ToolWhat is different in a room
Agent observabilitySource names are aliased and raw provenance is withheld
Edge sourcesReads the governed endpoint, and actions that would reveal another party are disabled
External agentsOutbound delegation is egress-gated
GovernanceOnly the aggregate result and its attestation are shown. Ballots and the voter roster are never projected
LifecycleCross-organization transfer consent becomes N-of-M across the room, not a single owner's decision
HealthAdds anomalies, presence, per-collaborator trust and coherence, and applies coarsening: a caller sees their own findings plus a room-wide count, with no actor identifiers
SIEMThe room has its own event lake, sealed under its own key. It is a peer of a workspace's, not a view onto one
RepositoriesA live clone is blocked, because it is network egress a sealed room must refuse
Data productsPublished from a succeeded run's governed output, room-scoped and restricted by default
NotebooksPlain authoring becomes the review workflow above

The pattern: gate and show, rather than omit. A tool that is constrained in a room appears with its constraint stated, so a collaborator learns the boundary rather than wondering where a feature went.

Setting the policy at creation​

A room's governance is chosen when it is created, not retrofitted: the anonymity threshold, the privacy-budget ceiling and the per-collaborator budget, whether output review is required, the key-rotation interval, the approval threshold, and the auto-approval rules.

Classification travels with the room​

A room carries a classification, a compartment label and an operating-mode badge, and those are rendered as persistent chrome on every surface rather than on a settings page. A restricted room says so wherever you are standing in it.