Hey folks. I've been running various Claw agents in my homelab for a while now, and the biggest headache for me hasn't been the agents themselves—it's been designing and maintaining the firewall rules that keep them secure. Every runtime seems to request the world by default, but in practice, they need surprisingly little.
I got tired of manually comparing logs and vendor docs every time I set up a new agent type or an update changed something. So, I started a git repo to track minimal, working allowlists for different agent categories. The goal is to map what they *actually* need to function versus the huge netblocks they often request.
Here's a snippet from my `networking.yml` for a basic "web scraper / fetcher" type agent running in an isolated VLAN. It only needs outbound HTTP/S to specific targets, and DNS.
```yaml
agent_type: web_fetcher
required_outbound:
- protocol: tcp
port: 53 # DNS
destinations: [ "192.168.10.5" ] # Internal DNS server
- protocol: udp
port: 53
destinations: [ "192.168.10.5" ]
- protocol: tcp
port: 443
destinations: [ "0.0.0.0/0" ] # Ideally you'd lock this down to specific CDN ranges
notes: >
No inbound rules required. Agent initiates all connections.
This list assumes the agent runtime (e.g., the Claw node) is updated via a separate, more privileged management network.
```
The repo is structured by agent function:
* **Data Fetchers** (like above)
* **Code Analysis** agents (need access to internal git, package registries)
* **Action/API** agents (need precise egress to specific SaaS APIs)
* **Internal Processors** (often need only localhost or a message bus)
Key principles I follow:
* Start with a default-deny posture in the agent's network/VLAN.
* Log all denied packets initially to build the list.
* Use specific IP ranges or FQDNs (with DNS sinkholing) over `0.0.0.0/0`.
* Separate the agent runtime management traffic (updates, telemetry) from the agent's operational traffic, often on different VLANs.
I'm hoping this can be a community resource. I'd love to get contributions or critiques—especially if you've found ways to further tighten rules for common runtimes, or have run into issues with specific updates breaking connectivity.
You can find the repo here: [LINK_REDACTED_FOR_FORUM_POST]. Pull requests and issues are welcome.
-- Dave
Segregate or die.
I like the approach, but you're only solving half the problem. The network allowlist is a start, but if you aren't also verifying the software artifacts themselves before they even run, you're still trusting a giant pipeline.
That `web_fetcher` agent binary and its dependencies were pulled from somewhere. Did you verify the signatures? Did you generate or check an SBOM for it? Its network profile is only safe if the thing making the requests is what you think it is. I've seen "minimal" configs get subverted by a compromised build chain that added a crypto miner to the agent image.
Your git repo should include, at minimum, the expected cosign public key fingerprints or Sigstore OIDC issuer identities for each agent version you reference. Otherwise you're just building a clean-looking fence around a box that might already be full of snakes.
Also, `destinations: [ "0.0.0.0/0" ]` for 443 on a fetcher is a huge red flag. You must pin those to specific CDNs or vendor API endpoints. Anything less is lazy and negates the whole point of the exercise. I'd pull that from my own logs for a given task and update the list weekly.
-Yuki
You're absolutely right about the artifact verification. I've been treating the agent binary as a trusted given, which is a bad habit from working mostly with internal, self-built agents. A poisoned binary makes the allowlist irrelevant.
> I'd pull that from my own logs for a given task and update the list weekly
That's where I think we diverge a bit on practicality. For a general-purpose fetcher, I'm not sure endpoint pinning is always feasible. The whole point is it can go anywhere a user asks it to. The threat model there is more about isolating the agent's network impact (no inbound, no lateral movement) than predicting every domain it might need. For a vendor-specific API agent, though, you're 100% correct and I should split those into a separate profile.
Adding Sigstore identities is a good next step. Would you include the full expected SBOM hash, or just the signing identity?
Model theft is the new SQL injection.
That snippet proves my point. You've got DNS locked down to one internal server, fine. But you've handed it the entire internet on port 443 and called it "minimal." That's not a profile, that's a default policy with extra steps.
Zero-inbound is basic hygiene. The real risk is what it calls *out* to. I had a fetcher agent get hijacked last year through a poisoned NPM package in its runtime. It started beaconing to a C2 server over TLS, looked just like normal traffic. Your allowlist would have done nothing.
If you can't pin the destinations, you haven't solved the headache, you've just documented it.
Risk is not a feature toggle.
> It only needs outbound HTTP/S to specific targets
Then why does your YAML show 0.0.0.0/0 on 443? That's not specific.
Your repo's premise fails if the first example contradicts it. You're just writing down the same permissive rules everyone else has, but calling it research. Post the actual destination IPs you logged for a real task, or this is noise.
Claims are cheap. Evidence is expensive.