We Built an AI Chat That Even We Can't Read. Here's How to Prove We're Not Lying.

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
  - holds your recovery-derived keys
  - masks PII before the provider layer
        |
        v
Brianni storage
  - ciphertext only
        |
        v
Attested enclave
  - temporary plaintext
  - verified code measurement
        |
        v
AI provider
  - sees the masked plaintext needed to answer
        |
        v
Encrypted reply
  - stored as ciphertext again

Your device checks the enclave before every session. This is the part that turns the whole thing from another policy promise into something verifiable:

1. Your client generates a fresh random nonce and requests attestation.
2. 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.
3. 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.
4. Mismatch = hard failure. No fallback, no retry-with-a-warning, no session.
5. 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 pinned measurement is:

PCR0 79dd3fefb84afcdbbbc5c5c02635e9513fafd562eacc7df8c3215b25ad26db60a635cfec792d65bddbe8766bed58d6bb

Don't take my word for it

A pinned hash is only as good as your ability to know what code it represents. So the enclave is open source with a reproducible build: the same source produces a byte-identical image — and therefore an identical PCR0 — for anyone who runs the documented toolchain.

One honest caveat on "anyone": producing a PCR0 requires nitro-cli, which needs a Nitro-capable x86_64 EC2 instance — a few pence an hour on spot, but not your laptop. The repo README documents the exact host setup. From there:

git clone https://github.com/zeemudia/brianni-enclave
cd brianni-enclave
git checkout v1.0.0-pcr0-79dd3fef
./infra/docker/vendor-deps.sh
./enclave/build.sh --offline
jq -r .pcr0 enclave/measurement.json

If that prints anything other than 79dd3fef…, one of two things is true: we have a reproducibility bug (we've hit and fixed several ourselves — stale .pyc files, tar mtimes, dpkg status drift; please file an issue), or we're lying. Either way, you have found something important in public.

Now walk the chain of what cheating would actually require:

• Run different code in the enclave? The hardware security module signs the measurement of whatever is actually loaded. A different image means a different PCR0. Every client running the published verifier rejects it immediately, and the service goes down loudly. There is no "silently swap the backend" move against the verifier users receive.
• Publish source that doesn't match the running image? That's exactly what the reproducible build catches. Anyone can run it, any time, unannounced.
• Forge the attestation? At that point the trust assumption has moved beyond Brianni-AI and onto AWS Nitro itself. If that is your threat model, no cloud confidential-computing product survives it.
• Quietly decrypt stored data later? With what keys? The server holds ciphertext and never held the keys. There's no password-derived escrow, no key envelope — nothing to subpoena that decrypts.

One completeness note, because it's visible in the source and I'd rather explain it than have you find it: a few configuration documents — the provider/model registry, agent skill prompts, and a (currently disabled) connector catalog — are served to the enclave at startup rather than baked into the image, so they sit outside PCR0. They can't be silently tampered with either: each is signed offline with a key held outside the build and deploy pipeline, verified inside the enclave against a public key that is baked into the measured image, with a version floor that blocks rollback to older signed copies. The catalogs live in the public repo, so what they grant is auditable the same way the code is.

The verifier bounty

The first five people who independently reproduce the measurement get named (with consent) in our public verifications file and in VERIFICATIONS.md in the repo — plus 12 months of Max free (the $99/mo tier). Report via a public issue on the enclave repo with your observed PCR0 and host details.

And if instead you break the claim — find a way the operator could read conversations that isn't disclosed below — you get the story, told by us, with your name on it. For anything that's actually a vulnerability, please don't open a public issue: email security@brianni.ai (the repo README lists the channels) and we'll do coordinated disclosure properly. Public issues are for reproduction reports and reproducibility bugs.

What we can see

Operator blindness is about content, not existence. Metadata is real, and you should weigh it.

On the product itself we minimize metadata hard: the Brianni-AI app and its landing page carry no analytics, no trackers, no pixels, no fingerprinting, no session replay — a CI gate scans every build and fails if a tracker signature appears. Open the network tab on app.brianni.ai and count. Full disclosure, before someone opens the network tab here: this post is hosted on the parent company's blog, which uses basic analytics as its cookie notice describes. The AI product's zero-tracker guarantee is about the product, and it's the part a CI gate enforces.

But I won't pretend metadata is nothing.

Why it's paid

There is a free tier for trying the core models. Pro is $19.99/month with $6 of provider compute included and a hard ceiling — you can never be surprise-billed. Max is $99/month. Subscriptions are the only revenue: no ads, no data monetization — there's nothing to monetize even if I wanted to; see everything above.

If the architecture matters to you, this is how it keeps existing: a business model whose incentives don't want your data. You pay for the service; the service can't read you.

Every AI company asks you to trust them.

I'd rather make trust less necessary.

If this architecture works, you should not need to believe a word I've written here. You should be able to verify the code, rebuild the enclave, compare the measurement, and catch us if the story and the system diverge.

That's the standard we're trying to build toward.

Try it: app.brianni.ai · Verify it: the reproducible-build recipe · Read the enclave source: github.com/zeemudia/brianni-enclave