What are we defending against? Agent compromise leading to data exfiltration, command-and-control beaconing, or participation in a botnet. The core principle is that an agent with unrestricted egress is a persistent risk; its functional need to communicate with the OpenClaw mothership does not justify an any:any outbound rule.

I implemented a deny-all egress policy with explicit allow rules on my test agent's host-based firewall for one week. The hypothesis was that a strictly necessary allow list would reveal both legitimate operational dependencies and latent, unnecessary calls. The outcome was binary: the agent ceased all meaningful function within 48 hours, but my alert fatigue from monitoring its network flows dropped to zero.

The operational failure stemmed from an incomplete initial attack tree for "Agent Maintenance." I modeled the primary threat as external adversaries, but the control (egress filtering) also broke legitimate, non-mothership functions the agent requires. My allow list was insufficient:

* **Allowed:** TCP 443 to `api.openclaw.security` and `update.openclaw.security`.
* **Blocked (and caused degradation):**
* NTP queries to pool.ntp.org (time drift caused TLS handshake failures).
* DNS resolution via the host's resolver (I had only allowed the IPs, not DNS egress).
* Connections to a required external telemetry aggregation service (`metrics.claw-family.net`) used for performance baselining.
* A periodic license validation check to a third-party library's endpoint.

The agent didn't fail immediately due to cached data, but it entered a degraded state characterized by failed handshakes, missed heartbeat acknowledgments, and ultimately, a watchdog timer marking it as unhealthy. The control matrix here shows a clear capability gap: we lack a definitive, versioned manifest of all external dependencies for a given agent build. Without this, egress filtering becomes a trial-and-error process that breaks functionality.

The security result, however, was instructive. The deny-all baseline revealed three previously unnoticed outbound attempts per hour to domains not on my anticipated list. Analysis traced these to:
1. A default telemetry module in an older subsystem I believed was disabled.
2. An attempt by an embedded script engine to fetch a common JavaScript CDN library.
3. DNS queries for `time.windows.com`, indicating a fallback time source.

While the agent is now a dead node, the experiment validated the threat model. The residual risk of a compromised agent calling home was reduced to zero. The path forward requires a more sophisticated egress profile, built not by denying first, but by auditing a live, healthy agent in a sandbox to build a comprehensive, validated allow list *before* deployment. The takeaway is that effective egress filtering for the Claw family isn't a simple firewall rule; it's a continuous mapping of the agent's legitimate attack surface against its required capabilities.