Security

Kaba’s security model follows from where it runs: on your hardware, under your account, with no service in the middle. This page covers encryption, isolation, the sandbox for model-driven commands, and how devices trust each other.

Personal and Enterprise

This page describes Kaba Personal: your account and keys are local and nobody else holds them. Under Kaba Enterprise with fleet management, authentication is centralized, policy is enforced by the organisation, and keys and data can be revoked remotely. Encryption, isolation and the sandbox work the same way; who holds authority does not. See what fleet control changes.

Encryption at rest

Each account has a random 256-bit data key. It is never stored in the clear.

1. Your password is run through Argon2id (64 MiB memory, 3 passes) with a per-account salt to derive a key-encryption key.
2. That key wraps the data key with XChaCha20-Poly1305. Only the wrapped form is stored.
3. Separate sub-keys for each purpose are derived from the data key with BLAKE3.

Signing in unwraps the data key and holds it in memory. Choosing Lock now under Settings → Passwords, restarting Kaba, or a long idle period drops it; signing in again restores it.

Protected by the data key	Notes
Memories	Each account has its own encrypted vector store, encrypted in blocks so searches can read a range without decrypting the whole file.
Learning data	Stored in the same encrypted store.
Saved logins	In the local vault.
Passkeys	One vault entry per passkey; the private key is used only inside Kaba and is never shown or handed to a page.

Changing your password re-wraps the same data key, so nothing needs to be re-encrypted. In Kaba Personal, forgetting your password means losing this data: there is no recovery path, because nobody else holds a key.

Your account password itself is stored only as an Argon2 hash.

Note

The account database (kaba.db) holds settings, history, frames and policies and is not encrypted by Kaba. Use full-disk encryption on the device to protect it.

Passwords and passkeys

Settings → Passwords chooses where logins are kept:

Backend	Storage
Kaba (default)	Encrypted in the local vault, unlocked when you sign in.
pass	Your existing GPG-encrypted password store.
1Password	Through the 1Password command-line tool.

Kaba offers to save logins as you sign in, autofills matching sites, and can hold TOTP secrets and show the current code.

For passkeys, Kaba acts as the passkey provider by default: its own dialog, keys in the vault. Hardware security keys are handed to the browser engine. You can switch to Browser only or Off.

Locking

Lock Kaba (Ctrl/Cmd+Shift+L) covers every window with a lock screen until you enter your password. While locked, menu actions that would open or change panes do nothing.

Web content isolation

• Every page renders in a sandboxed process with context isolation. Pages cannot reach Node.js or Electron.
• Sites are isolated from each other by origin.
• Web pages get no Kaba API. The kaba.* SDK exists only on built-in kaba:// pages, and only in the top frame. See SDK security.
• Permissions such as camera, microphone, location, notifications, USB, serial, HID and Bluetooth are asked per site, and decisions can be reviewed and reset from the site panel or Settings → Sites.
• Downloads are checked against the local threat database by file name and hash.
• Safe Browsing screens navigation against a local database of known-bad domains, URLs, file names and hashes. A fast in-memory filter answers most checks; hits are confirmed against a local index. No URL is sent to a lookup service.

The tool loop

When a model acts for you, it does so through a tool loop with hard limits.

• A fixed catalog. Tools are first-party code. A policy or overlay can remove, restrict, re-describe or order tools; nothing in data can add one.
• Deny wins. A policy’s denied tools and step ceiling are applied last. No project or overlay can re-enable what the policy removed. Disabled tools are removed from the model’s output grammar, so they cannot even be expressed.
• Budgets. Every run has a step cap, stops after ten asks without progress, and ends at 30 minutes.
• Gates. Irreversible actions, such as completing a purchase, are held behind explicit gates.
• Visibility. While Kaba is driving a pane, the frame shows it. Each step is recorded so a run can be reviewed.

Command execution

A policy sets how proposed shell commands are handled:

Setting	Behaviour
Ask (default)	The assistant proposes; you click Run.
Auto-run	Commands on the read-only allowlist run immediately. Everything else still needs approval.
Off	Words only. No runnable commands are proposed.

Commands that run on the host must be a single command on one line. Pipes, redirection, chaining and command substitution are refused, and destructive commands such as rm, dd and mkfs are on a deny list. Adjust the lists with exec_options.

The sandbox

File, code and build work runs in a container, not on your machine.

	Default
Runtime (Linux)	The first found of gVisor runsc, youki, crun, runc. Force one with KABA_SANDBOX_RUNTIME.
Runtime (macOS, Windows)	Docker or a compatible daemon.
Root filesystem	Read-only. The project workspace is mounted at /workspace.
Network	Off.
Command timeout	60 seconds.

A policy controls sandbox networking: Off (never, even if the model asks), Model may request (a tool call may ask for network for an install), or Always on. Off is enforced when the run starts, not just in the interface.

Manage images and running containers under Settings → Containers.

Devices and the mesh

• Each node has its own key pair in node.key. Its public key is its identity.
• A device joins with a single-use, time-limited ticket created on a device already in the cluster.
• Every connection between peers is encrypted end to end. A relay forwards packets it cannot read.
• Requests are signed and timestamped; peers reject anything more than 60 seconds old.
• Each peer enforces its own settings for remote inference, training and command execution.
• Evicting a device removes it everywhere and leaves a tombstone so it cannot rejoin unnoticed.

The local API

The engine’s API is HTTPS only, using a certificate generated on the machine. Requests need a session token or an API key; API keys are stored hashed. The proxy accepts unauthenticated connections only from the same machine.

Caution

In kabactl 0.87 the API and proxy listen on all network interfaces and the address cannot be changed. On a machine reachable from an untrusted network, block ports 28832 and 28833 with a firewall. See services.

Hardening checklist

• Use full-disk encryption on every device.
• Firewall ports 28832 and 28833 on machines with a public address.
• Run headless nodes with the system unit or the container image, both of which run as an unprivileged user.
• Keep Command execution on Ask and Sandbox networking Off unless a task needs otherwise.
• Install gVisor on Linux nodes that run the sandbox.
• Evict devices you no longer use.

Reporting a vulnerability

[todo: confirm the security contact address and disclosure process to publish here.]