Has anyone tried https://bhatti.sh/ ?
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
91–100 of 449 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#92Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will
become one.
cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand.
Also, the kernal is an interface too big for what an AI agent needs and is therefore offering a gigantic attack surface completely unnecessarily.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#93...or...just hear me out now...we could limit it in the harness.
Don't give it shell access, just predefined tools.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#94Most interesting part to me is credentials injection at the sandbox boundary level: https://docs.docker.com/ai/sandboxes/security/credentials
Doesn't everyone do this now? It's hardly a new idea. Yet every time someone proposes the idea, people fawn over it and proclaim it the best thing ever. Yes, you can inject tokens via a proxy. What else is new?
Who is doing it as first class feature with at least adequate UX?
I have skimmed alternatives offered in comments to this post (vibepod-cli, code-on-incus, opencode-docker, sandboxy, smolvm, amazing-sandbox) and none of them seem to do credentials injection at the proxy level.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#95[dead]
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#96Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will become one. cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand. Also, the kern…
Would you say podman is better, or is it the same as docker ?
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#97The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…
What I run is one hardened QEMU/KVM VM per project holding the whole dev environment (editors, agents, containers), with nftables on the host allowing internet egress but dropping anything aimed at the host, the LAN, or any other private address, plus an allowlist for deliberate exceptions.
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-...
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#98The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…
maintainer, I would recommend trying out: https://github.com/smol-machines/smolvm
It has network filtering + placeholders for secrets.
OSS, no logins needed
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#99The other day I saw this: https://nono.sh/
Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#100The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…
I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing? thanks
Yes, the stated "target workload"[0] is not what i'm looking for. I want my agent to run for long, spin up dedicated local stack while developing etc.
It seems with gondoling i need to explain the agent to run commands in the sandbox, but then where does the agent run itself?