Data boundaries

Data boundaries describe which system owns which data. In KB-1, the most important boundary is the split between Cloud login and vault home.

The short version

Mode	Durable notes and assets	Cloud stores	Cloud routes content operations?
Local-only daemon	Your machine	Nothing required	No
Self-hosted with Cloud login	Your machine	Account, org, membership, relay/session metadata, signed-entry metadata	Yes, through your daemon
Hosted	KB-1 operated hosted environment	Account, org, membership, lifecycle, session, routing, hosted durability metadata, and bounded hosted hot-cache state	Yes, through KB-1 operated daemon runtime

Local-only

The daemon serves the web UI, API, and MCP endpoint from the same local process. Files live under KB1_HOME/vaults/<vault-id>/. Cloud is not required for local use. The daemon itself does not have Cloud users, organizations, team presence, or per-user org permissions. Any client that can reach the local UI, API, or MCP endpoint is inside the local trust boundary.

Self-hosted full experience adds Cloud identity, org membership, signed entry, presence, and relay routing. The daemon still owns durable vault content and runs on a machine you control.

This is the path for remote people and agents. Cloud routes browser and agent operations to the daemon while your machine remains the vault home.

Cloud necessarily sees enough metadata to authenticate, authorize, route, and operate the relay. It should not be described as the durable vault store for this mode.

Hosted

Hosted full experience means KB-1 operates the vault engine and lifecycle. This is still the same Cloud login and org surface, but the vault home is KB-1 operated infrastructure instead of your machine.

Hosted may keep a bounded, per-org hot cache of daemon-produced bytes or Yjs document state so repeated reads and live edits can stay responsive while the hosted daemon wakes. That cache is part of the Hosted service, not a generic Cloud content store: it is scoped to the hosted org, not used for search, indexing, summarization, or cross-tenant data sharing, and daemon-produced entries are reconstructible from the daemon. Pending hot-document edits may be stored there temporarily until the daemon replays or acknowledges them.

Agents

Local MCP agents use the daemon directly. Cloud MCP agents, when enabled, use Cloud sign-in and an approved integration record before Cloud routes the tool call to an org daemon. Any agent that can reach the local MCP endpoint can use the tool surface for the daemon’s vaults, so keep local daemon access limited to machines and users you trust.

Why this matters

“Cloud” does not always mean KB-1 stores the vault, and “self-hosted” does not always mean no Cloud account. Ask two questions:

Where do people and agents log in?
Where does the vault engine live?

Those answers define the data boundary.