We Built an AI Chat That Even We Can't Read. Here's How to Prove We're Not Lying. | Brianni Blog<br>Skip to contentBlog›ai-privacy<br>ai-privacyconfidential-computingtrusted-execution-environmentreproducible-buildsremote-attestationaws-nitro-enclaveszero-knowledgeprivacy<br>We Built an AI Chat That Even We Can't Read. Here's How to Prove We're Not Lying.<br>Zee<br>4 July 2026 · 9 min read

Every AI company says some version of the same sentence: "we take your privacy seriously."

That's a promise.

Brianni-AI — GPT, Claude, and Gemini in one app — is built around a different kind of claim:

We designed the system so that the operator (me) cannot read your conversations, even if I wanted to.

More importantly, you shouldn't have to believe me. Most privacy claims are not falsifiable. Ours is. If we're lying about the code running in the private chat path, there is a public, reproducible process that should expose it.

I've written before about why no single party should hold both your identity and your content. This post is the other half: how the architecture enforces operator blindness, what it does not solve, and exactly how you can try to catch us lying. We're rewarding the first five people who run the verification successfully.

The claim, in one sentence

If you do not care about hardware attestation, here is the short version:

Your chat history is encrypted with keys we never possess, and the only server-side place conversation plaintext exists is inside hardware whose exact software you can independently verify.

The precise claim is operator blindness : Brianni-AI's servers store only ciphertext they cannot decrypt, and conversation plaintext exists server-side only inside a hardware-isolated enclave whose exact code is publicly verifiable.

The claim is not end-to-end encryption to the model. An AI provider has to read your message to answer it — anyone who tells you otherwise is selling something. What we do about that layer: PII masking runs on your device — regex plus a local NER model, before anything leaves your browser — so names, emails, addresses and the like are replaced with placeholders before the text ever reaches OpenAI, Anthropic, or Google. Masked text is still plaintext to the provider. We don't yet have zero-data-retention agreements with providers, and we won't claim them until we do.

How it works

Your keys, not ours. Sign-up is email OTP plus a passkey — no passwords, anywhere in the system. Your chat encryption keys derive from a 24-word recovery phrase generated on your device and never sent to us. Everything we store was encrypted with keys we never had. Lose the phrase and all your devices, and your history is gone — even for us that's not recoverable, which is the design working, not failing.

The server is a blind courier. Auth, billing, and storage all operate on ciphertext blobs. There is no ordinary server decryption code path, because there is nothing it could decrypt with. Assume the breach: an attacker with our whole database gets encrypted bytes, not conversations.

Plaintext exists server-side only inside an AWS Nitro Enclave. When a chat request needs model context, the sensitive work happens inside a hardware-isolated enclave — no interactive access, no SSH, not even for the host machine it runs on. The enclave calls the model provider, re-encrypts the reply to your keys, and zeroes its memory. It is stateless by construction: nothing survives the request. The provider API keys live only inside the enclave; a config validator rejects them if anyone tries to put them on the host.

As a flow, it looks like this:

Your device<br>- holds your recovery-derived keys<br>- masks PII before the provider layer<br>Brianni storage<br>- ciphertext only<br>Attested enclave<br>- temporary plaintext<br>- verified code measurement<br>AI provider<br>- sees the masked plaintext needed to answer<br>Encrypted reply<br>- stored as ciphertext again<br>Your device checks the enclave before every session. This is the part that turns the whole thing from another policy promise into something verifiable:

Your client generates a fresh random nonce and requests attestation.

The enclave returns an attestation document signed by AWS hardware — not by our app code — containing the measurement (PCR0) of the exact enclave image that is running, our nonce, and the enclave's ephemeral session public key.

The client verifies the signature chain, checks the nonce and timestamp from the signed payload, and compares the PCR0 against a value pinned in the client . That proves the attestation came from the hardware path, is fresh, and describes the code the client expected.

Mismatch = hard failure. No fallback, no retry-with-a-warning, no session.

Only then are session keys established — encrypted to the public key that appeared inside the hardware-signed document, so only the attested enclave can open them.

PCR0 is the enclave image's cryptographic fingerprint. Change one byte of the code or build output and the value changes. The currently...