Encrypted Model Weights

An extension of confidential computing: the checkpoint is encrypted at rest, and its key is released only while the host attests.

What it protects

Tensor data — the weights themselves — at rest and in transit to the machine, and in use only inside memory the hardware encrypts.

What stays readable, and why

The model’s configuration, tokenizer files and the weight index remain plaintext. The engine must read them to construct the model before any key exists, so the architecture and tensor names and shapes are visible.

That is a real limit of the design rather than an oversight, and it is worth stating to anyone evaluating the feature: what is protected is the weight values, not the fact of which architecture you are running.

How the key flows

1. The key is sealed to this deployment.
2. At server start Lifeboat asks for its release. Release is refused unless the host currently attests — a leaked database row and a leaked sealing key are useless outside the same attested environment.
3. The released key is written to a tightly-permissioned file on a memory-backed filesystem and handed to the engine.
4. Shards are decrypted into memory, never to disk. Inside a confidential VM that memory is hardware-encrypted.
5. The key file is discarded when the server stops. A released key left lying around would undo the gate that guarded its release.

Every launch path re-releases the key, including automatic restart after a crash and start after a reboot. That is also the correct security behaviour: attestation is re-checked rather than inherited from whenever an operator first started it by hand.

Operator workflow

1. Encrypt the checkpoint on a trusted machine with the bundled tool, generating or supplying a key.
2. Verify the encrypted checkpoint — decrypt and authenticate every shard, writing nothing — before deleting the plaintext.
3. Seal the key into the deployment.
4. Register the model as encrypted and start a server.

The tool emits the key before encrypting, so an interrupted in-place encryption cannot leave encrypted shards whose key was never shown. It also refuses to run when non-safetensors weights are present, unless overridden — otherwise the “encrypted” checkpoint ships with a plaintext copy of the same weights beside it.

Current limits

• Local node only. Remote node attestation is not wired up, so an encrypted model cannot be served from a node agent.
• One loader path. Formats outside the standard safetensors loading path are not covered, and an encrypted shard reaching one is refused rather than silently loaded as garbage.
• Requires an entitled licence and attesting hardware. On a non-attesting host the start is refused with the reason.

Sources and references

• The gate: Confidential computing
• Posture: Security posture