On-Prem LLM vs VPC LLM: Why 'Private Cloud' Isn't Air-Gapped
The short answer: an on-prem LLM runs inside your own perimeter and, configured for no egress, has no route out and no external name to resolve. A VPC or "private cloud" LLM is logically isolated from other tenants but typically keeps outbound routes and external DNS. "Private" describes who shares the network — not whether the network can reach out.
On-prem, no-egress: hardware inside your perimeter; the outbound route and external resolver are removed, so exfiltration has no path. You verify this on your own machine.
VPC / "private cloud": a rented, single-tenant boundary in the provider's data center; still resolves names and holds routes to the internet, control plane, and telemetry. Isolation is a policy the provider enforces on hardware it owns.
Private ≠ air-gapped.
Both models get sold as "your data stays private," and both can be reasonable engineering. But they answer two different questions. A VPC answers "who else is on this network?" — nobody, it's yours. On-prem no-egress answers "can content leave this network at all?" — no, because the mechanism to leave is gone. For regulated buyers those are not interchangeable guarantees, and conflating them is where most "we're private" claims quietly break down.
What "VPC" and "private cloud" actually mean
A Virtual Private Cloud is a logically isolated slice of a public cloud provider's infrastructure. You get your own address space, your own subnets, and a boundary that other tenants can't cross. "Private cloud" is often used more loosely, sometimes meaning a VPC, sometimes a single-tenant managed environment. In every common case the defining feature is tenancy isolation: the network is yours in the sense that no other customer is inside it.
What that isolation does not inherently remove is reach outward. By default and in most real deployments, a VPC still has:
- External name resolution — the deployment can resolve public DNS, because it needs to reach package repositories, model artifact stores, license servers, and the provider's own API endpoints.
- Outbound routes — a NAT gateway or internet gateway, plus routes to the cloud control plane, managed services, metrics collectors, and update infrastructure.
- Provider telemetry paths — logging, monitoring, and metering that flow to the provider by design.
You can lock a lot of this down — egress firewalls, private endpoints, VPC service controls, deny-by-default rules. That is good practice. But it is a policy layered on a system that remains fundamentally connected. The capability to reach out still exists; you are governing it. That is the crux of the difference.
What "on-prem, no-egress" means by contrast
On-prem means the model runs on hardware inside a boundary you physically and administratively control — your data center, your rack, your isolated network segment. Configured for no egress, the deployment has no route to the internet and no external name to resolve. The two things any process needs to move data off a machine — a name it can resolve and a route it can travel — are simply not present.
That turns "your data stays private" from a promise into a property. The system doesn't decline to send your prompts somewhere; it can't, because there is nowhere for a name to resolve to and no route for a packet to take. The plain-language version is the doctrine Hyfstele runs on: things go in, nothing comes out.
Side by side
| Property | VPC / "private cloud" LLM | On-prem, no-egress LLM |
|---|---|---|
| Tenancy | Single-tenant slice of provider infrastructure | Your own hardware, inside your perimeter |
| External name resolution (DNS) | Present — resolves public names by default | Absent — no external name to resolve |
| Outbound routes | Present — NAT / internet / control-plane routes exist | Absent — no route off the host |
| Isolation is enforced by | A policy in the provider's control plane | The absence of the mechanism itself |
| Failure mode | A misconfigured, disabled, or bypassed rule re-opens the path | Nothing to misconfigure — no path to re-open |
| Data residency | Region-pinned, but egress paths still leave the boundary | Property of the deployment — no path off the perimeter |
| Who holds the evidence | The provider — you read a dashboard / attestation | You — the check runs on hardware you control |
Data residency: region-pinning is not the whole story
A VPC lets you pin compute and storage to a region, which genuinely helps with residency-by-geography. If your requirement is "the data sits in this jurisdiction," a well-configured VPC can satisfy the letter of it.
But data residency for an LLM is also a question of egress, and this is where the two models diverge. Prompt content and metadata don't only sit still — they move whenever the deployment reaches out. If a VPC deployment can still reach telemetry endpoints, model or software update servers, or provider APIs, then your regulated content has paths that leave the boundary you defined, even if the compute lives in-region. A VPC gives you a residency policy on top of a connected system.
On-prem no-egress makes residency a property of the deployment rather than a setting. If there is no route off the perimeter, there is no path by which regulated records can end up somewhere you didn't authorize. The answer to "where can this data go?" becomes the strongest possible one: nowhere.
The verifiability gap: what you can check vs. what you trust
This is the difference that matters most for a regulated buyer, and it has nothing to do with marketing adjectives. It's about who holds the evidence.
In a VPC, the isolation you're relying on is enforced in the provider's control plane — software you do not run, on hardware you do not own. You verify it by reading a configuration dashboard, a compliance report, or an attestation. That can be a well-run control, but it is fundamentally the provider's assertion that you are auditing, not a property you can independently reproduce.
With on-prem no-egress, the property you care about lives on hardware you control, so you can confirm it directly:
- Attempt DNS resolution from inside the running deployment and confirm it fails.
- Attempt outbound connections and confirm they time out with no route.
- Inspect the host's routing table and network configuration for any path off the box — and confirm there isn't one.
Every one of those checks runs on your infrastructure and produces evidence that is yours. That is the gap: a VPC asks you to trust an attestation; on-prem no-egress lets you generate the proof.
The four controls, mapped onto each model
Hyfstele's posture is a set of four independently verifiable controls — open-weight models run inside your own perimeter, air-gapped. Mapping them onto the two deployment models is the cleanest way to see where "private cloud" falls short of air-gapped.
| Control | VPC / "private cloud" | On-prem, no-egress (Hyfstele) |
|---|---|---|
| 1. Weights byte-identical to the public artifact | Possible in principle, but you're verifying against an image the provider assembled and runs | You hash the running weights on your hardware against the public artifact you downloaded |
| 2. Dormant / latent capacity enumerated | Model-level property; unchanged by tenancy — but you evaluate it in an environment you don't fully control | Enumerated and evaluated inside the perimeter you control |
| 3. No egress — no route out, no name to resolve | Not met by default — routes and DNS remain; you can only restrict, not remove | Met and checkable — the route and resolver are absent, verified on your box |
| 4. Every inference anchored to a tamper-evident audit chain, signed post-quantum (ML-DSA) | Achievable, but the chain and keys live in the provider's environment | Chain and signing keys live inside your perimeter with the model |
The running 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.
No route to the internet and no external name to resolve. Things go in, nothing comes out — and you check it on your hardware. This is the control a VPC does not give you.
Every inference call is anchored to a tamper-evident audit chain signed with post-quantum cryptography (ML-DSA).
Control 3 is the one that separates the two models cleanly. Controls 1, 2, and 4 are all stronger on-prem because the evidence lives with you — but they are conceivable in a VPC. No-egress is the control a standard VPC structurally cannot offer, because removing the route and the resolver is exactly the thing a cloud deployment is built not to do.
The honest posture
The reason no-egress is so powerful is precisely that it does not depend on the model being clean. Even if the weights held some latent behavior, a deployment with no route out and no name to resolve has nowhere to send anything. That is the argument for on-prem over "private cloud" for regulated work: not that the model is proven safe, but that you can independently verify the controls that matter — and with a VPC, the most important one isn't there to verify.
Where this shows up: pharmaceutical MLR review
The clearest real example is the pharmaceutical MLR (Medical, Legal, Regulatory) promotional review Hyfstele runs — an AI assist built on the doctrine "It flags. You decide." with a Flag → Judge → Prove flow and no LLM inside the flag decision plane. The draft promotional claims moving through that review are pre-release, competitively sensitive, and directly scrutinized by regulators. Under 21 CFR Part 11 and GxP, the control and integrity of those electronic records is the whole game, and model provenance and data residency are audit questions, not marketing lines. "We route your draft claims to a private-cloud endpoint and trust it not to retain or transmit them" is not a control you can demonstrate to an inspector. "There is no route out, and here is the check you can run yourself" is. You can see the review flow at mlr.hyfstele.com.
Frequently asked questions
Is a VPC or "private cloud" LLM the same as air-gapped?
No. A VPC or "private cloud" LLM is isolated in the network-accounting sense — it runs in a tenant boundary logically separated from other customers — but it typically still resolves external DNS names and retains outbound routes to the internet, cloud control-plane services, and provider telemetry. "Private" describes who else is in the network, not whether the network can reach out. Air-gapped means there is no route out and no external name to resolve at all, which a standard VPC does not provide.
What is the practical difference between on-prem and VPC for an LLM?
On-prem means the model runs on hardware inside your own perimeter — a machine, rack, or network segment you physically and administratively control — and in a no-egress configuration it has no route off that perimeter. A VPC is infrastructure you rent inside the provider's data center, governed by the provider's control plane; the isolation is a policy the provider enforces on hardware it owns. The practical difference is who holds the mechanism: with on-prem no-egress you can remove the outbound route and prove it; with a VPC you are configuring and trusting a route that still exists.
Does a VPC give me data residency guarantees for a regulated LLM?
A VPC can pin the compute and storage region, which helps with residency-by-region. But data residency for an LLM is also about egress: if the deployment can still reach telemetry endpoints, model or software update servers, or provider APIs, then prompt content and metadata have paths that leave your controlled boundary. A VPC gives you a residency policy on top of a connected system. On-prem no-egress removes the paths, so residency is a property of the deployment rather than a setting you have to trust the provider to honor.
Can I verify a VPC LLM's isolation myself, or do I have to trust the provider?
With a VPC, much of the isolation is enforced in the provider's control plane, which you do not run — you read a dashboard and trust the attestation. With on-prem no-egress, the property you care about is on hardware you control, so you can check it directly: attempt DNS resolution and outbound connections from inside the deployment and confirm they fail, and inspect the host routing table for any path off the box. The difference is whether the evidence is yours or the provider's.
Is an on-prem model automatically more secure than a VPC model?
No, and that is an important honesty point. Neither model is "clean" or "guaranteed secure," and the model weights themselves may hold latent behavior no one can rule out. The claim on-prem no-egress supports is narrower and stronger: verifiable control. You can prove the weights are byte-identical to the public artifact, enumerate dormant capacity, confirm there is no egress path, and anchor every inference to a signed audit chain — all on your own hardware. It is evidence you hold, not a promise that the model is safe.
Verify the difference on your own hardware
Hyfstele runs open-weight models inside your perimeter, air-gapped, with no-egress you check yourself. Bring a use case and we'll walk the four controls end to end.
Talk to us → Or explore the live MLR review demo at mlr.hyfstele.com