Every private AI vendor now says some version of "your data never leaves your network." It is a good claim. It is also one of the easiest claims in the industry to make and one of the least often checked.
I build and deploy this category of system for a living, so this is not a neutral post. But the test procedure below is vendor neutral, it runs in an afternoon, and it works just as well pointed at my product as at anyone else's. If you are evaluating a self-hosted AI knowledge base, RAG platform, or internal assistant, this is the part of the evaluation that nobody does and everybody should.
"Zero egress" is three separate claims wearing one coat
When a vendor says zero egress, they could mean any of these, and the gap between them is where the surprises live.
The inference path. Your prompts and your retrieved document chunks are not sent to a third party model API. This is the claim people think they are buying. It is also the one most likely to be true, because it is the headline.
The data plane around inference. Embeddings, reranking, OCR, speech to text, document parsing, image description. A system can run the chat model locally and still ship every page of every indexed document to a hosted embedding endpoint. If your document set is the sensitive thing, and it usually is, this path leaks more than the chat path does.
The control plane. Telemetry, crash reporting, usage analytics, license check-in, auto-update, model pulls, container registry pulls, DNS, NTP. None of this is your document text. All of it is metadata about your environment, and some of it is a live outbound channel into your network that you did not deliberately open.
A product can be entirely honest about the first claim and still fail the second and third. Ask about all three separately, in those words, and watch which ones get a crisp answer.
The paths that actually leak
From evaluating and building these stacks, this is the list I work through. None of it is exotic. All of it has shown up in real deployments of real products.
- Hosted embedding models. The most common one. Local chat model, remote embeddings. Ask specifically: what model generates the vectors, and where does it run.
- Sidecar services. OCR, transcription, and layout parsing are often the piece a vendor did not want to build, so they called an API. If the product ingests scanned PDFs or audio, ask what handles them.
- Reranking. Same story, one layer down the retrieval pipeline, and easy to miss because it only fires on queries, not on ingest.
- Error and crash reporting. A Sentry-class SDK will happily transmit stack traces containing prompt fragments, file paths, usernames, and query strings. This is usually an oversight rather than a design, which does not make it better.
- Product analytics. Event streams with document counts, seat counts, feature usage, and sometimes query text for "search quality improvement."
- License and entitlement check-in. A phone home on a timer. Often the hardest thing to remove, because the business model depends on it, and often the thing that silently breaks an air-gapped install thirty days after it worked fine.
- Runtime model and dependency fetching. If model weights are downloaded on first run instead of baked into the image, you have an outbound dependency and a supply chain question at the same time.
- DNS. Even with egress blocked at the firewall, if the resolver is upstream then hostname lookups still describe your internal traffic to whoever runs that resolver. DNS query logs are the highest signal per unit of effort in this entire test.
- Outbound integrations you turned on yourself. Email notifications, webhooks, chat alerts, SSO to a cloud identity provider, connectors to SaaS sources. These are legitimate and deliberate. They are still egress, and they belong on the diagram.
How to test it in an afternoon
You do not need a lab. You need one host, a packet capture, and a representative workload.
Step 1: default deny, and log the drops. Put the deployment behind an egress policy that denies everything outbound and logs every denied packet. Do not start with allow-and-observe. Start denied, then read what screams. On Linux, an nftables or iptables OUTPUT chain with a log target on the drop rule is enough. The log is your finding list.
Step 2: check the container network topology before you trust anything else. If it ships as containers, inspect the network the AI services actually attach to. A bridge network created in internal mode has no gateway and no route out, which is a structural property you can verify in one command rather than a policy someone has to keep enforcing. Confirm which services sit on which network. The interesting finding is usually a single service that is on both.
Step 3: sinkhole DNS and read the query log. Point the deployment at a resolver you control that answers everything with a black hole address and logs every query. Then run a full workload. The query log is a plain text list of every remote host the software wanted to reach, including the ones the firewall already blocked and the ones that fail silently. I have never run this test and learned nothing.
Step 4: run a representative workload, not a smoke test. Index a real document set with real file types, including a scanned PDF and something with an embedded image. Ask twenty questions, including one that returns no good answer, because error paths are where crash reporters fire. Upload a document through the UI. Log in and out. Have an admin change a setting. Let it sit idle overnight, because timers are the point of the whole exercise.
Step 5: capture the traffic, not just the logs. Run a packet capture on the host interface for the whole window. Then look at what remains after you filter out your own management traffic. You are looking for TLS handshakes to hosts you cannot explain, and you are looking at timing, because a beacon on a fixed interval is a beacon regardless of what is inside it.
Step 6: pull the cord. Remove the default route entirely and repeat the workload. Write down what breaks and how it breaks. Good behavior is full feature parity, or a clear degradation on a documented feature. Bad behavior is a hang, a silent failure, or a licensing error two days later. If a vendor says the product supports air-gapped operation, this test either confirms it in an hour or ends the conversation early, which is also a good outcome.
Step 7: ask how the isolation is enforced, not just whether it holds today. The result you got is a snapshot of one build. The question that matters for the next three years is whether isolation is verified automatically on every build, or whether it was verified once by a person who has since moved teams. A vendor who can describe an automated check in their release pipeline is telling you something structurally different from a vendor who can only describe an architecture diagram.
Questions that are hard to bluff
Send these before the demo. The answers, and how fast they come back, tell you most of what you need.
- Which components make outbound network calls at any point in normal operation, including timers and background jobs?
- Where do embeddings get generated, and by what model?
- What handles OCR, transcription, and document parsing?
- Is telemetry present, can it be disabled, and does disabling it stop the process or only stop the transmission?
- Does licensing require a periodic check-in, and what happens on day thirty with no route out?
- Are model weights and dependencies present in the artifact you ship, or fetched at first run?
- Is network isolation asserted in your release pipeline on every build, and what exactly does that check assert?
- What is the complete list of hostnames the product would resolve in a month of normal use?
That last one is my favorite. A vendor who has genuinely built for isolation can answer it from memory or from a config file. A vendor who has not will need to go ask engineering, and the delay is the answer.
Where our own product lands on this
Adaptive Reservoir is a private AI knowledge platform that runs on hardware you own, on premise or in your own cloud account. It exists because the alternative most companies pick is banning AI outright and eating the productivity loss.
Against the checklist above: the AI runs on an internal-only container network with no route to the internet, and that isolation is asserted by an automated release gate on every build rather than only claimed in documentation. It runs with no internet connection at all. There is no cloud account, no external API key, and no per-token bill, because the model runs on your hardware. The target footprint is a single Linux host with an NVIDIA GPU, and 16 GB of GPU memory is the practical sweet spot. Answers cite the documents and decisions they came from, which is its own small audit property: a citation you can open and read is a retrieval path you can verify by hand.
The honest caveat, because a post about verifying claims should not hide behind its own. Reservoir offers optional connectors that pull AI activity from platforms you already use, through each vendor's official compliance API. Those connectors are outbound by definition. They are scoped, they are something you choose to enable, and they belong on your network diagram in a different color from the inference path. Any vendor telling you their product has literally zero outbound sockets under every possible configuration is describing marketing, not networking.
Base pricing starts at $395 per month and scales with deployment size and the optional modules you turn on. Details at adaptiveips.com/adaptive-reservoir.
Run the test
The point of this post is not the product. The point is that "your data never leaves" is a testable assertion, and almost nobody tests it. A DNS sinkhole, a default deny rule, and a representative workload will tell you more in one afternoon than a security questionnaire will tell you in six weeks.
Run it against whatever you are evaluating. Including ours.
Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm, and we build Adaptive Reservoir.
