Security

Verifiable execution by design.

Security is not a layer added on top. It is built into every part of the system\u2014from device enrollment to model updates to fleet synchronization. Every operation is cryptographically verifiable.

Air-gapped operation

The system is designed to operate independently of network access. Deploy in secure facilities, remote environments, or fully offline locations.

Details
  • All inference and execution happens locally on-device with zero cloud dependencies.
  • Models, configuration, and execution state are stored entirely on the device.
  • No telemetry, no phone-home, no external service calls. The runtime is fully self-contained.
  • Ideal for classified environments, remote field operations, and locations without reliable connectivity.

Zero-trust device enrollment

Devices authenticate cryptographically before joining a fleet. Each device is verified individually. Untrusted or compromised hardware is rejected automatically.

Details
  • Each device generates a unique cryptographic identity during enrollment.
  • Fleet membership requires mutual authentication—the device verifies the fleet, and the fleet verifies the device.
  • Revocation is immediate. Compromised devices are excluded from fleet operations without affecting other members.
  • No shared secrets, no static API keys, no implicit trust.

Device-bound encryption

Models and execution data are encrypted and bound to specific hardware. If a device is lost or removed, its data remains inaccessible.

Details
  • Encryption keys are derived from hardware-specific identifiers. Data cannot be decrypted on a different device.
  • Model weights, execution logs, and configuration are all encrypted at rest.
  • If a device is physically stolen, the data on it is cryptographically useless without the original hardware context.
  • Key rotation happens automatically without service interruption.

Verified updates

Model updates and configuration changes require cryptographic signatures. Unsigned or modified artifacts are rejected before deployment.

Details
  • Every update—model weights, configuration, firmware—must be signed by an authorized key.
  • The runtime verifies signatures before applying any change. Tampered artifacts are rejected outright.
  • Signing keys are managed separately from deployment infrastructure for defense in depth.
  • Update history is logged and auditable. You can verify exactly what was deployed and when.

Verified fleet synchronization

When connectivity is available, fleet state and configuration changes are verified before being applied. Only signed and authorized updates propagate.

Details
  • Fleet sync uses the same cryptographic verification as local updates. No separate trust model.
  • Configuration changes propagate only after verification by each receiving device.
  • Partial fleet updates are supported—devices that can't verify an update simply don't apply it.
  • Sync state is logged on both the device and fleet dashboard for full auditability.

Complete control from edge to cloud.