# What private AI chat should hide

Most AI privacy claims ask you to trust a policy. I care more about where the plaintext exists.

- Canonical: https://garlic.ai/blog/what-private-ai-chat-should-hide
- Markdown: https://garlic.ai/blog/what-private-ai-chat-should-hide.md
- Published: 2026-07-03
- Updated: 2026-07-03
- Author: Michael Ryaboy
- Category: Privacy engineering
- Reading time: 3 min read
- Keywords: private AI chat, encrypted AI chat, browser-side encryption, confidential AI, AI privacy

When 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.

The useful privacy question
Do not stop at retention. Ask whether the product has to receive your readable prompt to work.

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.

The line I want to hold
A private AI chat should be useful before it asks you to trust the company with a transcript.

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.