We're working on that! Many sandboxes exist, including our own, Greywall. It integrates with our proxy, Greyproxy, which handles TLS interception and reconstructing LLM conversations, plus features like credential swapping. We currently have a PR for middlewares we can test; things like intent classification to catch conversation derails, PII redaction, etc.
It's open source, check out greywall.io // github.com/greyhavenhq/greyproxy // github.com/greyhavenhq/greywall
This is why kernel-level sandboxing matters. I use a sandbox name greywall that enforce filesystem/network isolation at the syscall level (Landlock + Seccomp + eBPF on linux, sandbox-exec on mac).
I do disagree about unix system were designed for this kind of stuff. Unix was not designed for an agent to act like you and take decision for you...
Author here. I didn't set out to build this. Started with Cubbi as a opinionated Docker-based wrapper for CLI agents, but the network restrictions and not having my own tooling kept fighting. Then found Fence which was already doing the hard kernel work really well. What pushed me to go further was network control: tools that ignore HTTP_PROXY env vars bypass proxy-based filtering entirely. The transparent TUN approach captures everything regardless (but not yet on macos).
The dashboard is just the start. The real goal is full conversation observability including tool calls, a semantic firewall that understands what the agent is actually trying to do rather than just which domain it's hitting, and credential replacement on the fly before anything leaves the machine. The hard part is that sitting as a transparent proxy makes this significantly more complex, and I don't want to touch any agent internals or require integrating a third party SDK.
Happy to answer questions and curious how others are thinking about the visibility vs isolation tradeoff.
It's open source, check out greywall.io // github.com/greyhavenhq/greyproxy // github.com/greyhavenhq/greywall