I have a dedicated container for that. It can run its own Docker daemon and other system services if needed.

Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it.

Of course, this kind of setup requires a stack which can run or at least be tested without any credentials.

I'm using it as my main driver since months.

Support for running agent harnesses in unprivileged podman containers is on my feature list. :-)

Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.

Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)

It has network filtering + placeholders for secrets.

OSS, no logins needed

thanks

https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want

https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want

Basically, it's a plain QEMU/KVM VM on a stock Debian cloud image: device model stripped down to a virtio disk, a virtio NIC and a serial console, nested virt off, no passwordless sudo in the guest. It also ships a containment check that scans outward from inside the guest, so the network boundary is something you can verify.

Wrapping the whole environment rather than a single agent session puts supply chain attacks inside the boundary too. A poisoned npm or PyPI package, or a compromised editor extension, lands in the VM instead of on the host. That was the original reason I set this up; agents just made it more urgent.

There's no per-domain egress allowlist; the policy is "internet yes, private addresses no". Secret injection isn't built in either, though Infisical's agent-vault on the host as an egress proxy covers that part.

Wrote the whole setup up here, in case it's useful:

https://karamatli.com/posts/network-isolated-kvm-sandbox-ai-...

Firecracker is designed to start a VM in under 125ms and 5MB. Netbsd advertises that you can direct-boot a MICROVM kernel configuration in under 10ms.

There is a need for a Docker desktop like GUI for this market.

I use something in between - a single Ubuntu VM, into which I spawn multiple Incus LXC containers for the agents. The containers only use 50 MB or so per instance (separate systemd, ...). This way I pay the VM RAM tax only once, and the agents are still contained inside the VM if they manage to escape the LXC containers.

https://docs.docker.com/ai/sandboxes/security/credentials/

I quite like the 'features' layer system, adding extra tools to container in a declarative plugin-like way

Being able to 'safely' run with skip permissions has been a gamechanger

I wrote a tool to use `bubblewrap` to containerize any agent (at least all the agents I've used a couple of times), and bind mount the system stuff read-only, so the agent has your "usual" environment, but they can only see the project. Their history persists (either through a bind mount or a "shadow" copy of the history that only the wrapped agent sees), the agent can still create and manage containers of its own using podman's rootless mode, etc. It's nearly instant to start because it's just a namespace (plus a few copied files for the container support and session history); no container needs to be built/fetched/updated/whatever. bubblewrap is extremely well-tested as it is used by flatpak and several other large projects, so I trust it quite a bit (more than I trust Docker).

https://github.com/swelljoe/flar

Regardless, I'm hoping something that isn't behind a login screen is going to win out.

Still obviously you should run all untrusted code in a sandbox, but extreme actions like that would be very unusual with the model that shipped.