Sandbox VM — overview

The Kenaz Sandbox VM is the user-facing surface of Kenaz: a small, ephemeral virtual machine built from a NixOS image (SigilOS) that runs a single desktop app (Kenaz workbench) inside a kiosk-style window. The host machine launches it on demand via a thin launcher binary, the user does their work inside, and the VM is torn down when they're done.

This split — ephemeral VM + sandboxed desktop app + thin host launcher — is what makes Kenaz secure-by-default for AI work. The host has no direct access to the user's prompts, tool outputs, or scratch files; the VM has no persistent disk by default; and everything visible inside the VM is mediated by a single auditable surface.

Three pieces, one product

                   Host (macOS / Linux / Windows)
       +-----------------------------------------------+
       |                                               |
       |   Kenaz Harness (host app, separate docs)     |
       |   - session lifecycle                         |
       |   - inference brokering (Bedrock / OpenAI /   |
       |     Anthropic / OpenRouter / BYO)             |
       |   - policy + audit log                        |
       |                                               |
       |             |  spawns / supervises            |
       |             v                                 |
       |   +-------------------------------------+     |
       |   |  Launcher  (kenaz-launch / wrapper) |     |
       |   |  - hypervisor bring-up              |     |
       |   |  - vsock plumbing                   |     |
       |   |  - per-session VM fingerprint       |     |
       |   +-------------------------------------+     |
       |             |                                 |
       |             v                                 |
       |   +-------------------------------------+     |
       |   |  Sandbox VM (SigilOS + workbench)   |     |
       |   |  - sway kiosk + greetd autologin    |     |
       |   |  - workbench-app systemd service    |     |
       |   |  - vsock socket -> harness          |     |
       |   |  - no persistent disk by default    |     |
       |   +-------------------------------------+     |
       |                                               |
       +-----------------------------------------------+

Layer	What it is	Repo / source
SigilOS	NixOS flake that builds the base bootable image. Configures the kernel, hardening, init, the kiosk window manager (sway), and the workbench-app systemd unit.	sigil-tech/sigil-os
Kenaz workbench	The Wails (Go + Preact) desktop app that runs inside the VM. The single visible UI surface for the user. Talks to the harness over vsock.	sigil-tech/kenaz-sandbox (under workbench-app/)
Launchers	Per-host binaries (and make targets in dev) that bring up the VM + wire vsock + hand control to the harness.	sigil-tech/kenaz-sandbox (under scripts/ and nix/)

Each piece is documented in its own page:

• SigilOS image — how the base image is composed, what's baked in, how to add or remove modules.
• Workbench app — the in-VM Wails app, its responsibilities, and how it talks to the harness.
• Launchers — how a session starts on the host, including the vsock protocol and the dev-loop make image-aarch64 / make download-image flow.

Why a VM (and not a container)?

Containers share the host kernel. For a product whose security pitch is "your AI tools cannot exfiltrate or persist beyond a single session," a shared kernel is a meaningful attack surface — one container escape or shared-namespace bug and the bargain is broken. A small ephemeral VM gives us a well-understood isolation boundary (CPU + memory virtualization, no shared kernel) at the cost of a few hundred milliseconds of boot time and a few hundred megabytes of RAM. Worth it.

Threat model in one paragraph

The VM is treated as untrusted from the host's perspective. The launcher provides only the channels the workbench needs (display, vsock to the harness, optional clipboard). The workbench is treated as untrusted from the VM's perspective in the sense that sway's kiosk config restricts what windows it can spawn, what input devices it can grab, and what URLs it can be redirected to. The VM has no persistent disk by default; any user data that needs to survive a session goes through the harness's audit-logged storage layer on the host. See SECURITY.md in the kenaz-sandbox repo for the longer write-up.