Governance & Controls

A guide for governance and controls available in Kaba.

The tables below describe what every install provides by itself, which is all there is in Kaba Personal. Kaba Enterprise’s fleet management takes the same controls and centralizes them: sign-in, policy, enrolment, updates, retention and audit are set by the organisation instead of by each person. See what fleet control changes.

Kaba is software you run on systems you own. It does not make an organisation compliant by itself. What it provides are controls: concrete, inspectable behaviours you can point to when your own program asks where data lives, who can act on it, and how you would prove it.

Note

This page describes product behaviour. It is not legal advice. Map these controls to your obligations with your own compliance and legal teams.

Policy

Everything a model does in Kaba passes through a policy: where inference runs, which model and adapter answer, which tools may be used, whether commands may execute, and whether the sandbox gets network.

Control	How Kaba provides it
Least privilege for automation	Policies with deny-wins tool ceilings, a command-execution mode and a sandbox networking mode. See machine learning.
Non-overridable policy	Prevent overriding policy settings forces projects to run a policy exactly as configured, enforced when each request is made.
Inference location is explicit	A policy names the device that runs inference: this device or a specific peer.
Per-node opt-outs	accept_remote_inference, accept_remote_training, enable_peer_exec in config.toml.
Portable, reviewable policy	A policy exports to a .kabap bundle whose contents are plain JSON. See file formats.
Authentication	Per-account password; session tokens with a configurable lifetime (jwt_exp_time); API keys stored hashed.
Device enrolment and removal	Single-use, time-limited join tickets; eviction with tombstones. See cluster & mesh.
Session lock	Lock screen on demand. The vault can be locked separately, which drops its key from memory.

Central enrolment by group, pushed policies and remote revocation are part of Kaba Enterprise.

Audit

Control	How Kaba provides it
Record of automated actions	Each tool-loop step is recorded as a trajectory: the tool, the phase, and the outcome.
Provenance for models	Adapters carry a manifest; imported adapters keep the original download alongside.
What automation is doing right now	A frame is marked while Kaba is driving a pane in it, and each step is shown in the project thread.
Network transparency	All traffic goes through the local proxy, so what goes in and out of Kaba is available for you to view.
Inspectable source	The source is available to read and build. See the licence note in the FAQ.

Logs

Log	Where
Client log	Settings → System Logs, live, with filters and pause. On disk: kaba.log in the user data directory.
Engine log	kabactl-server.log in the storage directory. Rotates at 10 MB, keeps 5 files.
Service output	kabactl-service.log, or the journal under systemd.
Crash record	crash-log.jsonl, created on the first process crash.
Diagnostics bundle	kabactl --trace writes a bundle under perf/. See services.

Terminal sessions are a special case: when recorded as memory, typed input is never stored and printed secrets are redacted before anything is written. See terminal memory.

Retention

Need	Where
See what is stored	Hippocampus: Memories, History, Downloads, Frames.
Delete a memory, a visit, or all of them	Hippocampus.
Erase a specific string everywhere	Hippocampus → remove text from memory.
Exclude sites from capture and training	Memory Ignore List.
Stop collection	Enable Memory, Remember terminal sessions, Remember file activity, Enable Learning Data in Settings.
Delete learning data	Settings → Delete all learning data.
Forget a site	site panel → Forget; Settings → Sites.
Limit version history	memory_version_limit in config.toml.
Cookie lifetime	Capped at 180 days by the privacy layer.

One limit to state plainly: an adapter trained on a memory still reflects it after the memory is deleted. To honour an erasure request fully, retrain adapters made since that data was captured.

Metrics, Monitoring, and Reporting

Need	Where
Live system load	The performance readout in the Kaba bar: network up and down, CPU and memory.
Per-process memory and CPU	Settings → Information → Diagnostics and Processes. Copy JSON exports it.
Node health	kabactl doctor (add --json for machines).
Cluster state	Settings → Devices, or kabactl cluster list.
Training progress on peers	Settings → Devices.
Sandbox activity	Settings → Containers: running containers, image, status and step.
Threat database status	kabactl security status, or Settings → Security & Privacy → Safe Browsing.
Exposed service traffic	Hippocampus → Services.

Per-team metering, budgets and fleet-wide reporting are part of Kaba Enterprise.

Data location

Control	How Kaba provides it
Data stays on systems you own	Memories, prompts, model outputs and adapters are stored locally and move only between devices in your own cluster.
No vendor copy	There is no Kaba account server and no analytics. See when data leaves your device.
Self-hosted networking	Set your own relay and disable public discovery under cluster_options.
Air-gapped operation	A node works with no outside network once models are present. See kaba-enclave.

Data protection

Control	How Kaba provides it
Encryption at rest	Memories, learning data, saved logins and passkeys, under a key derived from the account password. See security.
Encryption in transit	HTTPS for the local API; end-to-end encrypted connections between peers.
Isolation	Sandboxed renderers for web content; containers for model-driven execution.

Regulation notes

GDPR and CCPA. The controls above support data minimisation (collection toggles, ignore list), storage limitation (deletion, version limits), integrity and confidentiality (encryption, isolation), and access and erasure requests (Hippocampus). In the self-hosted product, data does not leave systems you control and Kaba Labs does not receive it.

HIPAA. Kaba can be deployed so that protected information never leaves devices you manage. Whether a given deployment meets the Security Rule depends on your device management, backups, access policies and the rest of your environment.

SOC 2. Policies, enrolment, eviction, encryption and trajectory records are evidence you can cite under your own access-control, change-management and monitoring criteria.

[todo: confirm with legal which certifications or attestations, if any, Kaba Labs itself holds, and whether a DPA or BAA is offered for Kaba Enterprise.]