MCP works in air-gapped environments because the protocol itself has no dependency on any external service; both stdio and Streamable HTTP transports operate entirely within a local machine or internal network, and an MCP server can be written to talk only to internal systems with no outbound internet call at all. The condition that actually matters is the model behind the client, since Claude Desktop and similar consumer apps are built around a cloud-hosted model and cannot function without that connection, so an air-gapped deployment needs a self-hosted model served through something like vLLM, TensorRT-LLM or NVIDIA NIM running on GPU infrastructure inside the same isolated network as the MCP servers. Before relying on a third-party MCP server in this kind of environment, it is worth checking its source code for any telemetry, update-check or license-validation call that assumes internet access, since these are easy to miss and will fail silently or noisily once the network is cut off. Building the server in-house avoids this uncertainty entirely. Nanobase AI, an NVIDIA Inception Program member, deploys exactly this kind of fully self-contained model-plus-MCP stack for customers operating in air-gapped or classified environments.
The protocol is fine offline; the model and the supply chain are not
MCP itself has no built-in dependency on the internet. Both its stdio and Streamable HTTP transports operate entirely within a local machine or an internal network, and a server can be written to talk exclusively to internal systems with zero outbound calls. The actual constraint in an air-gapped deployment is almost never the protocol; it's everything around it, starting with the model, since consumer clients like Claude Desktop are built around a cloud-hosted model and simply cannot function without that connection, making them unsuitable for a genuinely isolated network regardless of how the MCP layer is configured.
Layer-by-layer air-gap requirements
| Layer | Air-gap requirement |
|---|---|
| MCP protocol/transport | None; stdio and Streamable HTTP work entirely within a local network |
| Model | Must be self-hosted, served via something like vLLM, TensorRT-LLM, or NVIDIA NIM on internal GPU infrastructure |
| MCP server code | Must be reviewed for any outbound call (telemetry, license checks, update pings) |
| Dependencies/packages | Must be mirrored internally; no live registry access during build or runtime |
Every layer in this table needs a separate, deliberate answer; assuming one covers the others is how an air-gap deployment fails silently later.
Proving a server makes no outbound calls
Before trusting a third-party MCP server in an isolated environment, verify its offline behavior directly rather than taking the documentation's word for it:
- Review the source for any HTTP client or socket usage that isn't explicitly tied to the internal systems the server is supposed to reach.
- Run the server inside a network namespace with all outbound traffic blocked except explicitly allowed internal destinations, and watch for connection attempts that get dropped, which reveal calls the documentation didn't mention.
- Check for telemetry, update-check, or license-validation calls specifically, since these are the most commonly overlooked category and often fail silently rather than raising an obvious error.
- Repeat this check after every version update, not just on first install, since a later release can introduce a call that wasn't present in the version originally reviewed.
Dependency mirroring: the part teams forget
Even a server with zero runtime network calls typically depends on a package ecosystem, whether that's a Python package index, an npm registry, or a language-specific equivalent, and building or updating that server inside an air-gapped network requires those dependencies to be available from an internal mirror rather than the live public registry. Teams that plan carefully for the model and the server's runtime behavior sometimes still get blocked by a forgotten pip install or npm install step that silently assumes internet access, so mirroring the full dependency chain, not just the server's own code, belongs on the air-gap checklist from the start.
Frequently asked questions
Can Claude Desktop be used in a fully air-gapped network?
No, not in its standard form, since it is built around a cloud-hosted model that requires an internet connection to function at all. An air-gapped deployment needs a self-hosted model and a client or custom interface built to work entirely within the isolated network.
Is building an MCP server in-house safer than using a third-party one for air-gapped use?
Generally yes, since building in-house removes the uncertainty of auditing someone else's code for hidden network calls and gives full visibility into every dependency. It requires more upfront engineering effort but avoids repeating a network audit on every third-party update.
What model-serving stack works for air-gapped deployments?
Self-hosted serving frameworks such as vLLM, TensorRT-LLM, or NVIDIA NIM running on internal GPU infrastructure are the standard approach, since they require no external API calls once deployed. The right choice depends on the model architecture, hardware, and throughput requirements of the specific deployment.
How Nanobase AI helps
Nanobase AI deploys fully self-contained model-plus-MCP stacks for customers operating in air-gapped or classified environments, auditing every server for hidden network dependencies and building internal dependency mirrors as part of the deployment. This connects directly to our broader on-premise LLM deployment guidance and to the third-party MCP server vetting process we apply before anything reaches an isolated network.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.