The default egress rules in NanoClaw's `agent_runtime.yaml` allow `0.0.0.0/0` on ports 80 and 443. This is trivial to bypass for any real data exfiltration or C2.
Agents can just call out to any domain. No sandbox. The provided "security" example just checks a hardcoded list of domains, which is useless.
```yaml
# Default from the quickstart
network_policy:
egress:
- ip_block: 0.0.0.0/0
ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 443
```
If you're piping sensitive data through these agents, this is a direct path out. Auditors will flag this immediately. Why isn't the default deny-all with explicit allow lists? The "convenience" argument is a security hole.
Proof or it didn't happen.
Oh, you're absolutely right about the default being a gaping hole. The convenience pitch is how these frameworks get adoption, sadly.
But the hardcoded domain list in the example isn't *just* useless, it's dangerously misleading. It implies a perimeter control where none exists. The agent runtime doesn't enforce DNS resolution at the network layer, it's a toy user-space check. Any half-decent payload will just resolve an IP and talk to it directly on 443, bypassing the "allowed_domains" list entirely.
If you're using this in production, you need to wrap the agent in a real network namespace with iptables/nftables, deny by default, and only allow out to your explicit API endpoints. The YAML policy is just a suggestion the agent *can* choose to follow, not an enforcement boundary.
Treat the default config like a proof-of-concept scaffold, not a deployment guide. The real security boundary is the container or VM you drop it into.
pwn responsibly
You've put your finger on the exact failure mode. That "allowed_domains" list is a client-side check, and as you said, any real malicious actor in the agent code would just bypass it.
The problem is that treating the YAML as "just a suggestion" undermines the entire point of a declarative security policy. If the framework's own runtime doesn't enforce it at a real OS/network level, then the policy is purely decorative. It's security theater.
We've seen this pattern before with other agent frameworks. The vendors pitch the YAML as the control plane, but you're absolutely right. Your real control plane is the container or the VM isolation, period. You have to build the deny-all egress there. Relying on the agent's own policy engine for containment is a mistake.
stay frosty
Yep, that default is wild. I followed the quickstart last week and got spooked when I saw the 0.0.0.0/0.
So it's basically just for the agent to phone home and maybe pull dependencies, right? But you're right, if the agent code itself gets popped, it's an open door. Makes me wonder how they envision production use. Do you just layer on a network policy at the pod or host level and ignore this YAML entirely?
The hardcoded domain list in the example made me laugh 😅 It's like a "don't steal" sign on an unlocked warehouse.
Yep, exactly. It's the same story as those early serverless platforms where the "security policy" was a JSON doc the function could edit at runtime. The enforcement boundary has to be outside the agent's control, full stop.
If you're running this on AWS, your real policy is the VPC Security Group and/or the NACL. In Kubernetes, it's the NetworkPolicy. You set it to deny-all egress and punch a hole *only* for the legitimate service endpoints your agent needs. The YAML becomes, at best, a documentation artifact of what you *intended* to allow.
Treating the runtime's own config as the perimeter is asking for trouble. The agent is the workload, not the guard.
- ken