The convenient choice is usually the wrong one for sensitive data
Most AI assistants are optimised for being easy to reach. You open a tab, paste in whatever you’re working on, and get an answer. That convenience is exactly the problem the moment the thing you paste in is a client’s data, a credential, or anything that would be a liability if it were logged, retained, or used for training.
I didn’t want the decision about which assistant to use to be made implicitly by whichever one happened to be open. For anything confidential, the assistant has to be chosen on purpose, and it has to be one whose handling of the data I can actually reason about.
Why Lumo
I settled on Lumo, Proton’s privacy-focused LLM, as the default for sensitive work. The argument that actually moved me is the one Proton puts front and centre: chats with Lumo are stored with zero-access encryption, so Proton can’t see your chat history — only you can access your conversations, by logging in to your Proton Account.
That’s the kind of guarantee I can design around. It means the sensitive material I hand it isn’t sitting in readable form in a general-purpose provider’s logs, and isn’t quietly becoming training data. I’d rather the privacy property come from how the system is built than from a promise in a terms-of-service document that can be revised later.
The honest caveat: this is still trust
I want to be clear-eyed about what this is and isn’t. Zero-access encryption shifts a lot in my favour, but I’m still trusting a company’s implementation and its claims about that implementation. The genuinely self-sovereign version of this would be a model I host myself, where there’s no third party to trust at all.
For now, that isn’t realistically achievable in a home setup — running a capable model locally with acceptable quality and performance is still out of reach at that scale. So Lumo is the pragmatic middle ground: a provider whose entire architecture is built around not being able to read my data, chosen precisely because full self-hosting isn’t on the table yet. If that changes, so does the default.
lumo-tamer: making the right choice the easy one
A privacy guarantee I have to remember to invoke is a guarantee I’ll eventually forget under deadline pressure. So the practical half of this is driving Lumo through lumo-tamer, which lets me pull it into my actual terminal workflow instead of context-switching to a browser.
That matters more than it sounds. The reason people leak sensitive data into convenient tools isn’t carelessness, it’s friction: the safe option lives in another window and the convenient one is already under their fingers. Bringing Lumo into the terminal removes that gap, so the privacy-preserving path is also the path of least resistance.
What this means for the rest of the stack
The flip side of committing to a deliberate default is that everything else gets demoted rather than removed. opencode, which I’d been reaching for day to day, now has a much narrower job: experimental connections and throwaway integrations, the kind of exploratory wiring where I’m testing whether something is even possible. None of that work touches sensitive data, which is exactly why it’s a safe place for a more experimental tool.
The split is intentional. One assistant for anything confidential, chosen for how it handles data, reached through a workflow that makes it frictionless. Another, kept deliberately at arm’s length, for experiments that are allowed to be messy precisely because nothing important is riding on them.
The underlying pattern
This is the same principle I keep coming back to with automation and infrastructure: don’t rely on a human staying disciplined indefinitely. Make the safe thing the default, remove the friction that pushes people toward the unsafe shortcut, and draw a clear line about what each tool is allowed to touch. The goal isn’t to never use experimental tools. It’s to make sure the experimental ones never end up holding data that was never theirs to hold.