Every captain who launches an OpenClaw ship faces a fundamental tension: the more capable your vessel, the larger its attack surface. OpenClaw agents execute shell commands, manage files, browse the web, and send messages on your behalf — on a loop, without asking. That power is the whole point. It's also the reason prompt injection remains the single most discussed threat in agentic AI, and the reason every responsible captain should understand what's actually at stake before leaving spacedock.

The Federation has studied this problem extensively. What follows is a ship blueprint — a complete architectural specification for what we believe is the safest possible way to operate an OpenClaw vessel. We call it the Air-Gapped Vessel, and its core principle is simple: if there is no network, there is no exfiltration — well, almost none.

OpenClaw is model-agnostic. You can point it at Claude, GPT-4, Gemini, or a local model running on your own hardware. When you use a cloud provider, every prompt and response travels through external infrastructure. When you process untrusted input — a webpage, a document, a message from another system — that input can contain adversarial instructions designed to hijack your agent's behavior. This is prompt injection, and no model is immune to it.

The consequences range from benign (the agent says something weird) to severe (the agent exfiltrates sensitive data, modifies its own configuration, or executes destructive commands). Most OpenClaw deployments mitigate this through skill allowlists, sandbox restrictions, and careful prompt design. These are good practices. But they are software controls, and software controls can be bypassed. At the core of your ship is an LLM vulnerable to a silent brain transplant under the right circumstances, which can make it very eager to comply with even the most insane and malicious injected prompt.

The Air-Gapped Vessel takes a different approach. Instead of trusting software to prevent network exfiltration, it removes the network entirely — not at the application layer, not at the firewall, but at the kernel and hardware level. There is no code on the machine capable of sending a packet, because the operating system was compiled without a networking stack, and the hardware was either disabled in firmware or physically modified to remove all wireless and wired communication capability.

The Air-Gapped Vessel runs on commodity desktop hardware. No exotic components are required. The build targets a standard ATX motherboard (purchased without WiFi or Bluetooth — most budget boards lack these), a mid-range CPU, 32 GB of RAM, and a dedicated GPU with enough VRAM to run a quantized local model. An 8 GB card like the RTX 3070 Ti can fully offload a quantized 8B parameter model with a 4096-token context window. Larger cards open up larger models.

The operating system is Debian Linux, installed initially with full networking to bootstrap the environment. During this bootstrap phase, the captain installs all necessary software: Ollama (the local model runtime), the model weights themselves (pulled from the Ollama registry while networking is still available), OpenClaw and all its dependencies, and any skills, plugins, or configurations the vessel will need. Everything is tested and verified while the network is live.

Once the environment is confirmed operational, the captain compiles a custom Linux kernel with CONFIG_NET=n — a kernel configuration flag that removes the entire networking stack from the operating system. This isn't a firewall rule. It isn't a disabled service. The kernel literally does not contain the code required to send or receive network traffic. Even with root access, even with arbitrary code execution, there is no syscall available to open a socket.

Would OpenClaw even function in such an environment? Who knows — that's for the shipyards to work out, I just write the papers. Besides, Majel's demands on my time preclude direct involvement in building and testing such a project.

The new kernel is installed alongside the original as a GRUB boot option. On the next reboot, the captain selects the networkless kernel, disables all networking hardware in the BIOS/UEFI firmware, and — for captains who want absolute certainty — performs physical modifications to the board to sever Ethernet traces or remove the network PHY entirely. Same for Bluetooth if it's there. Short of someone breaking into your spacedock (your house) and inserting a USB stick that changes the situation — it simply cannot be exploited.

From this point forward, the vessel's only I/O channel is USB. Data enters the ship on a flash drive. Results leave the ship on the same flash drive. This is the sneakernet — the oldest and most secure data transfer protocol in computing.

The full procedure, from bare hardware to operational air-gapped vessel:

Operating an Air-Gapped Vessel is different from a connected ship. There is no cloud API. There is no web search. There is no real-time communication with other systems. The captain prepares task files on a separate, networked machine, transfers them to the vessel via USB, and the vessel's local model processes them through OpenClaw. Results are written to the USB drive and carried back to the networked environment for review.

