Request capacity

Overview / Security

Enclosed
by design.

Privacy is a property of where the boundary is drawn, not a promise in a policy. Ours runs around whole machines, is checked at every boot, and is verified by you — with keys we never hold.

Pre-launch This page describes the platform's security design. Independent audits have not been completed; reports will be published here as they are.

Section through the stack: workload, operating system and accelerators sit inside the tenant enclosure; firmware, network and facility below it are operated by Cloister Labs and measured.AAYOUR WORKLOADNOT VISIBLE TO USOPERATING SYSTEM · DRIVERSNOT VISIBLE TO USGPUS · CONFIDENTIAL MODECPU–GPU ENCRYPTEDHOST FIRMWARE · BMCMEASURED AT EVERY BOOTFABRIC PARTITION · NETWORK EDGEPORT COUNTERS ONLYFACILITY · POWER · COOLINGOPERATED BY USYOU CONTROLWE OPERATE
Section A–A · responsibility through the stack

  1. S-01.1

    Nothing shared below your operating system

    Whole hosts, bare metal. No hypervisor, no co-resident tenant, no shared top-of-rack port. Isolation does not depend on software we run beside you.

  2. S-01.2

    Measured, not asserted

    Every boot is recorded in hardware. You receive the record signed by keys in the TPM and the GPUs — evidence we relay but cannot alter.

  3. S-01.3

    Your keys, your decision

    Disk and weight keys stay in your key service. It releases them only to a node whose evidence matches your policy.

The attestation
sequence

Seven steps between an empty machine and your keys reaching it. Step through to see who signs each piece of evidence and how each step fails closed.

Sequence: control plane sanitises the node; the node measures its boot and asks GPUs for signed reports; evidence goes to your verifier, which releases keys only if it matches your policy.CONTROL PLANECloister LabsNODEfirmware · TPMGPUconfidential modeYOUR VERIFIERand key serviceerase drives · re-flash signed firmware1measured boot → TPM registers2enable confidential mode · request report3signed attestation report4TPM quote + GPU reports5check against policy · vendor references6release wrapped key7

All steps

  1. Before a node is assigned, its drives are cryptographically erased and its firmware is re-flashed from images signed by the vendor.

    Signed by
    Vendor firmware signatures
    Fails closed
    A node whose firmware does not verify is pulled from the pool.

  2. Each boot stage measures the next into the node's TPM before running it: firmware, bootloader, kernel and initial filesystem.

    Signed by
    TPM endorsement key
    Fails closed
    Measurements cannot be removed after the fact; a changed stage changes the record.

  3. The driver switches supported GPUs into confidential-computing mode, encrypting the path between CPU and GPU, and asks each GPU for a signed report.

    Signed by
    GPU device certificate, chained to the vendor
    Fails closed
    A GPU that cannot enter confidential mode is reported as such; your policy decides.

  4. Each GPU returns a report of its firmware and mode, signed by a key fused into the device.

    Signed by
    GPU device key
    Fails closed
    A missing or unsigned report is evidence of nothing, and fails verification.

  5. The node bundles the TPM quote and GPU reports and sends them to your verifier. We relay the evidence; we cannot forge it.

    Signed by
    Hardware keys only — not ours
    Fails closed
    Stale evidence is rejected by a nonce you supply.

  6. Your verifier compares the measurements with your policy and the vendors' published reference values.

    Signed by
    Your policy
    Fails closed
    Any mismatch stops the sequence. The node runs, but receives nothing.

  7. Only after verification does your key service release the key that unlocks your disks and weights — wrapped to that node.

    Signed by
    Your key service
    Fails closed
    Keys never pass through our control plane in usable form.

After release: when you stop a node, the sequence runs in reverse — keys are revoked, memory is cleared on power-down, and the node returns to step 1.

Confidential mode by accelerator

GPU confidential computing is a hardware feature. Where an accelerator does not support it, the node is still single-tenant and measured — but CPU–GPU traffic is not encrypted.

AcceleratorArchitectureConfidential mode
NVIDIA B300Blackwell UltraSupported
NVIDIA B200BlackwellSupported
NVIDIA H200HopperSupported
NVIDIA H100HopperSupported
AMD MI300XCDNA 3Not available
NVIDIA RTX PRO 6000BlackwellBeing verified
NVIDIA L40SAda LovelaceNot available

What we see,
keep and destroy

A complete list of what passes through our hands when you run on Cloister Labs, and how long it stays there.

DataVisible to usRetainedDetail
Workload memory and GPU memoryNo—Bare-metal hosts have no hypervisor of ours. In confidential mode, CPU–GPU traffic is encrypted.
Disk contentsNoErased between tenantsEncrypted with keys your key service releases. We hold no copy of those keys.
Model weights and datasetsNo—They live on your volumes or object storage under your keys.
Hardware telemetryYes13 monthsPower, temperature, ECC and link errors — what operating the hardware requires.
Network flow metadataPartly30 daysPort-level byte and error counters. No packet capture, no payload inspection.
Operator access sessionsYesLife of the accountEvery session requires your approval and its log is copied to your project.
Account, billing and API audit logsYes7 years / 1 yearBilling records as the law requires; API audit logs exportable by you.

What this does not protect against

Security claims without limits are marketing. These are ours.

Attacks on the silicon itself
Physical probing of memory buses or fault injection by someone with hands on the hardware. Facility controls reduce the opportunity; they do not make it impossible.
Vulnerabilities in vendor firmware
Attestation proves which firmware ran, not that it is free of bugs. We patch from vendor advisories and publish what we changed.
Your own software
An enclosure protects a workload from other tenants and from us. It cannot protect it from a compromised dependency inside it.
Lawful demands
If compelled to act on your account we will notify you unless prohibited — and we cannot hand over what we cannot decrypt.

Reporting a vulnerability

Write to security@cloisterlabs.com. A security engineer reads every report.

  1. 1

    Include what you found, how to reproduce it, and what an attacker could do with it.

  2. 2

    Expect an acknowledgement within two business days and a status update at least weekly until it is resolved.

  3. 3

    Act in good faith — don't access data that isn't yours, degrade service, or disclose before a fix — and we will not pursue legal action.

Security review for procurementAttestation guide