Open source · Encrypted · Verifiable

This page fact-checks itself. Every claim comes straight from our code.

We don't hand-write the encryption claims below. They're generated straight from the real system that runs them, and re-checked every time we ship. If the words and the code ever disagree, the build fails and this page can't go out. So don't just trust it — read it, and check it yourself.

  1. Our code records what it actually does.
  2. That record becomes the claims on this page.
  3. If the two ever disagree, the build breaks.
AGPL-3.0-only
Trust boundary map: your devices and the untrusted relay Two islands marked Your Mac and Your Phone sit inside solid trust boundaries with pinned keys. Between them, a dashed cloud marked untrusted relay carries a sealed envelope that crosses without being opened. Where the lane meets the device boundary, a gate marked fails closed refuses anything that tries to downgrade. YOUR MAC KEYS PINNED YOUR PHONE KEYS PINNED UNTRUSTED RELAY sees ciphertext · routes bytes FAILS CLOSED
trusted boundary untrusted sealed in transit
The license

We moved from MIT to AGPL. On purpose.

AGPL is the license that keeps network software honest: if anyone — including us — serves you this software over a network, you're entitled to the source that's running. For a tool that watches your spend and relays your screen between your devices, source access isn't a nicety. It's the audit mechanism.

AGPL-3.0-only

The license is a feature

Source you can hold us to.

Run it, read it, fork it. And because it's AGPL, anyone serving you this software over a network owes you the source — including us.

AGPL-3.0-only GNU AGPLv3 — official Free Software Foundation license badge

Historical MIT snapshots stay MIT — the relicense changes the future, not the past.

WE CLAIM WE DON'T

We claim: The product is AGPL-3.0-only at HEAD. Run it, read it, fork it — and if you serve it over a network, your users get the source too.

We don't claim: We don't relicense the past. Every shipped MIT snapshot stays MIT.

We claim: The official Signal library is pinned and wired in for device-to-device lanes and at-rest sealing.

We don't claim: We don't claim it's live. It is wired in but off by default — per-domain flag, staged rollout, instant revert — behind a fail-closed readiness gate.

We claim: Phone ⇄ gateway traffic rides a hardened encrypted gateway: keys pinned to your devices, safety-code pairing, forward secrecy, downgrade attempts refused.

We don't claim: We don't say “the assistant can't read your messages.” The gateway decrypts to run the model — that is what running a model means.

We claim: These claims are wired to the crypto registry: the encryption claim lines are generated, and the build goes red the moment they drift from it.

We don't claim: We don't claim an external audit. The gates are ours; an independent audit will be linked here when it happens.

AGPL-3.0-only at HEAD Historical MIT snapshots stay MIT — the relicense changes the future, not the past. Terms

The crypto core

We're putting the real Signal library where it belongs — carefully.

We pinned Signal's official open-source library — the exact code, not a reimplementation — for device-to-device lanes and at-rest sealing. Today it is wired in, not activated in production: a per-domain flag, default off, staged rollout, instant revert.

The iPhone and iPad app is libsignal-free by design. It reads the same sealed envelopes through Apple's CryptoKit — and that interop isn't a design promise: it's locked by committed cross-implementation test vectors that run in CI, sealed by each library and opened by the other. No Signal code ships in the App Store binary.

WHAT WE CLAIM

  • iPhone and iPad read the same sealed envelopes through Apple's CryptoKit — interop with the Signal library's seal is locked by committed cross-implementation test vectors in CI, with no Signal code in the App Store app.
  • Every phone-to-AI-gateway lane runs our own hardened encrypted gateway — forward-secret, keys pinned to your devices, downgrade attempts refused outright.
  • Device-to-device lanes (Mac, Android, daemon) are built on Signal's official open-source library, pinned at v0.94.4 — wired in today, not yet activated in production; activation comes by staged rollout with instant revert.
  • At-rest sealing on Mac, Android, daemon, and backend uses the official Signal library's sealed envelopes — wired in, not activated in production.
  • The iPhone app runs no device-to-device encryption of its own — it is a secure satellite that reads what your other devices seal.

WHAT WE DON'T

  • We don't put Signal's library on iPhone or iPad. The App Store app never links it — that is an enforced invariant in our crypto registry, not a roadmap item.
  • We don't claim any Signal-library lane is live in production. It is wired in but off — per-domain flags, staged rollout, instant revert. A fail-closed readiness gate keeps this sentence honest: when the rollout flips on, this page is forced to change.
  • We don't claim affiliation or endorsement. Signal Messenger has nothing to do with us — we pin their open-source library, and we say so plainly.
  • We don't claim an external audit. There hasn't been one yet; when there is, it will be linked here.

Generated from the crypto registry · pinned at v0.94.4 · drift fails the build

Horcrux

So our open upstreams stay clean, we built our own seal.

Parts of our assistant stack live in open upstreams that must stay MIT-clean — code we share back to communities that license their work permissively. Signal's library is AGPL; pulling it into those lanes would close doors we want open. So every phone-to-gateway lane runs Horcrux, our own sealed-envelope layer — a hardened, forward-secret encrypted gateway.

A CI job stands at that boundary: every contribution headed upstream is scanned so the MIT lane stays MIT. Not an honor system — a gate.

The seal protects the path: your phone to our gateway, past every relay in between. At the gateway it is opened to run the model — we don't say “the assistant can't read your messages,” because that would be false.

— the part most pages leave out

Horcrux: “Honestly, Our Relay Can't Read User eXchanges.” We checked — it's even true.

Sealed in transit
Fails closed
Why believe this

Our marketing is wired to our crypto registry.

