What we can see
Most services promise not to look. Aida is arranged so that looking is not possible — and so that your own devices can check.
Aida is not finished, so this page separates what is running today from what is designed and still to be built. A privacy promise you cannot yet rely on is worth saying out loud, not blurring into the ones you can.
Running today
Today The Relay forwards ciphertext it cannot read
Your browser and your Bot establish a Noise IK channel directly with each other. The Relay sees two WebSocket connections and copies frames between them; it holds no key that would open one.
Today Pairing secrets never leave your devices
Claiming a Bot uses a short code you read off it, which acts as the shared secret between your browser and the Bot. The raw code is never sent to Aida — only a value derived from it, which cannot be reversed. Your browser and the Bot then establish keys directly with each other, and from that point the code can no longer decrypt anything.
Designed, not yet built
These describe how the feature will work when it ships. None of it is running, and none of the data it concerns is being handled at all yet.
Planned The Backend will never see a prompt or a reply
The design: inference requests will pass through Aida encrypted to the enclave that runs the model, with the Backend attaching the API key and streaming bytes it cannot read, recording token counts for billing and nothing about content. Aida's side of that is written and refuses any model that is not end-to-end encrypted, and your Bot's side is written too. Neither is wired to anything you can run: no command on the Bot sends a prompt, so no inference happens at all today and nothing of yours is being sent anywhere.
Planned Your Bot will verify the enclave, not our word for it
The design: before sending anything, your Bot checks the hardware attestation itself — the nonce it chose, debug mode disabled, the measurements it expects, and the signing key bound to that quote — and refuses a model that is not end-to-end encrypted rather than falling back quietly. That verifier is built, and tested against a real quote from real Intel TDX hardware. But nothing in the Bot sends a prompt yet, so it never runs on your behalf. Until it does, treat this as a promise about how the feature will ship, not a property you can rely on.
Planned Your mail credentials will stay on your Bot
The design: Aida's servers never hold them. Adding an account configures your Bot over the encrypted channel, and the credentials are stored there and used from there. Mail is not built yet, so there is nothing to configure — and nothing of yours held anywhere.
What we do hold
Every table in Aida’s database that holds anything about you, and why it is there. This list is checked against the schema itself, so a new store of your data cannot be added without this page changing.
| What | Why | In use |
|---|---|---|
| Your email address, and a hash of your password | So that you can sign in. The password itself is never stored. | Yes |
| A hash of each live session | So a signed-in browser stays signed in. The session token itself is not stored, so a copy of this table would not let anyone sign in as you. | Yes |
| For each Bot you claim: an identifier derived from its claim code, a label you choose, when you claimed it, and when it was last seen | So your account knows which devices are yours. The claim code itself never reaches Aida, and neither does the Bot's credential — only hashes of them. | Yes |
| Counts of tokens used per request, and which model served it | So that you can be billed. Never any part of the request or the reply. | Yes |
| Your monthly budget cap, if you set one | So spending stops where you asked it to. | Yes |
| Your Stripe customer and subscription identifiers | So invoices reach the right account. No card details, ever. | Yes |
| The identifier of each billing message Stripe sends us | So that a message Stripe delivers twice — which it does by design — changes your subscription once. It holds an identifier and a type, never the message itself. | Yes |
Plus ordinary operational logs, which record that a request happened and never what it contained.