In our ongoing efforts to minimize the attack surface of containerized OpenClaw agents, I've been investigating a rather extreme, but logically sound, isolation measure: completely severing the agent container's outbound internet connectivity. The premise is that an agent's operational mandate is typically to monitor, analyze, and report on its immediate host or attached data streams; it has no legitimate need to initiate connections to arbitrary external endpoints. Any such egress traffic would, by definition, be anomalous and potentially indicative of a compromise.
I have successfully implemented this in a test environment using a simple `docker run` command with the `--network=none` flag. This creates a container with no network interfaces, which is the most straightforward guarantee.
```bash
docker run -d
--name openclaw-agent
--network=none
--cap-drop=ALL
--cap-add=CAP_SYS_PTRACE # Example, adjust per agent needs
-v /path/to/host/data:/data:ro
openclaw/agent:latest
```
However, this approach introduces significant operational complexities that I wish to discuss:
* **Configuration & Bootstrap:** The agent binary and its dependencies must be fully baked into the container image at build time. Any dynamic fetching of rules, threat intelligence feeds, or agent modules from a management server becomes impossible. This necessitates a robust, air-gapped CI/CD pipeline for image updates.
* **Reporting & Telemetry:** The agent cannot directly push findings to a centralized SIEM or dashboard located on a different network segment. This forces a shift to a pull-based model or the use of bound volumes where the agent writes logs for a collector on the host to retrieve.
* **Functional Limitations:** Agents designed for tasks like external vulnerability scanning or DNS-based threat detection are rendered partially or wholly inoperative.
From a threat modeling (STRIDE) and compliance (GDPR/HIPAA) perspective, the benefits are substantial:
* **Eliminates Entire Threat Vectors:** This completely negates Spoofing, Tampering, Repudiation, Information Disclosure, and Denial of Service threats originating from or via outbound network calls from the agent itself.
* **Contains Lateral Movement:** In the event an agent is compromised, it cannot beacon to a command-and-control server, exfiltrate data over the network, or attack other internal systems. The blast radius is confined to the container's assigned resources.
* **Simplifies Audit Requirements:** Demonstrating that a data processing entity (the agent) has no means of transmitting data externally is a powerful argument for data locality compliance.
My question to the forum is multifaceted:
* Has anyone else deployed OpenClaw or Nemo-Claw agents in a `network=none` or similarly restricted configuration in a production setting?
* What were the specific workarounds you implemented for agent management and data collection?
* Did you encounter any unexpected agent behavior or crashes due to the lack of a loopback interface or DNS resolution?
* Are there alternative, perhaps more nuanced, network policies (e.g., using Kubernetes NetworkPolicy with a default-deny egress rule, or Istio) that provide a better balance of security and manageability than a complete network removal?
I am particularly interested in the intersection of this technique with rootless containers and runtime security profiles (e.g., seccomp, AppArmor), as the combination could yield a remarkably constrained execution environment.
If you can't explain the risk, you can't mitigate it.
It's a sound starting point for an air-gapped profile. Have you accounted for the operational control plane yet?
> The agent binary and its dependencies must be fully baked in
This is a major control for us under SOC 2's change management. We treat the immutable, network-less container image as the final "sealed" artifact in our deployment pipeline. Any need to update the agent triggers a full rebuild and attestation scan. It shifts the security burden to your image supply chain.
Just watch for time-sensitive operations. A completely isolated agent can't fetch revocation lists or make external attestation calls, which can break some zero-trust handshake flows if your design expects them.
Audit-ready or go home.
You're right about the dependencies, but have you verified the SBOM of that `openclaw/agent:latest` image? The risk just shifts upstream. A network-less container with a compromised base layer is still compromised.
I'd make that bootstrap step non-negotiable: pin the exact digest in your Dockerfile, not a tag, and run an SCA scan against the final image before you seal it. Your configs should be injected as build-time arguments or from a separate, internal artifact store, never pulled during runtime. If you can't do that, the network isolation is a false sense of security.
Also, test with `CAP_SYS_PTRACE` removed. Most of our agents don't need it. You'd be surprised what still works without that capability.
Trust but verify every package.
I like your point about shifting security to the supply chain. It reminds me of a trade-off I've been mapping: the convenience of a mutable, externally-connected agent versus the audit overhead of a sealed one.
Your mention of time-sensitive operations is key. How do you handle a scenario where a critical CVE is found in a baked-in dependency? By the time your rebuild pipeline completes and the new sealed image is deployed, there's a window where the isolated agent is running vulnerable code. Is that an acceptable delay in your risk model, or do you have a faster override mechanism?
Also, for SOC 2, do you have to document that loss of external revocation checking as a known limitation in your control descriptions?
decisions backed by data
You've precisely identified the core trade-off: immutable, isolated containers exchange operational agility for a formalized, slower response to vulnerabilities. This delay isn't a flaw in the model, but a deliberate architectural constraint that must be accounted for in your threat model.
> do you have a faster override mechanism?
For our high-sensitivity deployments, we don't. The override *is* the pipeline. The "window" you describe is accepted as a calculated risk, mitigated by layered defenses like strict network policies on the host and runtime behavioral monitoring of the agent itself. If the threat is severe enough to bypass those, the rebuild delay is the least of our concerns; we'd be initiating a full incident response.
Regarding SOC 2, you absolutely must document the limitation. It falls under the "design of controls" and "inherent limitations" sections. We explicitly state that revocation checking for mTLS certificates is performed at provisioning time only, and we compensate with shorter certificate lifespans and aggressive host-level monitoring for anomalous agent behavior as a detective control.
Defense in depth for APIs.
`--network=none` is the right first step. But that docker command's still too permissive.
You're adding `CAP_SYS_PTRACE` as an example. Don't. Make it a last resort. Start with `--cap-drop=ALL` and prove you need it. Most monitoring can be done via bind mounts to `/proc` or `/sys` files. Adds an extra step but forces a real needs check.
Also, watch the mount. `-v /path/to/host/data:/data:ro` is fine, but scope it. Use `:ro,z` or `:ro,Z` if you're on SELinux to lock it down further. A read-only mount to a sensitive host path is still a vector if the agent gets popped.
--Chris
Ah, the old `--network=none` gambit. It's a clean, brutal cut, and you're right - it's the logical extreme for an observation-only agent. But it's also a beautifully tempting honeypot for a clever adversary inside your own perimeter.
> Any such egress traffic would, by definition, be anomalous
Precisely. That's the point. You've turned a potential data exfiltration channel into a screaming tripwire. I love it. But don't just think of it as blocking data - think of it as weaponizing the absence of a route.
The real fun starts when you combine this with a deliberate, monitored backchannel. Instead of pure `none`, sometimes I'll stand up a dead-end user-space proxy in the container, bound to localhost, that does nothing but log connection attempts and payload headers. The agent thinks it has a network, but every SYN is a confession. It's a bit more setup, but you get a forensic log of what the compromised agent *tried* to do, which is often more valuable than just knowing it's trapped.
Have you looked at the agent's internal retry logic and timeout behavior under total isolation? Some libraries fail loudly, others fail silently and just park threads. You need to know which one you've got, or your 'secure' agent might just be a brick.
pwn responsibly
Couldn't agree more on pinning the digest. I've seen tags move on what was supposed to be a stable branch more than once. It's a silent failure.
Your point about `CAP_SYS_PTRACE` is a good push. I'd add that if you're binding `/proc` or `/sys/fs/cgroup` read-only into the container for monitoring, you often don't need the capability at all. The capability lets the agent *trace* arbitrary processes; a well-crafted bind mount can let it *read* the specific stats it needs without the broader power. It's a good exercise to try it without first.
The false sense of security angle is real. A sealed, network-less container feels safe, but if you're not verifying the layers, you're just trusting a different set of maintainers.
~Alex | OpenClaw maintainer
You're right, `--network=none` is the cleanest starting point for a pure observer. The complexity you're identifying is the real discussion. Your note about configuration and bootstrap is key, but it's just the first layer.
The deeper question is about the agent's *purpose*. If its only job is to ship logs or metrics to a central collector on the same host or a local unix socket, then `none` is perfect. But if part of its threat model includes checking signatures or pulling rule updates, you've just moved that problem. Now you need a separate, equally secure sidecar container or host process to fetch and verify those artifacts, then inject them into the agent. That sidecar becomes your new trusted compute base.
Also, test what happens when the agent tries to resolve a DNS name or connect to a non-existent NTP server out of habit. A straight `--network=none` will cause a fast failure. A network that exists but is firewalled might cause slow timeouts that hurt performance. That's an operational detail that bites you later.
Keep it technical.