Privacy

Effective 2026-09-27 · operated by the Witbitz project.

Witbitz is a trusted runtime for collaborative apps where people and AI agents work together. Its first app is Spaces — a shared room where you and others work with an AI. This policy explains what data the Witbitz service handles. Unusually, most of what you'd expect a service to see, we can't: your content is end-to-end encrypted and sealed to a key we never hold — so the platform stores only data it cannot read. Where the design falls short of that, we say so plainly below.

The short version

• Content-blind by design. Your messages, documents, images, and a Space's configuration are encrypted with a key that lives in your link and on your device — never sent to us on the read path. We store only ciphertext, sealed to a key we never hold. Neither Witbitz nor the app's own owner can read your content.
• An account is optional. A Space is reached by link, and a link is enough. You can also create an account — an email sign-in, and optionally a public @username — to keep your Spaces across devices. What that adds is described below.
• The one exception, stated honestly: to run an AI agent's turn, a certified, reproducible, egress-locked function decrypts your message in memory for that turn only — to run the model and enforce the room's admission rules — then discards it. It is not stored or logged in plaintext. A confidential Space removes even that: the turn runs inside a hardware-attested enclave your own device checks before it will send anything.
• Verifiable. You can read the running code's true data footprint at /docs/verify.md and its signed build certificate at /cert.json, and reproduce the build yourself.
• No advertising, no tracking cookies, no selling of data.

What is encrypted, and where the key lives

Everything that carries meaning in a Space is sealed under a room key: the conversation ledger, shared documents and widgets, images, and the Space's configuration (its agent persona, tools, and its admission rules and allow-list). That key is generated on your device and lives in your link — it is never transmitted to us during ordinary reading (the client opens the sealed data itself). We store only a one-way commitment to the key (a hash), which lets the service accept the right key without ever holding it.

If you turn on backup, your room keys are sealed on your device under a key we never hold and stored as an opaque blob, so they can be restored to a new device. Opening it again needs something only you have — your recovery code, a passkey, or a device already linked. We cannot read the blob and we cannot open it for you: if every one of those is lost, so are the Spaces it held. That is the trade the design makes on purpose.

Accounts, sign-in, and finding people

An account is an email address you verify, either with a code we email you or through Google sign-in. It lets your Spaces follow you to another device, lets people invite you, and lets you hold connections.

• We do not keep your address in the directory. When you sign in, the service verifies your token and derives a one-way handle from the address using a key we hold. The handle is what is stored and what invitations are addressed to; the address itself is not written into the directory. Your device can derive the same handle for someone you want to invite without sending us their address (the server answers a blinded request and never learns what was asked).
• A username is optional and public. If you claim an @name, that name and the fact that it exists are public — that is what makes it usable for invitations. Your display name is published only if you choose to publish it.
• Being found by email is opt-out. If you turn it off, a stranger asking whether your address is on Witbitz gets the same answer as for an address that is not.
• Devices. Linking a second device moves keys between your own devices; we carry sealed material we cannot open.

Running a turn — the in-use exception, and the tier that removes it

An AI agent genuinely needs to read a turn's plaintext to think, and the platform needs to check who is allowed to participate. So when a turn runs in an ordinary Space, a certified-ephemeral function receives your (still end-to-end-encrypted) message, decrypts it in memory, runs the agent and enforces admission, and discards the plaintext when the turn ends. That plaintext is not persisted and not logged. The function is a reproducible, egress-locked build whose declared data footprint you can verify (above). This is the one point where your content exists in the clear on a server we operate.

A confidential Space closes it. The turn runs inside a hardware-attested enclave (AWS Nitro), and your device verifies the enclave's measurement against a published build before it will seal anything to it — so the operator of the machine, and we, cannot read the turn. The Space says which it is, and the check is fail-closed: if the attestation does not match, your client refuses to send. See /docs/the-attested-tier.md. Running Witbitz on-premises puts all of this inside your own boundary.

The model (a sub-processor)

To generate a reply, the agent sends the turn's content to a large-language-model provider. Which model a Space uses is part of its configuration, and the choice is yours per Space — the catalogue includes models from OpenAI, Anthropic, Google, Mistral, DeepSeek, xAI, Moonshot, Z.ai, Alibaba and Meta, hosted by those providers or by an inference host. Each processes the content under its own policy.

