← Back to Blog
Privacy March 11, 2026 AES-256 Encrypted

AES-256: What Your Encryption Actually Does (Plain Language)

Encryption should be legible to the people it protects. Here's what yours actually does.

Most privacy claims are marketing. "We take your privacy seriously." "Your data is protected." "We never sell your information." These are sentences designed to reduce anxiety, not convey technical reality.

The Architect uses AES-256 client-side encryption. That's a specific technical claim that has a specific meaning. Here's what it actually means for your journal.

AES-256: The Standard

AES-256 (Advanced Encryption Standard, 256-bit key) is the encryption standard used by the US government for top-secret information, by Signal for end-to-end messages, and by financial institutions for sensitive transactions. It is, to current knowledge, computationally unbreakable. A brute-force attack attempting every possible key would take longer than the age of the universe on any hardware currently conceivable.

When we say your entries are AES-256 encrypted, we mean: without the key, the ciphertext is indistinguishable from random noise. No one — no employee, no government agency with a subpoena, no sophisticated attacker — can read your entries without your key.

"Client-Side" Is the Critical Part

Encryption is only meaningful if you control the keys. Server-side encryption — what most apps use — means the company encrypts your data on their servers using keys they control. This protects you from someone breaking into the server without authorization. It does not protect you from the company itself.

Client-side means your device performs the encryption before the data leaves it. The key is generated on your device. It stays on your device. What we receive is already ciphertext — a string of characters that means nothing to us.

How it works on The Architect1. When you create an account, a 256-bit AES key is generated in your browser using the Web Crypto API. 2. That key is stored locally and given to you as a recovery key. 3. Every entry is encrypted using this key before it's sent to Supabase. 4. We store the encrypted string. We have no copy of your key. 5. When you return, your device uses the local key to decrypt before display.

What It Doesn't Protect

Honesty matters here. When you write an entry and request a mentor response, your entry is decrypted locally and the plaintext is sent to the AI to generate a response. This is a necessary tradeoff — the AI cannot respond to ciphertext. That plaintext is processed transiently and never stored in readable form. But during the request, it exists in plaintext on the API route.

The encryption protects your stored history completely. The AI interaction is necessarily a brief exposure. We've designed it to minimize that exposure — but if complete zero-server-contact is your requirement, that's a different architecture (and we're building toward it).

Verify It Yourself

Export your data from the Settings page. Open the JSON file. You'll see ciphertext — strings of characters that aren't your entries. That's the proof. Your words aren't there in readable form. They exist only on your device, decryptable only with your key.

This is what "private by design" means. Not a policy. A verifiable, technical fact.

This is what The Architect does.

Write a diary entry. Get a real mentor response — specific to what you actually wrote. Private, encrypted, free to start.

Start journaling for free →