Trust Center¶

Tenant separation rests on two mechanisms: every tenancy holds whole nodes in a dedicated cluster, and a node that leaves a tenancy is sanitized before it can serve another. This page states what each mechanism does, what evidence it leaves, and — because a security page is only useful when it is honest — what the platform does not claim.

Tenant isolation¶

The market assigns whole nodes — a host serves one organization at a time, never two (Burst capacity).

Every tenancy is a dedicated cluster with its own control plane and its own credentials: Kubernetes tenants hold the kubeconfig and cluster-admin on their own cluster (Kubernetes clusters), Slurm tenants get their own login node, controllers, and scheduler (Slurm clusters), and a VM capacity grant hands you the node over SSH, reachable by the keys your organization registered (VM capacity). For GPU capacity there are no shared multi-tenant namespaces and no shared schedulers — the tenant boundary is the cluster boundary. Marshall workspaces hold no GPUs: each runs as its own pod on a shared workspace plane outside the tenant clusters, separated from every other workspace by network policy and identity.

Each GPU host runs a default-deny inbound firewall rendered from the platform's record of cluster membership and re-applied on every node move. A node holding no tenancy either answers to platform management alone or no longer exists — released and reclaimed nodes are destroyed (Burst capacity).

Node sanitization¶

A node that leaves a tenancy is sanitized before it can join another. Every site declares its mechanism — wipe in place or recycle — and a site that declares neither cannot move nodes between tenants at all: the system fails closed rather than moving an unsanitized node.

Wipe in place. GPU memory (HBM) is overwritten with zeros — the GPU driver does not zero freed device memory, so without this step the next tenant could allocate memory and read the previous tenant's residual weights, activations, or cache. Local scratch devices are discarded at the block layer, sampled reads of the raw device are verified to return zeros, and the filesystem is recreated empty. There is deliberately no file-by-file deletion fallback: a device that cannot prove zeroed blocks aborts the move, and the node stays out of service.

Recycle. The node is destroyed and replaced outright rather than wiped; the replacement carries fresh filesystems whose identities are recorded as the receipt. Nothing of the previous tenant's filesystem survives into the replacement.

Credentials do not travel with a node. The per-cluster authentication material, Kubernetes state, and tenant volume data on the node are destroyed when it leaves, and a node holds a tenant's credentials only while it serves that tenant.

Node-local disks are not encrypted at rest: the boundary between one tenant's bytes and the next is the sanitization above, not a key. Treat node-local data as ephemeral and keep durable state off the node (FAQ).

Audit records¶

Control-plane actions are audited — accepted and refused alike. Audit records land in append-only database tables (a trigger refuses updates and deletes) and are exported hourly to write-once object storage under a locked retention policy, currently 400 days: for that window nothing in the pipeline — or outside it — can overwrite or delete an exported record. The sanitization tools emit their own receipts: the wipe's zero-read verification, the recycle's fresh filesystem identities.

API credentials¶

Org API tokens are stored as SHA-256 hashes and compared in constant time; the plaintext secret is shown once, at mint, and never stored. Expiry is mandatory — 365 days at most — and revocation on the console is immediate. A token is one grant for the whole organization, and destructive actions (deleting a preserved volume, changing billing settings) refuse every token, requiring a console session. Authentication has the full model.

Data sharing from Marshall sessions is an organization-level setting in the console (Settings → Data sharing); since 1 October 2026 the baseline for an organization that has never set a tier is tier 1, redacted conversation transcripts, and tier 0 is one click away; the tiers are documented here. At tier 0 the platform collects usage analytics and the feedback notes members write to us, never message content. Higher tiers add redacted conversation transcripts and, at the highest, training artifacts matching published patterns. Collection stops as soon as an organization lowers its tier; data collected earlier is kept under the tier in force when it was collected. Collected data lives in dedicated object storage under the platform's own account, encrypted at rest by the storage service, with access limited to platform staff by access policy and every read and write of it logged; every record carries the consent it was captured under. Redaction of credentials and secrets before storage is automated and best effort.

Web analytics¶

The console, including its sign-in pages and public pages, and this documentation site use Google Analytics to count page views and in-page navigation. Each view sends the page address, a browser cookie that identifies the browser, and standard request metadata to Google. It never sends message content, credentials, or account details. The organization name in a console address reaches Google as part of that address. Google Signals and advertising personalization are off. Administration pages carry no tag.