Air-Gap / No-Egress Attestation

For your security & risk team. What BareMetalRT does — and provably does not do — on the network when sealed, and how to verify it yourself. BMRT_AIRGAP Egress Mode Off by default

1. The guarantee

When sealed, BareMetalRT makes zero unsolicited outbound connections. It does not phone home, check for updates, send telemetry, or contact any vendor service. Inference, your data, your prompts, and your documents never leave the machine. The only network traffic the product originates is to endpoints you explicitly configure (your own fleet nodes on your LAN, or a connector you turn on).

Sealing is off by default and can be turned on two ways: set BMRT_AIRGAP=1 in the daemon's environment (operator-set at launch), or set Egress Mode → Sealed in the app (Settings ▸ Security). Both close the same paths. Sealing is one-way from the app — there is no in-app unseal, so a user or a compromised agent cannot silently re-open the network; leaving sealed mode requires an operator to restart the node with sealing removed. A sealed box that restarts stays sealed.

2. What Egress Mode disables

The product's only autonomous outbound internet path is the in-app updater. Egress Mode closes every part of it:

Behavior (default install)	Endpoint	With `BMRT_AIRGAP=1`
Update check at boot + every 6 h	`api.github.com`	Thread never starts
On-demand "check for updates"	`api.github.com`	Served from cache; no request
Download & apply an update	GitHub release asset	Refused
Restart-time source pull (dev installs)	`git pull`	Skipped

3. Why nothing else reaches out

For completeness, here is every other place the daemon can open a socket, and why none of it is an unsolicited call home:

Licensing. Verified entirely offline with a local Ed25519 public key. No activation server, no license check-in, no phone-home — ever, in any mode.
Fleet / clustering. Node-to-node traffic (tensor parallelism, status) goes only to the peer addresses on your own LAN that you configure. A standalone box makes none of these calls. Air-gap means "no internet egress," not "no LAN" — an on-LAN cluster still works.
Cloud orchestrator (register / heartbeat / license / model token). If a box is linked to the hosted orchestrator, it keeps a relay connection and sends periodic heartbeats. Sealing unlinks it: every one of these paths is gated on the sealed flag, so on seal the heartbeat, registration, license and token fetches stop, the relay closes, and the node does not reconnect (the cloud dashboard shows it offline until unsealed). A box that boots sealed never links at all. The license path then runs fully offline against a local Ed25519 key and a manually installed license file — no activation server, ever.
Audit forwarding. If — and only if — you configure an audit sink (Splunk HEC or syslog), records are forwarded to the on-prem collector address you supply. It is off by default and never points at us.
Connectors / tools. Integrations (e.g. a SaaS connector or web fetch) only make requests when a user explicitly invokes them, to the service that connector is for. In an air-gapped deployment you simply don't enable internet-facing connectors.

4. Verify it yourself

Don't take our word for it. The guarantee is observable from outside the process. Any of these is sufficient evidence for an accreditation package:

A. Network firewall (strongest)

Deploy on a host or VLAN with all outbound internet denied at the firewall, allowing only your own LAN ranges. BareMetalRT runs normally; there is nothing to allow-list. This is the deployment an air-gapped site uses anyway, and the firewall logs are your proof.

B. Packet capture

Capture for the daemon's full lifetime (boot, idle, and a few inferences) and confirm no traffic leaves your network. On the host:

:: Seal egress (Egress Mode) and (re)start the daemon, then capture.
set BMRT_AIRGAP=1

:: Windows: log all egress that is NOT to private ranges.
:: (Run a packet capture — e.g. Wireshark/pktmon — with a display filter:)
::   ip.dst != 10.0.0.0/8 and ip.dst != 172.16.0.0/12 and ip.dst != 192.168.0.0/16
::   and ip.dst != 127.0.0.0/8
:: Expected result over the full session: zero packets.

C. Live socket inspection

Watch the daemon's established connections during a boot + 6 hour window (longer than the default update interval) and confirm none are to a public address:

:: Windows — established remote endpoints for the daemon process:
netstat -ano | findstr ESTABLISHED
::   Cross-reference the PID with baremetalrt.exe (tasklist).
::   With BMRT_AIRGAP=1: only LAN/loopback peers, never a public IP.

Control test. To confirm the flag is what's responsible, run the same capture without BMRT_AIRGAP: you'll see one outbound TLS connection to api.github.com shortly after boot (the update check). Set the flag and it disappears. That single, consent-gated, signature-pinned call is the entire difference.

5. Updating an air-gapped install

Updates are applied the way air-gapped sites always apply them — deliberately, by an operator, on your schedule:

Obtain the signed installer (BareMetalRT-<version>-Setup.exe) through your normal media-transfer process.
Verify the Authenticode signature (same publisher as your installed build) and run it silently.
The daemon never downloads or launches anything on its own in this mode.

6. Sealed boxes and agent write access

Sealing the box from the app also enables agent write access by default — the pitch is an autonomous agent that can act on local files precisely because nothing leaves the box. The two are separate settings: you can seal as a strict read-only box (agent write off), in which every side-effecting tool is refused across chat, headless runs, the process funnel, and the on-box code editor.

Because a sealed box may run an agent with write access, note the boundary that keeps the seal one-way: the sealed flag lives in the daemon's config directory (%APPDATA%\BareMetalRT), which is outside any agent workspace; the built-in editor agent is confined to its workspace root; and a restart can never clear a seal (a restarted node re-reads the flag and stays sealed). For the strictest posture, run agent tools under an OS account that cannot write the config directory, and enforce egress at the firewall (§4A) so the application gate is defense-in-depth, not the only control.

7. Scope

Egress Mode governs the daemon's autonomous outbound behavior. It does not, and is not intended to, block traffic that an operator or user explicitly initiates (enabling an internet connector, configuring a remote audit collector, joining nodes across a routed network). Enforce those with your network controls as usual. The product's role is to add no egress of its own.

Questions from a security review? This page pairs with the SSO / Identity architecture doc. Both features are off by default.