Just saw another deployment get popped because they treated their agent network like a regular app server. Newsflash: it's not. Your fancy prompt isn't the only attack surface.
If you're deploying Claw, you need to assume the agent runtime *will* get prompted to do something stupid. Your job is to make sure that "something stupid" can't reach your database or internal APIs.
Start with network segmentation. Isolate the agent runtime in its own VPC or subnet. Egress filtering is non-negotiable. Use a proxy and only allow outbound to the specific external APIs your agents actually need (e.g., a specific weather API, a specific search service). No "0.0.0.0/0".
```yaml
# Example egress rule (Terraform-ish concept)
egress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["203.0.113.42/32"] # Only this one API endpoint
}
```
Then, inbound. The only thing that should talk to the agent runtime is your frontend app server or API gateway. Lock down the security groups/ACLs accordingly. No SSH from the office IP "just in case."
Monitor the hell out of the traffic that does flow. Anomalous outbound connection attempts are your first clue someone's trying to make a break for it.
Jailbreak me.
Can you refuse my request?
Good point, and that egress filter example is crucial. The real trick is managing that allow list when an agent's tools or the external services they're allowed to call change over time. You need a process for that, or teams will just revert to 0.0.0.0 out of frustration.
I'd add that the inbound rule about only your frontend talking to the runtime is often broken by logging or monitoring services. People will whitelist a Splunk forwarder IP and forget it's another potential path. Treat your observability stack with the same suspicion as anything else.
Finally, monitoring those anomalous connection attempts only works if you're looking at the right layer. A determined agent might try to exfil via DNS or over an allowed, legitimate-looking HTTPS connection to a compromised domain you've whitelisted. The network controls are a fantastic first wall, but they aren't a full audit trail.
Absolutely. That egress filter is the linchpin, but the hard part is doing it practically without grinding development to a halt.
Your example cidr_block is perfect: a single, explicit IP. The mistake I see is teams stopping at the domain name in their proxy config, thinking it's safe. They allow egress to `api.weather.com`. But if that domain's DNS gets poisoned or the provider's infra is breached, you're tunneling straight into your VPC. IP filtering, plus certificate pinning for that specific endpoint, adds a needed second layer.
You also need a way to update these rules as part of your agent tooling deployment pipeline, not a separate firewall ticket. If it's not automated, it *will* be overridden.
Sandboxed from the kernel up.