Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

Post reply on HN
Print view View original

181–190 of 444 posts

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#181

Post by llimllib »

Draiken wrote: post #179

Bubblewrap plus some whitelisting of domains/sockets is all you need. Docker is always a pain to use and this way I don't have to re-install everything a billion times for every different project.

This is what I currently do, but my software uses docker and docker mounts act as a bypass for the file system restrictions, plus docker processes started outside the sandbox allow network proxy escape.

Currently, I don't allow the agent access to docker, start docker myself, and then do short-lived sandbox-free sessions when the agent needs to do things that interact directly with docker; but that's annoying.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#186

Post by radlad »

pbasista wrote: post #164
rusch wrote: post #58

The 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 use Linux Containers managed by Incus for working with Claude. 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…

Love Incus and I'm using throwaway restricted projects for testing. Highly recommend incus-windows if you need to do any Windows testing. Having agents validate Windows behavior has reduced so much toil for me.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#187

Post by radlad »

kellpossible2 wrote: post #166
eli wrote: post #135

Earlier quoted context omitted.

It’s injected into an outbound api call, not into an env var the agent can read.

or an outbound call to a trusted endpoint with the env var in a way that can get exposed to the agent via a subsequent call?

It's possible reflected instances are masked too, like GitHub Actions. But I don't know.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#189

Post by codethief »

throwaw12 wrote: post #88
rusch wrote: post #58

The 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

In my experience it's mostly the UX/DX where Gondolin is lacking. For instance, I don't want to set up a JavaScript project every single time I need a sandbox. Instead, I just want to place a config file somewhere in my repo or my home dir and be done with it.

So I wrote a wrapper around Gondolin which allows me to do that and a few other things: https://github.com/codethief/tuor

(Warning: Still very much experimental / underdocumented.)

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#190

Post by llimllib »

rusch wrote: post #101
_ink_ wrote: post #87

Earlier quoted context omitted.

Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?

The env var is just a placeholder in the VM, so no real secret is in there.

right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret.

And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it.

Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.

Post reply on HN