Where your knowledge lives, and why it stays yours.

1. Where your knowledge base is stored

Short answer: in our cloud, but encrypted so we can’t read it. “Encrypted in your browser” is about where the encryption happens (client-side, before anything leaves), not about where the file lives afterwards.

When you upload a file — a past brief, a client email, your notes — it is encrypted inside your browser before it ever reaches our servers. What we store is a sealed block of unreadable bytes. We use Supabase Storage, a managed object store running on AWS S3. The encrypted files sit there under your account ID.

We can see that a file exists, how large it is, and when you uploaded it. We cannot see the filename, the contents, or the structure.

The exact split: what lives where

In our cloud (Supabase Storage, on S3-compatible infrastructure):

• The encrypted file bytes — opaque to us.
• A database row with file ID, encrypted filename, size, timestamp. No plaintext content.
• A row in ema_knowledge_keys with your salt and a verifier hash — enough to tell whether a passphrase derives the right key, not enough to recover the key.

On your device (inside your browser, nothing on disk):

• Your passphrase — held in the browser’s sessionStorage for the active tab, wiped the moment you close the tab.
• The derived key — held in browser memory only, re-derived from your passphrase each session.
• Decrypted bytes — briefly in RAM, only during a single draft request. Never written to disk.

Why store the encrypted files in our cloud instead of locally on your device? So you can sign in from any browser or laptop and pick up where you left off, so you don’t lose your knowledge base if your laptop dies, and so KBs can (soon) be shared across teams via expertaiteam and expertaishare — which only works if the storage lives somewhere both parties can reach.

2. How it’s encrypted

We use AES-GCM with a 256-bit key — the same cipher that protects your bank’s traffic and your phone’s disk. The key is derived from a passphrase you set when you first sign up, using PBKDF2 with 600,000 iterations (the current OWASP-recommended work factor). Derivation and encryption happen inside your browser via the Web Crypto API — the same cryptographic layer that powers HTTPS and password managers.

3. How a reply gets drafted

When you paste an AI output and click Run Expert AI, three things happen:

• Your browser fetches the encrypted files it needs — only the ones relevant to the current request, not your whole library.
• Your browser decrypts them locally with the key held in memory.
• The decrypted text, plus your paste, is sent over HTTPS to Anthropic’s Claude API. Claude generates the reply and returns it. The plaintext is held only as long as it takes to generate the answer, then discarded.

4. Why this is safer than the alternatives

Every AI tool must see your data at some point to work with it. The real questions are who sees it, for how long, and what they do with it afterwards. Here’s how we compare.

vs. Giving an AI access to your SharePoint, Google Drive, or email

Enterprise assistants like Microsoft 365 Copilot and Gemini for Workspace have standing access to everything in your tenant. They index your whole document library and every mail thread. The AI pulls from them even when you haven’t explicitly selected a particular file — that’s the whole product pitch. Vendor admins can typically see what the AI accessed. If your IT policy changes, if an admin account is compromised, or if the vendor has a breach, the blast radius is your entire corpus.

Our model is the opposite: zero standing access. We cannot read anything in your knowledge base unless you are present (to supply the key) and actively drafting (to trigger the decryption).

vs. Pasting documents into ChatGPT, Claude.ai, or Gemini

Consumer AI chat products retain what you paste, often for 30 days or longer, and many will use it to improve their models unless you have explicitly opted out at account level. Your sensitive drafting material becomes a candidate for training corpora. There is no encryption on what you paste — it sits in the vendor’s database as plaintext, searchable by their staff and discoverable in a subpoena.

With encryptmyai, your knowledge base content never sits on a vendor’s server as plaintext. It is only decrypted in the brief moment it is needed to draft one reply.

vs. Uploading a document to a chat or a custom GPT

When you attach a PDF to a chat or upload a file to a custom GPT, that document often becomes part of the vendor’s permanent data store. You lose track of where copies live, you may not have a reliable way to delete it, and you have handed over the whole document even if the AI only needed a paragraph.

We only ever expose the minimum necessary chunks to Claude, and only during the request itself. Nothing lingers on our side as plaintext.

5. The honest trade-offs

This architecture has two costs you should know about up front.

If you forget your passphrase, your knowledge base is unrecoverable. We cannot help you — we don’t hold the key. That is not a limitation we can engineer around without weakening the whole guarantee. We strongly recommend storing your passphrase in a password manager (1Password, Bitwarden, or similar).

During a draft, the decrypted content briefly reaches Anthropic’s API. Anthropic’s commercial API policy is contractual and public: they do not train on API data, and they delete API content after a 30-day trust-and-safety retention window. We cannot make that window shorter than Anthropic’s policy allows, but it is the smallest and most constrained exposure window of any practical architecture we know of.