What your AI cloud can and cannot see
In a hybrid end-to-end encrypted AI service, the cloud sees account and operational metadata: your email, billing status, usage counts, and sync timestamps. It cannot see your content: messages, memories, and journal entries are sealed on your device, and the server stores only envelopes of nonce plus ciphertext that it cannot open.
Why publish this list at all
Every cloud service sees something. The phrase end-to-end encrypted describes what a provider cannot see, and it is easy to let people assume that means everything. It does not. The honest move is to enumerate both columns: exactly what the servers hold and can observe, and exactly what they cannot. This page does that for Violet's cloud, using its actual database schema and server code as the source, so the list is checkable rather than aspirational. Violet is pre-launch, so this describes the built system behind the waitlist, not a live consumer service.
The two columns
| The cloud can see | The cloud cannot see |
|---|---|
| Your account email address and when the account was created | Anything you and the AI have talked about |
| A hash of your sign-in password, with its salt (never the password itself) | Your content passphrase, or the encryption key derived from it |
| The per-account key-derivation salt (a salt is not a secret) | The plaintext of any synced record, now or later |
| Session records: a hashed session token with created and expiry times | Your memories, notes, or journal entries |
| Billing state: plan name, active or inactive status, paid-through date, and a Stripe customer id | Any conversation that led you to subscribe, or your payment card details, which Stripe processes |
| Managed-inference usage: one token tally per account per day | Stored transcripts of those inference requests: the proxy forwards messages and never logs their contents |
| Sync metadata per record: a collection label, a record id, a version number, an updated-at timestamp, and a deleted flag | What the record contains: the content field is exactly a nonce plus ciphertext |
| Envelope sizes and how often each account syncs | Which words, names, topics, or people appear anywhere in your content |
| The network address a request arrives from, like any web server | What you typed, said, or heard inside the app |
Reading the visible column honestly
Two rows deserve extra candor. First, collection labels: sync groups records into named collections, and those names are visible to the server. A label can reveal the kind of record it holds, the way the label on a locked box reveals it contains letters without revealing a single sentence of them. Second, traffic patterns: the server necessarily observes when your devices sync and how much data moves. Neither of these exposes content, but a transparency page that omitted them would be marketing, not transparency.
The one deliberate exception: asking a hosted model
When you use managed inference, the messages you choose to send are forwarded to a model provider so the model can answer. Those messages are plaintext to the inference path at request time. That is not a leak; it is how asking a hosted model a question works, in any product. The honest boundaries are these: the inference module never logs message contents, the only thing recorded is a per-day token count for budgeting, and your at-rest content stays sealed regardless. If the caller is not entitled or the upstream model fails, the system returns an honest error rather than a fabricated answer.
Before you even have an account: the waitlist
Violet is pre-launch, and joining the waitlist stores an email address, a short source label such as which page the signup came from, and a timestamp. Nothing else. The join endpoint deliberately never reveals whether an email was already on the list, so it cannot be used to probe who signed up. No confirmation emails are claimed or pretended: the system marks addresses unconfirmed until a real double-opt-in flow exists.
How to check claims like these
- Ask for the enumeration. A provider that cannot list what it sees, plainly and completely, is asking you to trust a vibe.
- Apply the recovery test. If support can restore your content after you forget your passphrase, the provider holds a key and can see more than it says.
- Look for live state, not brochure claims. Violet's app includes a Trust panel that reports what is stored on the device and what the cloud can see, read from the real configuration at the moment you open it. While cloud sync is off, it says exactly that: nothing leaves the device.
- Watch the language around inference. Any product that sends questions to a hosted model should say what happens to those messages, not just what happens to stored data.
Questions
If authorities demand my data, what can the provider actually hand over?
Only what it holds: the metadata in the visible column, such as the account email, billing state, usage tallies, and the stored envelopes of nonce plus ciphertext. The provider cannot decrypt the envelopes, because the content key is derived from your passphrase on your devices and never sent to the server.
Does the cannot-see column depend on the provider keeping a promise?
The storage design does not: the server stores only sealed envelopes and has no key to open them, which is an architectural property rather than a policy. What you do trust is the client software running on your device, which is true of every end-to-end encrypted product. That is why the client behavior should be stated precisely and be checkable, not just asserted.
Is Violet available today?
No. Violet is pre-launch: the apps are not in stores yet, and there is a waitlist on the home page. Joining stores your email address, an optional source label, and a timestamp, and nothing more.