Privacy

Effective 2026-10-16 · 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. Restoring it needs your recovery code and a second check — a code sent to your account's email, or your passkey — or a device you have 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.

Your list of Spaces and your account's settings are sealed the same way, on your device, before they are stored. If you turn on the optional device lock, what the app keeps on your phone or computer is sealed at rest too, opened only by your passkey or biometrics.

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. Requests are routed through TrustedRouter, an inference router. Each processes the content under its own policy.

A confidential Space uses confidential inference instead: open-weight models running in confidential computing (attested hardware), reached through a gateway that keeps no log of prompts or replies, 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.

Your usage

Each account has its own capped keys with the AI providers, so the provider meters the use that is yours and we can show it to you exactly. That means the provider sees which key a request came from. After a turn, its cost and token counts are sealed to a key only your devices hold and filed with the room, so your own usage page can read them and we cannot. If a room's admin funds the room, the room's grant pays for members' turns up to a limit, and the admin sees what was spent, not what was said.

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 and outside agents (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.

The same way, you can let an outside AI agent send messages to one of your private assistants. What it sends is sealed inside the enclave to that assistant and collected by your device; the agent sees only the answers you approve. You can close that door at any time.

Speech (optional)

Press-to-talk can transcribe in the cloud: your microphone audio streams straight from your device to Tinfoil's speech model, which runs inside an attested enclave, using a short-lived key minted for your account. "Play aloud" sends the message's text to Tinfoil the same way to be read out. We do not receive the audio or the text. Where you choose on-device transcription, nothing leaves your device.

The coding agent and cloud computers (optional)

If you pair a computer for coding, the agent runs on that computer; your devices reach it through an encrypted relay that carries only sealed traffic, and the computer uses capped model keys issued to your account. A cloud computer runs inside an attested enclave: its disk is encrypted with a key the host cannot read, its saved workspace is sealed before it is stored, and the agent's web browser runs inside the same enclave. You can watch or take over that browser from your devices; what it shows travels sealed.

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. Our server logs record timings, counts and errors — never content, and rooms only as one-way hashes — and are deleted after 30 days.
• Hide my IP. With this switch on in Settings, the app's requests to us travel through a relay (Oblivious HTTP): the relay sees your IP address but only encrypted requests, and we see the requests but only the relay's address. The relay is attested code that keeps no record of where you connect from. Loading the app itself still reaches our CDN directly.
• Free help. The in-app help assistant needs no account; to keep it free we count its requests per network, using a one-way hash of your network address that changes daily.
• 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 and places

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.

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. During early access nothing is charged.

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. Superseded versions and our daily storage backups — ciphertext as well — expire within 35 days, so a deletion is complete by then. Delete my account removes your directory entry and username, your billing user and its provider keys, and your backup, and deletes the Spaces only you were in; Spaces you share with others stay theirs. Sign-in tokens are never stored. Operational logs are deleted after 30 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, delete your account, revoke a connection, turn off being found by email, release a username, turn on Hide my IP, or reset a device — which erases everything the app keeps on it at once. 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.