Sovereign mode
Run everything on your own hardware, under your own key — no control plane, nothing leaving your perimeter.
For a bank, a regulator, or any workload where the answer to "who has access to the box" must be nobody but you, run in sovereign mode. SCSA is a set of binaries that run on your GPU host. There is no control plane in the middle and no external party authorized on the machine.
What runs on the node
| Binary | What it does |
|---|---|
scsa-vault | Seal and unseal to the attested GPU; attest; anti-replay and Confidential-Computing self-tests |
scsa-sealmodel | Seal a safetensors model, and unseal it |
scsa-infer | Unseal weights into VRAM only and run inference; prove in-VRAM consumption |
zk-cli | Generate and verify transparent STARK audit proofs |
scsa-verify | Check a decision envelope offline, from bytes alone |
They are self-contained and build from source on your hardware. Only a CUDA 12.x
driver is required — no nvcc, no repo checkout, no external download. A
sovereign deployment can run fully offline.
Sealing a model
scsa-sealmodel seal model.safetensors -o model.scsa --model-id my-model
scsa-sealmodel unseal model.scsa -o model.safetensorsThe key is derived from your GPU's identity and never leaves the machine. The
.scsa is inert on any other hardware. scsa-vault check model.scsa verifies the
GPU matches without decrypting.
Running inference without the weights ever landing
scsa-infer run model.scsa --input <data>
scsa-infer vram-proofWeights are decrypted in GPU memory only. They never exist as files. vram-proof
demonstrates that the decrypt-and-consume path stays inside VRAM.
Recovery, deliberately chosen
scsa-vault seal secret.bin -o secret.scsa --shards 3 --threshold 2
scsa-vault seal secret.bin -o secret.scsa --single-deviceThe default is 2-of-3 recovery shards, because binding to one GPU means GPU
loss is data loss, and most people do not want that discovered during an incident.
--single-device opts out and is exactly as absolute as it sounds — there is no
recovery.
--expiry <HOURS> and --max-unseal <N> bound the seal in time and in uses.
Attestation tiers
scsa-vault reports which tier it can actually reach on your hardware, and
refuses rather than pretending:
| Tier | Binding |
|---|---|
| 1 | GPU measurement + driver/VBIOS, no TPM |
| 2 | GPU measurement + TPM-sealed secret, bare metal |
| 3 | GPU fused key + TPM in Confidential Computing mode — not yet available |
scsa-vault attest --nonce <64-hex>
scsa-vault verify-replay # an attestation for one challenge must fail against another
scsa-vault cc-check # fail-closed Confidential Computing enforcementOn a GPU without Confidential Computing, attest and cc-check fail closed —
the gate correctly refuses rather than pretending. See Proofs
for how to read the verdicts.
Why this is the sovereign path
- No control plane. The binaries run on your box. There is no server to trust, meter, or compromise.
- Your key only. Nothing from the operator is authorized on the machine.
- Air-gap friendly. The binaries phone home to nothing.
The strongest posture
Sovereign mode removes the operator from the loop. To also remove the need to trust any single machine or party — including your own operators — combine it with threshold custody, where the key is split so nobody holds enough to unseal alone, and with the Authority Fabric if you want each use to be a governed, logged, offline-checkable decision.
Security then rests on the math: hardware-signed attestation plus threshold cryptography.