Data at Rest vs. Data in Transit: Cryptographic Security on Element 31 Devices

It is a common assumption that once a system is air-gapped, encryption stops being an urgent question. If the box never talks to the outside world, the reasoning goes, there is no wire for an attacker to sniff and no cloud provider's key management to trust or distrust. That reasoning collapses the moment you ask two sharper questions: what happens to the data on the drive if the box is stolen, and what happens to the data moving between the box and the workstations, storage, and services it talks to inside the facility. Neither question is answered by "it's air-gapped." Both are answered by cryptography, and by different cryptography, because at rest and in transit are different threat models wearing the same name.

This is worth being precise about, because the two categories get collapsed more often than almost any other pair of security terms. "The data is encrypted" is not a complete sentence for an auditor or an adversary. Encrypted at rest, with what key, held where, unsealed under what condition? Encrypted in transit, between which two points, authenticated how? An appliance with a clean answer to one and a vague answer to the other has a real gap, and sealed hardware does not close that gap by virtue of being sealed. It has to be built to close it.

Data at rest: the threat is possession, not the network

Data at rest on an E31 device is model weights, retrieval indices, cached context, fine-tuning corpora, and the key material governing access to all of it, sitting on physical storage inside a unit that, by design, lives somewhere the vendor does not control. That is the reason at-rest encryption matters here differently than it would for a server in a vendor-operated data center behind that vendor's own physical controls. An E31 appliance ships to a customer facility, a partner site, or in some deployments a field location, and the threat model has to include the ordinary case: the unit is stolen, a drive is pulled, or a shipment goes missing.

The property at-rest encryption has to deliver is narrow and concrete: physical possession of the storage media is not, by itself, sufficient to read what's on it. The data on disk is encrypted with keys that are not sitting in flash next to the ciphertext they protect. Those keys are either held in protected key-management hardware that resists extraction, or unsealed only as part of a boot sequence the appliance validates end to end. That sequence checks that firmware is signed, the enclosure has not been tampered with, and the chain of trust from power-on to running system holds before storage keys are ever released. A tripped tamper indicator is one of the signals that chain checks against, and depending on deployment posture, it can be configured to halt the boot rather than complete it.

It's worth naming what this does not claim. No vendor can honestly promise encrypted storage is immune to extraction under unlimited time and tooling. That is active key-extraction research, and treating it as solved is how security claims stop being credible. What at-rest encryption is built to guarantee is narrower: the ordinary loss scenario, a stolen box, a device missing in transit, an insider who walks off with hardware, degrades into "we lost a sealed unit," not "we lost the model weights and the data behind them."

Data in transit: the network you still have, even air-gapped

Here is the part that surprises people who equate "air-gapped" with "no networking to think about": an E31 appliance still has a network, it is simply not the internet. Inside the facility, the device talks to workstations submitting requests, to file shares or repositories it may be configured to read from, to local storage, and in a Czar deployment, potentially to other nodes participating in a training job. Every one of those paths is a wire, in the security sense. An adversary who has already gained a foothold inside the facility's network, a compromised workstation, a rogue device on the same VLAN, does not need the appliance reachable from the internet to intercept or tamper with what crosses that internal wire.

This is why "air-gapped" is a claim about the external boundary, not a substitute for transport security on the internal one. Traffic between an E31 device and the systems it talks to on-premises is encrypted and authenticated using standard transport security practice: mutual authentication so each side of a connection can verify the other rather than trusting network position alone, and encryption so an observer sees ciphertext rather than the request or response. This matters as much for routine traffic, an engineer's query to Forge, a batch of documents ingested for retrieval, as for anything obviously sensitive, since that traffic is frequently exactly the material the appliance exists to protect.

The governed connectivity Substrate provides, the plumbing underneath Forge, Czar, and every Chassis build, extends this discipline to any integrations a deployment allows: a connection to an internal repository, a knowledge base, a local model registry. Each is scoped, authenticated, and encrypted individually rather than treated as implicitly trusted because it stays inside the building. Being inside a facility's four walls is a real control, but it is the customer's control, tied to that facility's own segmentation policy, not a substitute for the appliance authenticating and encrypting its own traffic.

Where the two stories connect

At rest and in transit are distinct threat models, but not independent ones, and the seam between them is where careless implementations fail. A key that protects data beautifully while it sits on disk is only as good as the path it travels when it moves: into memory at boot, across an internal link during a distributed training job, into a backup. Data meticulously encrypted in transit and then written to disk in the clear at the other end has not actually been protected. It has just had its exposure relocated. A credible design treats the lifecycle as one continuous chain: keys are generated and held in protected hardware, data is encrypted before it leaves that protection, it stays encrypted across any network hop, and it is only ever decrypted in the memory of a process validated as part of the boot chain, not written back to disk in a more convenient, less protected form along the way.

This is also where tamper detection and transport security meet, on Czar in particular. A sandboxed training job spanning more than one node has to move batches, gradients, and checkpoints between them, and that movement is the in-transit case, happening entirely within a facility's own network. The same authentication and encryption discipline applies whether the two endpoints are a workstation and an appliance or two nodes in the same cluster, because the adversary who matters here is defined by network position, not geography. "Inside the building" is not synonymous with "trusted."

What this looks like across the lineup

Forge holds source code, retrieval indices, and cached context from an organization's own codebase, exactly the material an organization runs a sealed coding assistant to avoid sending to a cloud model in the first place. At-rest protection covers that material on disk; in-transit protection covers every query an engineer sends and every response Forge returns, since that traffic is the code itself, not incidental metadata.

Czar's threat model adds distributed training workloads, so in-transit protection has to cover node-to-node traffic within a sandbox, not just client-to-appliance traffic, while at-rest protection covers training corpora and resulting model weights between jobs.

Chassis builds inherit the same Substrate-level cryptographic primitives, but the specific transport topology (how many nodes, what internal systems a unit integrates with) is scoped to the deal each build ships for, since every Chassis unit lands in a different ISV's environment with a different internal network to authenticate against.

The audit question this answers

For a reviewer evaluating a sealed appliance, the useful question is never "is the data encrypted." It is two questions, asked separately: what protects this data when the device is powered off and sitting on a shelf, and what protects it while it is moving between the appliance and everything it talks to, including traffic that never leaves the building. An architecture with a confident answer to only one of those has a gap dressed up as a feature. Building both into the platform layer, consistently, documented, the same way on every unit, is what makes the answer to both a specific, checkable claim about the hardware and its boot chain, rather than a general assurance taken on faith.