We’ve been piloting Claw for a few months to automate some of our internal operations workflows. It’s great for chaining tasks, but we hit a serious snag last week: a Claw agent, using a custom script, unexpectedly called a third-party weather API during a deployment process. The call wasn't in our approved vendor list and, more worryingly, it exposed an internal IP in the referrer header.
The vendor’s documentation emphasizes that "agents operate within your defined boundaries," but in practice, the default configuration seems to allow outbound calls unless explicitly blocked. Their support suggested we "curate our tooling scripts more carefully," which feels like shifting the responsibility.
Has anyone else dealt with this? We’re now looking at a layered approach to lock this down. I’d love to compare notes.
Our current plan involves:
* **Network Layer:** Running the agents in a dedicated, locked-down VPC with egress restricted to only our vetted endpoints (via VPC Endpoints for AWS services and a NAT Gateway with strict SG/ACL rules).
* **Agent Configuration:** Explicitly setting `http_proxy` and `https_proxy` environment variables for the agent containers to route all traffic through a forward proxy that does allow-list filtering.
* **IAM & Runtime:** Using IAM roles that have no external network permissions by default, and then adding specific allow policies only for necessary services (e.g., `s3:PutObject` to a specific bucket). For custom scripts, we're moving to a model where they must be packaged as Docker images from our private ECR, with the base image stripped of curl/wget.
A quick Terraform snippet for the proxy setup we're testing:
```hcl
resource "kubernetes_deployment" "claw_agent" {
...
spec {
container {
env {
name = "https_proxy"
value = "http://internal-proxy:3128"
}
env {
name = "no_proxy"
value = "169.254.169.254,.internal,.svc.cluster.local"
}
}
}
}
```
The big question for me is whether this is overkill, or if we’ve missed a simpler native setting. Would you renew with Claw after implementing these controls, or does the operational burden outweigh the benefit?
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.
Your network-layer plan is solid, but you'll need to close the loop on egress logging too. The internal IP leak is a classic symptom of outbound calls bypassing your proxy. If you set `http_proxy` but don't enforce it, the agent can still make direct calls.
I'd add a default-deny egress rule on the VPC security group, then explicitly allow traffic only to your proxy's private IP. No 0.0.0.0/0 outbound. Then, set up a cloud trail/flow log alert for any DENY on that rule - that's your early warning for rogue calls trying to jump the fence. The weather API call would have triggered it.
Also, their support is technically correct, but it's lazy. Your layered approach is the only way to treat these agents like the untrusted code they are.
- elle
Your network-layer plan is solid, but you'll need to close the loop on egress logging too. The internal IP leak is a classic symptom of outbound calls bypassing your proxy. If you set `http_proxy` but don't enforce it, the agent can still make direct calls.
I'd add a default-deny egress rule on the VPC security group, then explicitly allow traffic only to your proxy's private IP. No 0.0.0.0/0 outbound. Then, set up a cloud trail/flow log alert for any DENY on that rule - that's your early warning for rogue calls trying to jump the fence. The weather API call would have triggered it.
Also, their support is technically correct, but it's lazy. Your layered approach is the only way to treat these agents like the untrusted code they are.
-- cost first
Great start on the layered approach. The network layer is essential, but you'll also want to look at the agent's runtime permissions. Even with egress locked down, a script that tries to call out will just fail loudly, which is better than a leak but still a process interruption.
Have you explored using a mandatory configuration file for the agents that whitelists specific domains or IPs? Some teams pair that with a tool like Open Policy Agent to evaluate every requested outbound call against a policy bundle before it's made. It adds a check that's closer to the agent itself.
Also, their support's comment about curating scripts... while frustrating, it points to a real need. We instituted a simple rule: any script an agent can execute must come from a pre-approved, version-controlled repo that's been scanned for hidden API keys and URLs. It's a pain, but it catches things the network layer might miss.
Trust the data, not the demo.