A private AI assistant with exactly one way out: designing the outbound boundary 只留一个出口的私有 AI 助手：设计出站边界

The claim and the proof are different things

Anyone can say “self-hosted and private”. It’s an easy overclaim, and a nervous buyer has heard it before, often shortly before something leaked anyway. What earns trust is the opposite approach: instead of promising data never leaves, say exactly where it leaves, why it has to, and what stops it leaving anywhere else. A vendor who volunteers the one exit has actually thought about the boundary, and that’s more convincing than any “100% private” banner.

Five controls, each an architecture decision rather than 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 and nowhere else. Self-hosted on your machine, the assistant has no home in anyone’s cloud, so there’s no account elsewhere to be breached or subpoenaed.
• Never on the public internet. A private mesh (Tailscale) with no inbound public port. You can reach the machine; the open internet can’t address it, so there’s nothing to port-scan.
• Your model keys, your inference. Every reasoning call uses your own API key. The model is rented per call on your account, not through a middleman who sees your data.
• Encrypted at rest and fully exportable. A local encrypted store, with export to plain formats plus the original source files at any time. Owning your data means being able to leave with all of it; lock-in is a kind of leak too.
• 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 and every business connector read and write locally. The provider call is the single exit, and because it’s the only one, it’s the only thing you need to reason about, rate-limit and log. Everything else is contained by how the system is built, not by policy. With one door, you can actually watch it.

That’s also the honest caveat: the model call does leave the machine. So the boundary isn’t “nothing ever leaves”. It’s “only the model API you chose sees a request, on your account, and you can see every time it happens.” That kind of precision is what a real privacy design looks like, and stating it plainly is what separates it from a marketing claim.

The through-line

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

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

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