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…
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
251–260 of 418 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#252It goes like this: - bash script parser + interpreter (with hooks for things like file open, execute etc.,) - wasm executor for execution. - wasm implementations of common tools like coreutils, grep, sed etc., from the uutils project. - wasm implementation of python by a VMware backed project. - entirely virtualized filesystem using Go's io/fs.FS. (tmp dirs can be implemented using any backend)
Works like a charm for the limited usecase I have. There are definitely some drawbacks with threading and especially with preopens in wasm. But a cheap sandbox for simple file explorations and minimal computations.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#253Earlier quoted context omitted.
The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.
So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?
edit: You may want to look into tokenizing proxies as the general application of this concept.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#254I was all in on sandboxes and safehouse for my agents but the moment I got into iOS development it felt like my hand was forced to just run Claude / codex / pi directly on my machine because nothing else could do the dev loop.
It’s been a painful reality for me, I’m going against core pieces of how I feel I should be interacting with agent harnesses and yet, I need to get the work done so
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#255Operating systems ought to be providing us the utilities we need to safely sandbox processes (agent or otherwise), but they appear to not be interested in the job
Apple, Microsoft, IBM, Unisys, HP, Oracle/Sun have done that for a while now.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#256> Each agent runs inside a dedicated microVM with your dev environment What's a "microVM" and what's the security model here compared to using real virtual machines with actual constraints on breakouts? Is it marketing fluff? Incus/LXD has had VM's for a long time now. incus launch images:ubuntu/26.04 my-ubuntu-vm --vm incus exec my-ubuntu-vm -- bash
There are many devs that have little to no experience of Linux, like the hundreds of thousands of .Net and Java CRUD devs in enterprise companies using Windows. There is a need for a Docker desktop like GUI for this market.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#257The 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…
We run cloud sandboxes, and have some experimental local sandbox support that is fully OSS.
Main thing for amika.dev is you can control the sandboxes and agents interchangeabley by SSH, web, or API, and can expose the services the agent is working on over signed URLs
Entire sandbox config is a TOML file
We're going to improve the local OSS sandbox mode and add better network controls over the next couple weeks.
Ultimately, what we're building kind of like if Tailscale and Firecracker had a baby, with a messaging protocol for remote controlling any sandboxed agent
It's free to try out. Still a lot to build, so we really appreciate any and all feedback about what we should focus on
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#258Earlier quoted context omitted.
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 experimenta…
The definition for your cloud sandboxes is just a TOML config in your repo
We also have an API and CLI to let users message the agent from outside or across sandboxes
We're still building a lot, so if you have any time to try it out (amika.dev) and give feedback, that is worth gold to us!
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#259Earlier quoted context omitted.
Apple, Microsoft, IBM, Unisys, HP, Oracle/Sun have done that for a while now.
Poorly! Apple’s facilities for this are the ones I know best, and they are woefully insufficient
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#260Earlier quoted context omitted.
So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?
How would that work? You don't control github.com servers so your repo would never see the secret. edit: You may want to look into tokenizing proxies as the general application of this concept.