A private AI assistant that never leaks: designing the outbound boundary

15 Jul 2026

"Your data never leaves your machine" is the promise every privacy-anxious buyer wants to hear — and it's meaningless unless you can point at the single place data does leave, and prove nothing else can. The trust isn't in the reassurance. It's in drawing the outbound boundary explicitly, and designing the system so there's exactly one door.

The claim and the proof are different things

Anyone can say "self-hosted and private." The overclaim is easy and it's what a nervous buyer has heard before, usually right before something leaked anyway. What actually earns trust is the opposite move: instead of promising it never happens, you name precisely where data leaves, why it has to, and what stops it leaving anywhere else. A vendor who volunteers the one egress is a vendor who has actually thought about the boundary — and that's more convincing than any "100% private" banner.

Five controls, each an architecture decision — not a promise

Take a buyer's list of "non-negotiables" for a private assistant and turn each one from a feature into an enforced mechanism:

• Runs on your hardware, nowhere else. Self-hosted on your machine — the assistant has no home in anyone's cloud, so there's no account to be breached or subpoenaed elsewhere.
• Never on the public internet. A private mesh (Tailscale) with no inbound public port — the machine is reachable by you, and unaddressable to the open internet. There's nothing to port-scan.
• Your model keys, your inference. Every reasoning call uses your own API key — the intelligence is rented per-call under your account, not mediated through a middleman who sees your data.
• Encrypted at rest, and fully exportable. A local encrypted store, and export to plain formats plus the original source anytime. Owning your data means being able to walk away with all of it — lock-in is its own kind of leak.
• No silent failure. Every workflow has a heartbeat; a silent failure pings you instead of rotting quietly. A privacy system that dies without telling you is a privacy system you've stopped being able to trust without knowing it.

The one door: only the inference call leaves

Drawn as a data-flow, the whole system has exactly one arrow pointing outward: the inference call to the model provider, made on your key. Capture, transcription, memory, the knowledge graph, every business connector — all of it reads and writes locally. The provider call is the single egress, and because it's the only one, it's the only thing you have to reason about, rate-limit, and log. Everything else is contained by construction, not by policy. When there's one door, you can actually watch it.

That's also the honest caveat, stated plainly: the model call does leave the machine. So the boundary isn't "nothing ever leaves" — it's "only your chosen model API sees a request, on your account, and you can see every time it does." Precision like that is what a real privacy design looks like, and saying it out loud is what separates it from a marketing claim.

The through-line

It's the same instinct as least-privilege everywhere else I build: don't grant a capability you can't account for, and make the sensitive path the narrowest, most visible part of the system rather than the vaguest. Trust with a privacy-anxious buyer isn't won by promising more — it's won by drawing the boundary so precisely that they can check it themselves. The system I'd be proud to hand over is the one where the customer can see exactly where their data goes, because it goes exactly one place.

This is how I design these systems — the pattern comes from years of backend work where the boundary between "inside" and "outside" a system is the thing you defend first.

A worked example of this boundary design is public: Intranet-Chat-Stream — a self-hosted, DB-less stream for moving text and files between your PC, phone and AI agents. A single Go binary, token auth, nothing exposed to the public internet.

← All notes