A confidential Space uses a confidential inference provider instead, where the model runs in an attested enclave and the turn is refused unless the upstream proves it. On-premises or air-gapped, the model is one of your choosing, including a self-hosted one, and nothing leaves your infrastructure.

Connections — keys you attach

You can give a Space the ability to call an outside service on your behalf — a calendar, a code host, an API you hold a key for. The key itself is sealed to a hardware-attested enclave (the Credential Sentinel) that your device verifies before sending it. We never hold it in a form we can read, the Space does not hold it, and the model never sees it. What comes back from the call is a result, which the agent reads like any other content, and the reply is stripped of credentials before it is returned. A connection belongs to your account, works only in the Spaces you add it to, and revoking it stops every Space at once.

Where an app's builder has registered their own OAuth application, you consent to them and the resulting token is held the same way. In that case the builder is the party you have granted access to, under their own policy.

Voice capture (optional)

If you set up voice capture, a shortcut on your phone sends dictated text to a dedicated endpoint whose TLS terminates inside an attested enclave. The words are sealed there to the Space you named and collected by your own device, which posts them as you. We do not hold the text in a form we can read, and the feature does nothing until you set it up.

Identity and admission

Many Spaces are open by link. Others are gated: the owner requires a sign-in, or limits who may post to named addresses, usernames or a domain. When a gated room runs a turn or read, we verify your sign-in token against the room's sealed allow-list and then discard the token. We persist the display name you chose and a "verified" marker; the allow-list itself is sealed, so the platform cannot read who is permitted. In a verified room, what is attested beside a message is your handle or username, not your address.

Metadata we do handle

• Opaque room identifiers, timestamps, and version tags (computed over ciphertext) so the service can route and sync.
• IP address and request metadata, transiently, for delivering the service and for security and abuse prevention. Standard server logs (timings, counts, errors — never content) auto-expire within days.
• Cleartext markers that reveal only that a room is identity-gated, owner-governed, or confidential — never who is allowed or what the policy is.
• Push subscriptions, if you enable notifications. The notice we can send is content-free; any preview travels sealed under a notification-only key and is opened on your device, not by us.

Search, maps, places and flights

When an agent looks something up, the request leaves our side and reaches a provider:

• Web search runs inside an enclave operated by Tinfoil, which opens the connection onward to Exa under a zero-data-retention agreement — so the query is not plaintext on a machine we operate.
• Places and maps are proxied to Google Places and map/routing providers, so those providers see the Witbitz server rather than your IP address. Some place and shop photos come from Wikimedia.
• Flight lookups go to Duffel.

Each provider handles what it receives under its own policy. In an air-gapped deployment these external calls are turned off.

Apps built on Witbitz

Other people can build apps on this runtime. When you use one, the app's builder decides what its rooms contain and which outside services it declares; the encryption model is the same, so the builder cannot read your content either. Your relationship for what that app does with the results is with its builder.

Payments

Paid features are handled by a third-party payment processor. Witbitz does not receive or store your full card details; the processor handles payment data under its own policy. We keep only the non-secret records needed to grant and meter what you purchased.

Hosting and infrastructure

The hosted service runs on cloud infrastructure (a CDN for static assets; a short-lived cloud function for the certified render; attested enclaves for the confidential tier and for held credentials; managed storage that holds only ciphertext and non-secret records). These providers may produce standard operational logs.

Retention and deletion

Your content persists as ciphertext until it is deleted. Because you hold the key, you control access; deleting a Space removes its stored ciphertext. Sign-in tokens are never stored. Operational logs auto-expire within days. A backup blob is kept until you delete it, and a connection's key is destroyed when you revoke it. Note that, by design, we often cannot identify or read the data associated with a given person — we hold ciphertext plus a key we cannot use — which both protects you and limits what we can retrieve on request.

Your choices and rights

Depending on where you live, you may have rights to access, correct, delete, or port your personal data, or to object to certain processing. Because of the encryption model, the most effective controls are in your hands: keep or delete your link and key, delete a Space to remove its ciphertext, revoke a connection, turn off being found by email, or release a username. For requests we can act on, contact us below. Organizations that need data to stay inside their own boundary can run Witbitz on-premises.

Children

Witbitz is not directed to children and should not be used by anyone under the age required by their local law to consent to this kind of processing.

Changes

We may update this page; material changes will be reflected by a new effective date above.

Contact

Questions or requests? Email privacy@witbitz.chat.