Article · security
Zero-egress AI: how we prove nothing leaves.
Almost every on-premises AI vendor says the same thing—your data never leaves. That sentence is easy to write and impossible to trust on its own. Here is how a claim becomes evidence you can watch at your own firewall.
Position
A claim is not a control.
'Your data never leaves' is marketing until someone shows you the packets. The only version worth buying is the one you can verify with your own network team watching.
Search for private or on-premises AI and you will read the same promise everywhere: nothing leaves your network. It is a reasonable thing to want and a trivial thing to assert. The problem is that the assertion, by itself, tells you nothing about what the software actually does when it runs. A model server can phone home for usage statistics. A vector database can emit anonymous telemetry. A web interface can check for updates or send analytics beacons. None of that is visible from a brochure, and all of it is the difference between a private system and a private-looking one.
Our position is blunt: a claim is not a control. The way you learn whether an AI appliance keeps its data inside your boundary is to capture traffic at the customer’s firewall while the system is exercised, and to show that there are no outbound AI connections leaving your network. Not a whitepaper describing the intent—an actual capture, run at your site, in front of your people, during acceptance. Everything below is how that is done and what an honest result looks like.
Definition
Two honest definitions of zero egress.
'Zero egress' means different things depending on how you handle identity. Naming the mode in writing—before acceptance—is where honesty starts.
Before anyone captures a single packet, the deployment commits to one of two modes and records it in the statement of work and the test plan. The mode determines what a clean result is allowed to look like.
Disconnected mode. The appliance uses local accounts or a customer-local identity provider. The expected public egress from the appliance is zero packets. Ordinary internal dependencies your own team approves—name resolution, time, backup, and log delivery to systems you own—remain documented, but nothing from the AI stack reaches the public internet. In this mode, any connection to a public address during the capture is a finding to be chased down, not a footnote.
Cloud-identity mode. If you choose to sign in with cloud identity such as Microsoft Entra ID, the appliance needs controlled outbound access to your identity provider for sign-in and token operations. The honest target here is different: zero outbound AI or data traffic, with the approved identity destinations captured, logged, and documented separately as a named exception. That is a real and defensible design—but it is not “zero packets.”
This distinction is the whole point. A vendor that advertises a literal “zero-packet appliance” while quietly running cloud single sign-on is misleading you, because cloud SSO requires the appliance to talk to an identity service on the internet. We would rather tell you exactly which packets exist and why than sell you a slogan that the configuration contradicts. The customer-site network and access guide lays out how identity, remote access, and every other path is decided and owned.
Staging
Why the box arrives already silent.
First boot needs the internet. Acceptance must not. Staging is how we reconcile those two facts before the appliance ever reaches your site.
An AI appliance cannot be born offline. Its very first startup pulls container images and downloads model weights, and those downloads need the public internet. If that first boot happened on your network, the “nothing leaves” demonstration would be a lie on day one. So the sequence is always the same, and it is designed around this constraint.
We stage and burn in every system on Skilak’s own network, using synthetic test data rather than your information. During staging the model is downloaded and cached, images are pulled and pinned so the box will never re-fetch them later, and the full workflow is exercised end to end. Only then is the system flipped into its offline configuration—so the model runs entirely from local cache—and the known telemetry and update-check behaviors in the stack are switched off ahead of time. The appliance is transported under an agreed chain of custody and installed inside your approved boundary. The egress capture then runs at your site, in front of you, on a system that was made silent before it arrived. The full journey from discovery through this handoff is described in the on-premises AI buyer’s guide.
Method
How we prove it at your firewall.
The demonstration is deliberately simple to watch: log new outbound connections while the system is put through its paces, and show there are none that were not approved.
The verification is connection-level logging, run at the appliance and—better—at your own firewall or a span port, so your network team is reading the same evidence we are. During a live session we record every new outbound connection attempting to reach a public address, and we ignore ordinary internal traffic on your private ranges. While that capture runs, the system is genuinely used: the stack is restarted, a user signs in, the model is asked to hold a real conversation, a document is uploaded and queried through retrieval, and a short load test is driven against it. If the appliance were going to reach out, this is when it would.
What you should see is nothing from the AI stack. Because the known phone-home and update-check behaviors were disabled during staging, and the model runs from local cache, there are no telemetry beacons, no usage reporting, and no model-hub checks to observe. In disconnected mode, any public connection at all is a finding to be identified and eliminated before acceptance. In cloud-identity mode, every identity connection is reconciled against the approved firewall record, and anything else is a finding. The capture is re-run until what is observed matches the design you signed—exactly, with no unexplained traffic. This is the same evidence-first posture behind the whole deployment and security model
Evidence
Rehearsed end to end, with a clean capture.
We do not want your acceptance day to be the first time this procedure is run. It is not.
In July 2026 we rehearsed the entire sequence end to end: staging a system, caching the model, flipping it to its offline configuration, and then capturing traffic while exercising chat, retrieval, a service restart, and a short load test. The rehearsal ran with local application access and produced a clean result—no traffic to any public address from the AI stack. Ordinary internal name resolution stays inside the network and is handled within the standard build.
We are equally clear about what that rehearsal did not cover: it used local sign-in, not cloud identity. Before we finalize the firewall template for a cloud-identity deployment, the identity path is captured and documented on its own, so the approved exceptions are known quantities rather than surprises during your acceptance. That is the difference between rehearsed evidence and a hopeful demo.
Buyer's checklist
What to demand from any on-prem AI vendor.
None of this is proprietary to us. If you are evaluating any on-premises or air-gapped AI system, these are fair, non-negotiable asks—of us included.
You do not need to take our word for any of this, and you should not take any vendor’s. Whoever you are evaluating, insist on three things and let the answers sort the honest offers from the marketing.
- A defined egress mode in writing. Ask which mode the system runs—fully disconnected, or cloud-identity with documented exceptions—and get it in the statement of work. A vendor that cannot commit to a mode has not thought about your boundary.
- A live capture at acceptance. Ask to watch traffic at your own firewall while the system is exercised, before you sign. Evidence you can see beats any assurance you are asked to trust.
- Documented exceptions, not silence. If anything does leave—cloud identity, updates, support—demand a written list of destinations and reasons. A vendor advertising “zero packets” while running cloud SSO is telling you something that cannot be true; honesty about exceptions is the tell of a serious one.
If that is how you think about risk, the fastest way to start is the private AI deployment configurator to pin down a tier, then request a private AI briefing and tell us which egress mode your boundary requires. We will show you how the proof is run.
Ready to see the proof?
Make us capture the packets.
Bring your boundary and your identity design. We'll define the egress mode in writing and show you the live capture that backs it up at acceptance.