Encrypted Backups for Your AI's Memory (Why Plaintext Context Is a Liability)

After a few months with an AI coding assistant, its memory files quietly become one of the most information-dense artifacts you own: your architecture, your conventions, sometimes your incidents. Two things follow from that. It's worth backing up -- and it's worth encrypting the moment a copy leaves your machine.

What's actually in these files

Open your CLAUDE.md or memory directory and read it the way a stranger would. A typical accumulation, honestly surveyed: your stack with versions, architecture decisions and the reasoning behind them, internal service names and hostnames, database and cron topology, coding conventions, incident write-ups ("prod went down when the migration ran out of band -- never do X again"), and business context like pricing experiments or customer situations. Occasionally something worse: a fragment of a secret someone pasted into chat that got summarized into a memory note.

None of it is the crown jewels. All of it together is an excellent map -- a reconnaissance dossier your assistant helpfully wrote about your systems, one lesson at a time. And separately from the risk angle, it's months of accumulated understanding that would genuinely hurt to lose. Both halves of that argue for a backup; the first half argues for an encrypted one.

The threat model, without the drama

You are not defending against the NSA. If a nation-state wants your infrastructure map, your memory files are not the weak point. The realistic threats are boring:

• A lost or stolen laptop. Largely solved by full-disk encryption -- if FileVault or BitLocker is on, local plaintext files are fine at rest. Turn it on today if it isn't.
• The copies that travel. The unencrypted external drive in your bag. The cloud storage folder you synced it to. This is where plaintext actually leaks.
• A provider incident. A breach or misconfiguration at whatever service holds your backup -- you're one bucket policy away from your context being someone else's dataset.
• Your own git mistake. A memory directory accidentally pushed to a public repo. It happens constantly with .env files; memory files are next.

The rule of thumb: plaintext on your own encrypted disk is acceptable. Plaintext copies on other people's computers are the liability.

Option 1: a private git repo

Push your memory files to a private repository. You get versioning, diffs, and an off-machine copy for free, and it's the workflow you already know. The caveat people skip: "private" means access-controlled, not unreadable. The forge encrypts at rest with keys it holds, so the provider -- and anyone holding a leaked token, or benefiting from a visibility misconfiguration -- sees plaintext. For conventions and preferences, plenty of people accept that trade. For incident details and internal topology, accept it knowingly or don't.

Option 2: an encrypted archive

tar the directory, encrypt it with age or gpg, and put the ciphertext anywhere -- the dumbest storage works, because the storage only ever holds noise. This is genuinely encrypted at rest. The costs are operational: it runs only as often as your cron job or your discipline does, key management is now your problem (lose the key, lose every backup), each archive is a snapshot rather than a history, and restores need rehearsing. An encrypted backup you've never restored from is a hope, not a backup.

Option 3: memoir's encrypted sync

memoir splits the problem the way the threat model suggests. The local store is deliberately plain Markdown files on your disk -- human-readable is the feature; you can grep your own memory, and on an encrypted disk that's the right default. Encryption applies where it matters: when memory syncs to the cloud, it's encrypted client-side with AES-256-GCM before upload, and the keys never leave your machine -- the server stores ciphertext it cannot read. That gives you the off-machine copy and multi-machine sync in one motion, without a key ceremony or a cron job to forget. Restore is the same motion in reverse: install memoir on the new machine and sync pulls your memory down.

Whichever you pick, pick one this week. The failure mode here isn't choosing the wrong option -- it's months of accumulated context sitting in exactly one place, unencrypted copies drifting outward, until the day one of the boring threats finally lands.