No-Egress LLM: What 'Nothing Comes Out' Really Means
A no-egress LLM is a model deployment that has no route to the internet and no external name to resolve. Prompts and documents go in, answers come out — but there is no network path by which any of that content could leave the perimeter it runs in.
Things go in. Nothing comes out.
That sentence is the whole idea, and it is deliberately literal. A no-egress deployment is not a system that promises not to send your data anywhere. It is a system that cannot, because the two things any process needs in order to reach the outside world — a name to resolve and a route to travel — are simply not present. The distinction between "will not" and "cannot" is the entire point, and it is the difference between a claim you have to trust and a property you can check.
The doctrine: things go in, nothing comes out
Everyone building on LLMs today has to reason about where prompt content can end up. A prompt is not a search query; it is often the most sensitive text an organization produces — a draft drug claim under review, patient or trial data, unreleased earnings language, a classified operational context. The moment that text enters a model that has a path to the internet, the number of ways it could leak is large and hard to fully enumerate: a compromised dependency phoning home, telemetry you forgot was on, an SDK that retries against a fallback host, a prompt-injection instruction that tries to make the model call out.
No-egress collapses that whole surface to a single, checkable condition. Instead of trying to enumerate and block every way data could leave, you remove the capability to leave at all. If the deployment holds no route off the host and can resolve no external name, then every one of those exfiltration paths ends in the same place: nowhere to send it.
Why DNS and outbound routes are the surfaces that must be absent
To move data off a machine, a process needs two things, almost without exception:
- A name it can resolve. Software talks to the outside world by hostname —
api.some-vendor.com, a telemetry collector, an update server. Resolving that name to an address is the first step of nearly every outbound call. - A route it can take. Once it has an address, the process needs a network route that actually reaches it — a default gateway, a NAT path, an egress interface.
Remove either one and the outbound call dies before it starts. No-egress removes both. There is no external resolver the deployment can reach, so names do not turn into addresses; and there is no route off the host, so even a hard-coded IP address has nowhere to go. This is why the verification of no-egress is aimed squarely at these two surfaces. You are not auditing intent or reading a policy document. You are confirming that DNS resolution fails and that the routing table contains no path to the outside — that the mechanism of exfiltration is provably not present.
No-egress vs. "firewalled" or "restricted" cloud endpoints
This is the contrast that matters most, because "restricted," "isolated," and "private endpoint" are marketed in ways that sound like no-egress but are not.
| Property | "Firewalled" / restricted cloud endpoint | No-egress deployment |
|---|---|---|
| External name resolution | Still resolves external DNS names — the capability exists, a rule discourages using it. | No external name to resolve. The capability is absent. |
| Outbound route | Route to the internet exists; an allow/deny policy sits on top of it. | No route off the host exists to govern. |
| Failure mode | A misconfigured, disabled, or bypassed rule re-opens the path. | Nothing to misconfigure — there is no path to re-open. |
| Who holds the evidence | The cloud provider's control plane; you read a dashboard. | You do — the check runs on hardware you control. |
A "restricted" endpoint is a policy layered on a system that is fundamentally connected. That can be perfectly reasonable engineering — but it is a "will not," and it fails the way policies fail: a rule gets edited, a default changes, an exception is granted for a migration and never revoked. No-egress is a "cannot." The reason it holds is not vigilance; it is the absence of the mechanism itself.
No-egress is verified on your hardware, not asserted by a vendor
Here is the part that separates no-egress from a marketing adjective: it is a property of an environment you control, so you can confirm it yourself. A vendor telling you "your data never leaves" is an assertion. You checking, from inside the running deployment on your own infrastructure, that name resolution fails and no outbound route exists — that is evidence, and it is your evidence.
That is the honest posture, and it is the one Hyfstele takes across the board. We do not ask you to believe a claim about what our software will or will not do at runtime. We make the condition checkable on the machine you own. No-egress is one of four independently verifiable controls in a Hyfstele deployment — open-weight models run inside your own perimeter, air-gapped:
The model weights are proven byte-for-byte identical to the public artifact you can download yourself.
Latent and dormant capability in the model is enumerated, not hand-waved away.
The deployment has no route to the internet and no external name to resolve. Things go in, nothing comes out — and you check it on your hardware.
Every inference call is anchored to a tamper-evident audit chain signed with post-quantum cryptography (ML-DSA).
Why this matters for regulated and proprietary data
For regulated buyers the stakes are concrete. Under data-residency rules, regulated records are only permitted to exist in defined locations; a deployment with any egress path is a location you did not authorize. Under 21 CFR Part 11 and GxP, the integrity and control of electronic records is the whole game — and "we route your prompts to a service and trust it not to retain them" is a control you cannot demonstrate to an inspector. Under any model-provenance requirement, you need to know exactly what is running and exactly where its outputs can go.
No-egress answers the "where can it go" question with the strongest possible answer: nowhere. That is why it pairs naturally with the pharmaceutical MLR use case Hyfstele runs — an AI assist for Medical, Legal, and Regulatory promotional review, built on the doctrine "It flags. You decide." with a Flag → Judge → Prove flow and no LLM inside the flag decision plane. The draft claims moving through that review are exactly the kind of pre-release, competitively sensitive, regulator-scrutinized text that must never touch an outbound route. You can see the review flow at mlr.hyfstele.com.
Frequently asked questions
What is a no-egress LLM?
A no-egress LLM is a model deployment that has no route to the internet and no external name it could resolve. Prompts and documents go in and answers come out inside your perimeter, but the deployment has no network path by which any of that content could leave. The plain-language version of the doctrine is: things go in, nothing comes out.
How is no-egress different from a firewalled or restricted cloud endpoint?
A firewalled or "restricted" cloud endpoint still resolves external DNS names and still holds outbound routes; it is a policy that says traffic should not leave, layered on top of a system that physically can. No-egress removes the capability rather than restricting it: there is no external name to resolve and no outbound route to take, so there is no path for content to exit even if a policy is misconfigured or bypassed.
Why do DNS resolution and outbound routes specifically have to be absent?
Those two surfaces are the mechanism of nearly every exfiltration path. To send data out, a process needs a name to resolve to an address and a route to reach that address. If the deployment can resolve no external name and holds no route off the host, the common exfiltration paths — a compromised dependency, a prompt-injection that tries to call out, telemetry, an accidental API call — have nowhere to send anything. That is why no-egress is checked by proving those specific surfaces are absent, not by trusting that a policy forbids them.
Can I verify no-egress myself, or do I have to trust the vendor's claim?
You verify it yourself on your own hardware. No-egress is a property of the environment you control, so you can confirm it directly: attempt DNS resolution and outbound connections from inside the deployment and confirm they fail, and inspect the host's routing table and network configuration for any route off the box. Because the check runs on your infrastructure, the evidence is yours and does not depend on the vendor's word.
Why does no-egress matter for regulated or proprietary data?
Prompts to an LLM routinely contain the most sensitive material an organization has — draft promotional claims, patient or trial data, unreleased financials, classified context. If the deployment has any route out, that content is one bug or one injected instruction away from leaving. No-egress removes the path entirely, which supports data-residency requirements and controls like 21 CFR Part 11 and GxP that turn on where regulated records can and cannot go.
See the four controls on your own hardware
Hyfstele runs open-weight models inside your perimeter, air-gapped, with no-egress you verify yourself. Bring a use case and we'll walk the controls end to end.
Talk to us → Or explore the live MLR review demo at mlr.hyfstele.com