Anyone can write a privacy page. Ours is compiled. The tier of every domain below is generated from the registry our apps run on. Every claim line above is keyed to a model in the crypto registry, its platform list comes straight from the policy matrix, and a fail-closed gate rejects the copy the moment the registry — or the rollout state — stops backing it. The wording is human; the facts behind it are machine-checked, and drift turns the build red.

Server-readable Zero-access End-to-end

// CI-gated · registry drift gate · build-verified

End-to-end Sealed on your device. Our servers never see the content or the key.

Conversations & Chat

Assistant chats, CLI agent transcripts, mobile mission prompts/results, saved text snippets, rollback scope/diagnostics, approval rules, agent personas, subscription graph edges, and conversation recall metadata are sealed on-device before Firestore receives them.

Our servers see
provider/runtime identifiers
message counts
status/routing metadata
timestamps
device ids
Only your devices
chat titles
chat previews
message bodies
CLI transcripts
mission prompts/results
saved text snippets
project/file/command labels
rollback scope paths
rollback error diagnostics
approval policy labels/globs/projects
agent persona text
subscription graph edges and display text

Searchable Session Logs

Full conversation bodies + the encrypted search index + project memory. Sealed on-device; the server holds only ciphertext, aggregate cockpit facets, and opaque search/integrity hashes.

Our servers see
provider
model
cost
token counts
timing
integrity hashes
deterministic keyed search digests
Only your devices
project/path text
title
snippet
body preview
full transcript body

NOTE The keyword search index is deterministic — repeated and co-occurring search terms produce stable keyed digests, so the server can learn which terms recur and appear together across your logs (the search structure), and the integrity hashes can confirm a guessed body or chunk; every title, snippet, body, and path stays sealed and unreadable.

Pensieve Knowledge

Your private semantic memory: repo docs, notes, and chat-derived memories your agents recall. Text is sealed on-device; hosted ANN recall is an explicit opt-in over cloaked vectors and opaque keyed hashes. Those structures still reveal structural signals such as vector geometry, recurrence/co-occurrence patterns, counts, and access timing. Use local-only recall for sensitive memories when available.

Our servers see
cloaked 384-dim vectors
sourceKind
opaque keyed slug/dedup hashes
opaque repo match token
chunk/byte counts
timestamps
Only your devices
chunk text
source paths
repo names
section/category metadata

NOTE A connected repo stores only an opaque keyed match token plus a sealed repo name — the cleartext repo name is observed transiently server-side only to route an inbound GitHub push webhook, never stored.

Device Trust & Vault Keys

Which devices are trusted to decrypt your data, and the wrapped vault keys that make end-to-end encryption possible. The crux of the whole E2EE model.

Our servers see
device trust state
public key fingerprints
wrapped (ciphertext) key blobs
Only your devices
the vault key itself (Keychain / 0600 file, never uploaded)
Zero-access Sealed envelopes. Our servers hold ciphertext, not content — the key stays under your device trust.

Agent Control & Escrow

Computer-use (Agent Control) sessions and their tamper-evident escrow audit trail.

Our servers see
session metadata
action counts
quota usage
Only your devices
sealed escrow envelopes

Media

Files, screen, and video relayed between your Mac and phones (Floo media).

Our servers see
session events
quota usage
attachment blob hash
mime type
byte size
opaque peer device-id hash
direction
timestamps
Only your devices
media payload contents (relayed/sealed)
attachment file names (sealed on-device)

NOTE An attachment manifest records only an opaque content hash, mime type, byte size, an opaque per-peer device-id hash, direction, and timestamps — the human-readable file name is sealed on-device (sealedFilename) and never readable by the server.

Server-readable Operational metadata, stored as readable text — our servers can read this.

Usage & Spend

Per-session token counts, cost estimates, and provider/model/device telemetry. Project names and budget labels are sealed on-device; the server groups spend only by opaque per-project hashes.

Our servers see
provider
model
device
token counts
cost estimates
timestamps
opaque project hashes
Only your devices
project names
budget labels

Provider Accounts

Connected AI provider accounts. Labels + status only — the actual credentials live in Google Cloud Secret Manager, never in your data tree.

Our servers see
provider id
redacted label
status
refresh metadata
Only your devices
secret material (in Secret Manager, not the user tree)

Connected Devices & Pairings

Your paired Macs, phones, and relays and which can talk to your account.

Our servers see
device ids
pairing metadata
last seen
relay routing
opaque relay key material (public keys)
Only your devices
paired relay + gateway frame contents after E2EE/runtime readiness is complete (message text, sender names, attachment file names — sealed on-device in that mode)

NOTE Paired relay and hosted-gateway frame contents are only claimed as sealed after paired E2EE is enabled and the runtime-readiness gate is complete; relay routing metadata, public keys, coarse tool labels, thread ids, attachment ids, and delivery state remain visible. The per-agent subscription graph is cloaked behind opaque keyed doc ids.

External Agent Access (MCP)

Coding agents you've granted hosted-MCP access to, the scopes they hold, and their access audit trail.

Our servers see
client id
display name
granted scopes
grant mode
access timestamps
Only your devices
decrypted search/recall results (decrypted only in the local shim)

Plan & Billing

Your subscription entitlements (Cloud Pro, Ultra) and their change history.

Our servers see
entitlement ids
product ids
active state
expiry
purchase source
Only your devices

Access Audit Timeline

A unified, tamper-evident log of who/what accessed your data, when — across every device, agent, and grant.

Our servers see
actor
action
domain
timestamp
hash-chain links
generic notification routing ids
Only your devices