Jul 3, 2026
What private AI chat should hide
Michael Ryaboy3 min readWhen people ask whether an AI chat app is private, they usually get a policy answer. The company says it will not train on your prompts, or it will retain data for fewer days, or enterprise administrators can configure a setting. Those promises matter, but they are not the boundary I want to depend on.
The boundary I care about is simpler: where does the readable prompt exist? If the server receives plaintext, the server has to be trusted. If logs, retries, queues, analytics, or support tooling touch plaintext, the operating surface gets larger. Good people can still build systems that accidentally preserve too much.
A private chat should move the boundary into the browser
garlic.ai uses PrivateMode in the browser so the message is sealed before it crosses the app server. The app server still has a job: it forwards protocol traffic and injects the server-side PrivateMode credential. But the goal is that the chat plaintext is not available to that server path in normal operation.
That distinction changes how I think about product design. A private chat app should not need accounts before you can try it. It should not create server-side history as a convenience. It should not make the easiest path the least private path. The default should be a clean, boring session: type, encrypt in the tab, receive an answer, and leave no server-side transcript behind.
What other tools often mean by private
Many tools use privacy to mean policy-level restraint: they will not train on a prompt, they will delete it eventually, or they will isolate it inside a vendor account. That can be a reasonable enterprise control, but it is not the same as avoiding plaintext on the service path.
- If a product needs plaintext on its backend, privacy depends on every backend system that can see or copy it.
- If history sync is server-backed, privacy depends on the storage path, access controls, backups, and deletion semantics.
- If AI search or tool use is bolted on without care, the search query can become a second copy of the sensitive prompt.
I am not arguing that every product must make the same tradeoff. Collaboration, admin controls, and cross-device sync all have value. But users should be able to tell when they are choosing those tradeoffs. The private default should not be hidden behind an enterprise procurement checkbox.
What garlic.ai tries to make obvious
The product language stays narrow on purpose. We say the chat content is encrypted in the browser before it crosses the server boundary. We also say saved chats, when enabled, are saved only in this browser. Those are implementation claims, not vibes.
There are still things the app can observe: route, timing, model choice, protocol headers, ciphertext sizes, and whether a request is in flight. Metadata is real. The privacy claim is not that the internet disappears. It is that the readable chat content is pushed out of the normal server path.
That is the product I want to use. No ceremony, no account wall, no server-side chat archive pretending to be a privacy feature. Just an AI chat where the most sensitive data is handled as if it is sensitive by default.