# Trust model

Witbitz has two separate trust claims. Keep them separate:

1. **Humans keep authority.** An AI agent can propose work, but the runtime requires a human approval before any
   high-stakes action executes.
2. **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](./status.md) 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](./verify.md)

## 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](./the-double-blind.md)

## 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:

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

Read: [Delegated authority](./delegated-authority.md)

## 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](./identity-and-admission.md)

## 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](./verify.md)
- Understand storage privacy: [Privacy model](./the-double-blind.md)
- Understand admission: [Identity and admission](./identity-and-admission.md)
- Understand lifecycle: [Member lifecycle](./member-lifecycle.md)
- Understand recovery: [Recovery](./recovery.md)
- Review action safety: [Delegated authority](./delegated-authority.md)