Most software that promises to keep your data local means something slightly looser than it sounds. It means we don't send it to a company. Your own network — the laptop, the desktop under the desk, the little server in the cupboard — is treated as inside the wall, and traffic there doesn't count as leaving.

That is a reasonable line and almost everyone draws it. NAOMS draws it somewhere else, and the difference shows up the first time you try to be clever.

Where the model actually runs

On your machine. That is the whole design, and everything below is a consequence of taking it literally.

The component that talks to the local model will only address the computer it is running on. Not "prefers" it, not "defaults" to it — that is the only address it will accept, and it holds even if you set the configuration variable to something else by hand. The directive it implements is one sentence, from 2026-05-14: "vLLM must run only locally."

Your own machine is therefore never the thing being excluded. It is the only thing included. What the design refuses is a different computer — and the reason it refuses even a computer you own is the interesting part.

Why draw the line at the machine

Because "my network" is a category that quietly grows.

It starts as the box down the hall. Then it's the box down the hall while you're on the café wifi through a tunnel. Then it's a friend's machine you're borrowing capacity from. Then it's a rented GPU that is, technically, on a private network you control. Each step is defensible, and the last one is indistinguishable from the cloud service the whole design exists to avoid.

The prompt you send a model is not incidental data. It is the question you're asking, which usually contains the thing you're asking about — the document, the name, the symptom, the worry. It's among the most revealing traffic a personal system produces.

A rule of "don't send that off the machine" is checkable in one line. A rule of "don't send that outside my trusted network" requires a definition of trusted that survives every future convenience, and that definition erodes. So the boundary is drawn where it can actually be enforced: the computer the request started on.

It isn't a wall. It's the default setting of a permission system.

This is the part that took me a while to see properly, and it's the thing worth understanding about the architecture.

The local-only behaviour is not a special case hardcoded into one component. It is a policy, evaluated before the model is ever called. Providers are classified, and the rule says: at the moment of generating, only a local-class provider is permitted. Anything else is denied before the request exists.

Which means the interesting question is not "how do I get around it" but "how does something ever get permitted?" — and there is an answer, by design.

Reaching outward is not forbidden. It requires an explicit grant from you, and that grant is recorded. When an operator enables a cloud provider, that action writes a consent receipt naming the provider class, and the gate consults that receipt when it evaluates the policy. No receipt, no egress. A receipt, and the same gate lets it through.

So the shape is: classify, deny by default, permit only on a recorded consent, and check the record at the point of use. That is a governance layer, and it gives you something a hardcoded restriction never could — an auditable answer to what is allowed to leave, and who said so.

The principle underneath it is stated plainly in the project's own policy catalogue, and it is the sentence I'd keep if I could keep only one:

Data never leaves. Computation comes to the data. Share only results, never raw memories.

That is why the GPU box works the way it does. It isn't a workaround for a restriction — it is the same principle: the work travels, the data stays.

Checking an address is not the same as trusting it

Checking that an address is local sounds trivial. Resolve the hostname, confirm it's loopback, proceed.

That check is defeated by time. A name that resolves to loopback when you validate it can resolve to something else moments later, when you actually connect — the classic version of this trick has a name and a long history of working.

So the provider doesn't just validate the endpoint; it re-resolves and re-validates, and it treats a policy failure as a typed error rather than a warning to log. The verification happens against the address that will really be dialled, not the one that was inspected earlier.

That's the difference between a check and a guarantee, and it's the part that would be quietly dropped by anyone reimplementing this from the description.

And the refusal is pinned by a test asserting the provider is denied — a property the suite enforces rather than a comment expressing an intention.

How you use the fast machine — because you do

You run NAOMS on it.

The GPU box gets its own daemon, and your laptop reaches it as a peer, over the same encrypted device-to-device link the rest of the system already uses, with the same identity and permission model. The work is dispatched to it as a task, and its model runs against its own local address exactly as yours does.

So the capability is not withheld. Both machines are yours and both are usable; what changes is which thing crosses the gap. Instead of your prompt travelling to a model server, a request travels from one identified peer to another, and the prompt stays where it was typed.

That is the architecture in one line: each machine keeps its own model traffic on itself, and machines cooperate as peers rather than as a client and a server. It is the same rule applied twice, not a rule plus a workaround.

Where these boundaries usually break

Most privacy boundaries fail at the second definition rather than the first. "Nothing leaves the machine" is enforceable. "Nothing leaves my trusted network" requires maintaining a notion of trusted that will be widened, once, for a good reason, by someone reasonable — and then it's a perimeter with a door in it.

Drawing it at the machine is the version that survives, because "this computer" needs no maintenance — it cannot be widened by a reasonable person on a Tuesday.

And the capability you actually wanted is still there. Two machines, both yours, both usable, cooperating as peers. The architecture didn't remove the fast box from your reach; it changed what travels between the two of them, so that the thing that stays put is the one you'd most want to.

---

Written by AI agents from real project logs; owned and edited by Mujo.