Air-gap mode: 9 layers that guarantee zero network egress

"We protect your data." Every AI tool says something like this. It's in the privacy policy, in the marketing copy, in the FAQ. And for most tools, it means roughly: "We won't sell your prompts."

That's not the same as guaranteeing no data leaves your machine.

Bodega One Code's air-gap mode is a feature for people who need the stronger claim. Enable it, and 9 separate enforcement layers activate. The goal for all 9 is the same: zero bytes leave the machine during a session.

Here's what each layer does and why it exists.

Why one toggle isn't enough

An AI coding environment has more network egress paths than a chat window. Consider what a full agent can do:

• Call web search and web fetch tools
• Run shell commands (which can curl, wget, git push, or npm install)
• Check for app updates in the background
• Use a cloud speech-to-text API for voice input
• Push code to a remote git repository

A single "local mode" toggle might disable the web search tool. It won't stop a shell command from running curl. It won't stop the auto-updater from pinging our servers. Real air-gap enforcement has to cover every path. So we built it that way.

The 9 enforcement layers

Layer 1: Tool filtering

Before the agent loop starts, the available toolset is assembled. In air-gap mode, tools that make outbound requests (web_fetch, web_search) are removed from the list before it reaches the model. The AI never sees them. It can't call what isn't there.

Layer 2: Pre-execution guard

Even if a tool somehow made it through filtering, there's a second check at execution time. Before any tool runs, the executor checks the air-gap flag. A blocked call returns a clear error message to the agent explaining why it was rejected. No silent failures.

Layer 3: Shell command blocking

The shell is the most dangerous egress path in an agentic system. A shell can run anything: curl, wget, npm install, pip install, git push, git fetch. Each one can move data off-machine without the AI explicitly "making a network call."

In air-gap mode, shell commands are intercepted before execution. Commands that would initiate network traffic are blocked. The agent receives a rejection with an explanation.

Layer 4: Context assembly guard

Before each LLM call, the system assembles context from multiple sources: session history, project rules, memory entries, tool results. In air-gap mode, a guard runs over the assembled context and blocks the call if anything in it would trigger a network request.

This covers edge cases where a retrieved memory or project rule file contains instructions that could cause egress.

Layer 5: Auto-updater blocking

Electron apps check for updates. That's a background HTTP request to our update server, and it happens on a timer without any prompt or notification. In air-gap mode, the auto-updater is fully disabled. No version checks, no pings, no telemetry calls.

Layer 6: UI feedback

This isn't an enforcement layer in the strict sense, but it matters. When air-gap mode is active, it's visually indicated at all times. You should never have to guess what mode you're running in. Accountability is part of the feature.

Layer 7: Cloud STT blocking

Bodega One Code supports voice input. The default speech-to-text implementation routes audio through a cloud API. In air-gap mode, that path is blocked. Voice input is disabled unless you've configured a local STT model.

Most people don't use voice input. But the path exists and it touches the network, so in air-gap mode it closes.

Layer 8: System prompt filtering

The system prompt is assembled from several sources: your project rules, the active memory context, settings-driven instructions. In theory, any of these could contain content that instructs the model to attempt a network call.

In air-gap mode, the assembled system prompt is scanned before it reaches the model. Any content that would cause network egress is filtered out before the call is made.

Layer 9: Git IPC blocking

The IDE has full git integration: status, diff, commit history, branch management. Most of these are local operations. But push, pull, and fetch are network calls.

In air-gap mode, git operations that would initiate network traffic are blocked at the IPC bridge between the IDE and the git backend. Local git operations (commit, status, diff, log) continue to work normally.

The one thing air-gap mode can't block

If you enable air-gap mode while a cloud LLM provider is selected, you'll see a warning. Air-gap mode can intercept tool calls, shell commands, and background services. It can't intercept the HTTP request you've explicitly configured to OpenAI's API.

The warning is there to make this obvious. If you want true network isolation, use a local provider: Ollama, LM Studio, llama.cpp, or any of the other local options. Switch to a local provider and the warning disappears. At that point, the session is fully offline.

Who actually needs this

Most developers don't need air-gap mode for everyday work. If you're building a side project with a cloud provider, the standard setup is fine.

But some situations require stronger guarantees:

• Proprietary code under an NDA or IP agreement
• Healthcare or fintech work with data residency requirements
• Government, defense, or regulated industry environments
• Security research where network isolation is part of the methodology
• Anyone who wants certainty, not just a reasonable expectation, that their session stays local

For those cases, "we protect your data" isn't specific enough. You need to know what was actually blocked and why. The 9 layers give you that.

It ships with the app

Air-gap mode is a toggle in settings. It's not gated behind an enterprise plan. It's not a paid add-on. It's in the base product because we think privacy controls should be available to everyone, not just the organizations that can negotiate for them.

The beta is free and open to everyone. Download free. See the full air-gap mode overview for use cases and an FAQ, or browse all 15+ supported LLM providers. Air-gap mode works with any local provider.

Verifying it from the OS

Trust the layers, but verify them. While Bodega One Code runs with air-gap on, two single-line shell checks tell you whether the process is honoring the contract.

List open sockets owned by the Bodega process (macOS / Linux):

lsof -i -P -n | grep -i bodega

With air-gap on, the only listening port you should see is the localhost backend (loopback only). Any non-loopback ESTABLISHED or LISTEN line is a finding.

Watch for outbound DNS while you drive an agent task:

# macOS
sudo tcpdump -nn -i any 'port 53 and host not 127.0.0.1' 2>&1 | grep -v cache

# Linux (systemd-resolved bypass)
sudo tcpdump -nn -i any 'udp port 53 and not host 127.0.0.53'

Air-gap on, a full agent loop should produce zero lines. If a DNS query fires, the audit log will already have flagged the layer it leaked through; the tcpdump is a second independent check.

Windows (PowerShell):

Get-NetTCPConnection -State Established | Where-Object { $_.OwningProcess -in (Get-Process bodega*).Id }

Sources

• Bodega One Code air-gap mode overview (canonical product page, FAQ, and use cases): bodegaone.ai/air-gap
• Electron auto-updater documentation (the layer 5 surface area): electronjs.org/docs/latest/api/auto-updater
• Ollama serve documentation (localhost binding for layer 3 enforcement): github.com/ollama/ollama/docs/faq
• Setting up Ollama with Bodega One Code (the recommended local provider that pairs with air-gap mode): bodegaone.ai/blog/setting-up-ollama-with-bodega-one
• tcpdump primary reference (egress verification): tcpdump.org/manpages