Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

161–170 of 449 posts

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

#161

Earlier quoted context omitted.

Eclipse Enclave does exactly that: There is an outbound firewall and secret injections, so that the agent never sees a real key. And it's fully open source: https://github.com/eclipse-enclave/enclave

Looking at the Readme it seems like it only supports docker. Which is a dealbreaker for some

What is missing in qemu + podman that we need rootful docker for this? Is there actual capability that is missing or is it more of a design choice by the eclipse enclave folks?

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

#162
Just a small meta note: most of the comments in this thread appear to be posting their own codebase (typically AI-generated) that accomplishes the same goal. It's interesting that this problem is simultaneously in high demand and yet considered trivial enough to vibe code per-user solutions to it.

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

#164
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 least be tested without any credentials.

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

#165
post #135
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?

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

what's to stop an agent creating an outbound call with the var to a malicious endpoint? (unless you whitelist what it has access to)

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

#166
post #135
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?

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?

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

#167

If any AI company was doing serious engineering isolated containers would have been a prerequisite to using their tools.

Anyone serious about security will want to bring their own sandbox anyway, not trust these, often proprietary, agents. I've never run an agent outside a sandbox. My first bubblewrap script for `claude` is now over a year old. The tools are available and if you learn to use them you can run any program in a sandbox. But, in any case, why put in effort doing something people don't expect or ask for? We can assume every…

> Anyone serious about security will want to bring their own sandbox anyway

Exactly. It's not as though it's difficult. It never occurred to me to not do this from day one, and it astonishes me that anyone runs this stuff bare metal. Since then, I've brought several other people on board, and that's all they've ever seen: I don't think they'd know how to run outside a sandbox, and that's just fine.

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

#168
Are we sandboxing AI agent harness process, or the environment it executes commands in?

Ideally, they should run in _different_ sandboxes.

The environment might corrode the harness (e.g. rogue npm/pip packet would manipulate agent harness config).

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

#169
I tried it and it worked great at first but I had multiple issues with it, the disk space usage was growing significantly, I need to login multiple times for each sandbox, it's closed source and not possible to customize to my need.

One other thing, I want to be able to handle multiple repos in the same sandbox and have a standard workflow around worktrees (one worktree per repo, all the worktree mounted in the VM).

These were some of the reasons that led me to build: Clawk - https://github.com/clawkwork/clawk

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

#170

I tried Docker Sandboxes but last time I checked you could not configure custom volume mounts, making more complex setups impossible. For work I need two directories for context for the agent to have access to…

put them both inside another directory and share that? what am i missing?

Of course, but that was not part of my workflow and I found it quite strange that this was simply not possible especially when docker-compose can easily do this
Post reply on HN