Two planes — both real, neither confuses the other:
Industrial host fleet stays host-only. Guests never get Config / Antigravity host panes unless paid workspace product surface is gated in.
Claim we make: Server stores ciphertext only. Device-chain unlock means a DB dump does not yield file plaintext.
Claim we do not make: “Unhackable server.” No system is. We minimize blast radius.
1. First device (login): client creates a local device id; server stores only deviceHash + genesis chain token.
2. Second device (e.g. Quest): requests link → pending.
3. First device approves (in-app): extends chain HMAC link; optionally uploads wrapped master key ciphertext for the new device.
4. Only devices on the chain may request wrappedDek for containers.
5. Decryption happens on the device (or user session with device secret) — not by server “reading files for you.”
1. Client holds masterKey (device secret ± passphrase).
2. Each container has a random DEK.
3. Files encrypted client-side (AES-256-GCM); server stores blobs + wrappedDek.
4. Coding agent on server sees ciphertext metadata only; decrypt for tools runs in a device-bound session if we ever stream keys ephemerally (prefer local agent).
social_ai_freedom | yes | yes | yes | yes |encrypted_vault | no | no | light yes | yes |workspace_coding_agent | no | no | no | yes |antigravity_workspace | no | no | no | yes |full_fleet | never free | no | no | team+ |shared/device-chain.mjs — register / pending / approve / chain integrityshared/workspace-vault.mjs — containers, ciphertext blobs, dual-world policyshared/plan-tiers.mjs — privileges abovePOST /api/devices/register — primary devicePOST /api/devices/request — second devicePOST /api/devices/approve — primary approvesGET /api/devices — list (no secrets)POST /api/vault/containers — create (body: wrappedDek)GET /api/vault/containersPOST /api/vault/files — upload ciphertextGET /api/vault/files/:id — download ciphertextAll vault routes: plan gate + deviceHash must be linked.