Your tasks are encrypted on your device with keys we never hold. Authorization is enforced by signatures, not database flags. This page tells you exactly what our servers can and cannot see.
Every task and comment is encrypted client-side before upload. What crosses the wire is ciphertext, signatures, and sealed keys. The server's job is not to read your data — it's to verify it.
The second deliberate exception is metadata: like every E2EE system, we see the shape of your activity even though we can't see its content. We enumerate exactly what below, instead of hoping you won't ask.
That right-hand column is our honest metadata disclosure. If your threat model requires hiding the membership graph itself, we're not there yet — and we'd rather tell you that here than in your pentest report.
Every AEAD invocation carries associated data pinning the ciphertext to its exact place in the system — a sealed key cannot be replayed across tracks, recipients, epochs, or purposes, because the AAD won't match.
An edge is a key you hold. A missing edge is ciphertext you can't read. Three tracks, three humans, one agent — trace any path yourself.
For teams already deploying AI agents against real systems. You choose how much an agent sees — a full seat beside you or a single task — and either way, revoking it is one operation, not a key-rotation ceremony.
Capability tokens can only narrow or stay the same at each hop — never widen — and are verified server-side on every operation. The root must be signed by a human — agent authority is always auditable back to a person.
A human member and a service agent join by different doors. One receives the track key; the other never does — follow either protocol step by step.
A small, memory-safe surface served from EU infrastructure — the API, the crypto core, and the browser client share one memory-safe codebase.
You're evaluating a security product; here is the other side of the ledger, current as of July 2026.