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
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
161–170 of 449 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#162Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#163Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#164The 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 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
#165Earlier 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.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#166Earlier 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.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#167If 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…
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
#168Ideally, 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
#169One 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
#170I 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?