Trust model

Witbitz has two separate trust claims. Keep them separate:

Humans keep authority. An AI agent can propose work, but the runtime requires a human approval before any high-stakes action executes.
Privacy is verifiable. A Space is sealed at rest, the app has no backend of its own, the browser egress footprint is locked, and the deployed render can be checked against published source.

The docs are intentionally explicit about what is live today and what is not. Start with Status if you need the shipped/preview/designed map.

What is protected today

Claim	Production status
A gated Space refuses reads and writes without an allow-listed identity	Live and checkable
The stored Space ledger is ciphertext sealed to the room key	Live and checkable
There is no operator recovery recipient in the production envelope	Live and checkable
The app's browser egress is locked to a published allowlist	Live and checkable
The deployed render publishes a signed build certificate	Live and checkable
The render source can be rebuilt to the deployed hash	Live and checkable
High-stakes agent actions require approval	Live and tested

Run the checks: Verify it yourself

What is not hidden

Witbitz does not hide everything, and the docs should never imply that it does.

Metadata remains visible. The platform sees that a room exists, when it changes, and roughly how large writes are.
The model provider sees turn content. A remote model must receive the text it is asked to reason over.
The render sees plaintext in use today. Production Spaces open plaintext inside the server-side render during a member's active read or turn.
Endpoints still matter. A compromised member device can read what that member can read.
Availability is not privacy. The operator can refuse service. The content-blind claim is about reading, not guaranteeing access forever.

The one plaintext door

The current production architecture is content-blind at rest. Plaintext opens in one code path: the render. That path runs when a member posts a turn and, for changed reads on the legacy render path, when entries are returned to a client.

The reason this is still a useful privacy boundary is that the render is small, published, reproducible, egress-locked, and moving toward attestation. The reason the docs keep calling out the limit is that an ordinary production Space is not yet "unobservable in use."

Read: The double blind

Human authority

Tools are capabilities. Some are harmless, like rendering a chart. Others can spend money, send information, modify an external system, or cross an organizational boundary. The runtime treats high-stakes tool calls as proposals:

The agent proposes.
A human approves or denies.
Only an approved proposal executes.
The audit trail is sealed with the room.

Read: Delegated authority

Identity and admission

A Space starts with key possession: holding the room key proves membership. Gated Spaces add signed identity on top: Google/OIDC identity, signed invites, agent keys, owner policies, or other credential families depending on the room.

Read: Identity and admission

Stronger tiers

Tier	Status	What it changes
Owner-governed rooms	Built, opt-in	The app owner can mandate admission tiers and capabilities.
Attested server tier	Built and verifiable, not production traffic	The render runs inside measured Nitro hardware.
Sealed Spaces	Designed	The platform never receives `mk`; it can append but not read.
Attested client	Server seam built; native clients not shipped	A room can require the audited client code, not just an ordinary browser.

Where to go next

Check claims: Verify it yourself
Understand storage privacy: Privacy model
Understand admission: Identity and admission
Understand lifecycle: Member lifecycle
Understand recovery: Recovery
Review action safety: Delegated authority

Machine-readable source: trust-model.md · every doc in one fetch: llms-full.txt (HTML) · ← api-reference · verify →