Skip to main content

Workspace and Org Isolation

Isolation between organizations and workspaces is not a claim on a slide here, it is a boundary that is measured, exercised through the real routes, and pinned by a ratchet that can only tighten. Two ideas do the work: oversight sits above the governed unit, and every administrative read that could return another party's rows is either confined to the caller's own scope or raised to an authority that sits above any single organization.

Oversight sits above the governed unit​

Whether a principal may administer an organization, a node, a workspace, or a clean room is answered by one scope model, the same (kind, id) question on every surface, rather than a special case per resource. Above every governed unit sits an oversight authority:

Figure E7: oversight above the governed unit. A platform or SOC operator (green) holds an authority that no organization-scoped grant satisfies, and reads across the estate through cross-cutting consoles. An organization administrator is row-confined to its own rows and is refused exactly those cross-cutting consoles (red). Oversight is one plane over every container, not a back door into a peer's data.

Table equivalent

CallerMay readRefused
Platform / SOC operatorAcross the estate, via cross-cutting consoles: (this is the oversight authority)
Org administratorOnly the org's own administered rowsCross-cutting consoles that would return another party's rows
Any admin listingNarrowed to the caller's scope, or raised to oversightAn open listing that returns another party's rows

The boundary is measured, not asserted​

Every admin listing and by-id read across the platform's services was checked against a scanner and, where it could return another organization's rows, either row-confined to the caller's own administered scope or raised to the oversight authority. The residual set that stays open by design was driven down and then pinned:

  • The residual open ("unconfined") set was reduced from a carried figure of 299 to a measured floor of 36.
  • Every one of the 36 is classified: protocol-public endpoints (OIDC / SAML / SCIM metadata), genuine node or platform operator consoles, or reads self-scoped to the caller's own rows.
  • A shrink-only ratchet pins that floor. It can fall, never silently rise.

Figure E7b: the measured shrink. The unconfined set fell from a carried 299 to a measured floor of 36, each of the 36 classified as protocol-public, an operator console, or a self-scoped read; a shrink-only ratchet keeps the floor from rising silently.

Table equivalent

FigureMeaning
299Carried figure of admin reads that could return another org's rows
36Measured floor after confining or raising every reachable one
The 36Protocol-public metadata, operator consoles, or self-scoped reads
RatchetShrink-only: the floor can fall, never silently rise

Proven two-party, in both directions​

The boundary is exercised through the real mounted routes with the real authorization resolver (no allow-all stub) with two organizations and a sabotage in both directions on each control: break the gate and the other organization's rows come back; over-tighten it and the caller loses their own. A passing check therefore cannot be a hollow one.

Stores scope to a workspace or clean room​

The isolation boundary rests on a data model where every store maps back to a workspace or a clean room. A workspace has its own hash-chained activity ledger; a clean room has its own audit plus a signature chain over its runs. These are separate, scoped stores (not filtered views of one shared log) and they hold identically single-cell and multi-cell. See the entity model and audit and tamper-evidence.

Terminology

The unit of isolation is the organization, the workspace, and the clean room. System9's own vocabulary, not a generic isolation label. Oversight authority (platform / SOC operator) sits above them.