# 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](https://docs.nationalcompute.com/market.md)).

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](https://docs.nationalcompute.com/kubernetes.md)), Slurm tenants get their own login node,
controllers, and scheduler ([Slurm clusters](https://docs.nationalcompute.com/slurm.md)), and a VM
capacity grant hands you the node over SSH, reachable by the keys
your organization registered ([VM capacity](https://docs.nationalcompute.com/api/vm-capacity.md)).
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](https://docs.nationalcompute.com/market.md)).

## 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](https://docs.nationalcompute.com/faq.md)).

## 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](https://docs.nationalcompute.com/authentication.md) has the full model.

## Marshall data sharing

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](https://docs.nationalcompute.com/marshall-data-sharing.md). 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.