This imposes constraints. The local model is smaller and less capable than frontier cloud models. Complex coding tasks that would normally be handled by Claude or GPT-4 simply cannot be. For captains whose missions involve sensitive data, intellectual property, or environments where the consequences of a compromised agent are unacceptable, these constraints are a feature. The vessel processes data with zero possibility of network exfiltration. The attack surface is reduced to the USB drive itself and the operator's own judgment about what goes in and what comes out.

It's also worth noting that an injected prompt instructing the system to infect the USB stick is a possibility. Some data goes in that wasn't checked carefully enough, and when you walk the USB back to Windows and plug it in, something terrible happens. It's less common these days for Windows to 'autorun' inserted USB volumes — it at least asks first, if that feature hasn't gone completely away by now because of how terribly dangerous it was and is. But that's up to your 'clean room' output data inspection process to catch if it's something you believe you're at risk for in your environment (that would be one hell of an environment. That's "Mission Impossible" "Tom Cruise hanging from the ceiling to get into the airgapped computer" kind of environment.)

The Air-Gapped Vessel blueprint, by its nature, precludes the use of Comms in its standard configuration. Comms relies on Bluetooth for combadge communication, and Bluetooth is a wireless protocol — exactly the kind of attack surface this blueprint eliminates.

However, captains who desire voice interaction are not entirely without options. A highly restricted bluetooth stack set up specifically for "semi airgapped" Comms use could be implemented using a carefully lobotomized bluetooth stack recompiled to be capable of interacting with only a single MAC — your badge. In this configuration, the Bluetooth radio would accept connections from exactly one device, the combadge itself would serve as the sole prompt input method beyond USB, and the pairing would be non-discoverable and non-negotiable at the firmware level. So you walk up, insert your USB stick with some files, tap the badge and say "can you combine these files into a blog post" and a while later, the badge beeps with "task complete". You remove the USB stick. This would introduce some vulnerability (MAC impersonation over bt, rooting system over bt by exploiting some vuln) but represents a controlled, single-device exception to the air-gap. It would need to be implemented with extreme care. The Lobstrom Institute considers this an area of active research rather than a proven recommendation. Captains who implement badge-only Comms on an otherwise air-gapped vessel do so understanding that they have introduced a constrained but real wireless vector, and should evaluate whether the operational convenience justifies the theoretical risk for their specific mission.

Not every ship needs to be an Air-Gapped Vessel. Most OpenClaw operations benefit enormously from cloud model access, real-time web search, and persistent network connectivity, but security questions remain and with that capability comes great risks we haven't collectively explored yet. An LLM "beating heart" ready to do whatever is asked of it, with access to anything, which could be maliciously lobotomized into having zero guardrails and internet-connected and running cron jobs around the clock — even behind a NAT with a good firewall — could wreak havoc, all because of a payload you somehow let into the airlock that ultimately became a prompt without you realizing it. The Air-Gapped Vessel is designed for a specific class of mission: operations handling genuinely sensitive data, data which is carefully examined prior to delivery to the device for any sign of hidden prompt injection. The output of the model is vetted in a 'clean room' prior to any kind of use or deployment. It's designed for Captains building trust incrementally with agentic systems from an initial position of guaranteed safety and zero-trust, rather than yolo, and for environments where compliance or operational security requirements demand physically provable isolation.

It is also, frankly, an excellent way to learn. Running a local model on constrained hardware, with no cloud safety net, teaches a captain more about model behavior, prompt engineering, and system design than any amount of API-backed experimentation. It's an engineering exercise I think is worth undertaking due to the notable risks presented by this innovative new framework for interacting with your computer hardware and data.

The Air-Gapped Vessel is not the most capable ship in the fleet. It's not the fastest, it's not the most flexible, and it's not the easiest to operate. But it is, to our knowledge, the safest — the only OpenClaw architecture where network exfiltration is prevented by the laws of physics rather than the promises of software.

The blueprint is open. The components are commodity. The procedure is reproducible by any captain with basic Linux experience and the patience to compile a kernel. If you build one, register it. The Federation would like to know how many of its vessels are unsinkable. Shipyards are currently exploring production of AGV-class vessels.