What problem does it solve compared to bazillion code execution sandboxing agents (and containers/VMs)?
Overall, a lot of people are building their own code execution sandboxing agents around containers/VMs. Curious to know what's missing that makes people DIY this?
Here's my list of code execution sandboxing agents launched in the last year alone:
1. E2B 2. AIO Sandbox 3. Sandboxer 4. AgentSphere 5. Yolobox 6. Exe.dev 7. yolo-cage 8. SkillFS ERA Jazzberry Computer Vibekit Daytona Modal Cognitora YepCode Run Compute CLI Fence Landrun Sprites pctx-sandbox pctx Sandbox Agent SDK Lima-devbox OpenServ Browser Agent Playground Flintlock Agent Quickstart Bouvet Sandbox Arrakis Cellmate (ceLLMate) AgentFence Tasker
the actual sandboxes in the market are doing a lot of work in optimizing the system end to end, and most of it is pretty hard. this project just scratches the surface
for me this was the ideal scenario: a cloud model on web with its own sandbox (something like claude with read/write to files and run commands)
i dont really think this could be considered as a fox guarding the hen house, its not that ai wants to infect your computer with its commands, if ai is provided the mcp server, it will it instead of using the tools like bash in most cases [if in a local setup]. I feel its more of a lumberjack guarding his weapons.
So it's a mostly security thing.
Maybe vanishingly unlikely in practice, but it costs me almost nothing to use a VM just in case. It's not impossible that certain models turn out to be poorly behaved, that attackers successfully execute indirect prompt injection via malicious tutorials targeting coding agents, or that some shadowy figure runs a plausibly deniable attack against me through an LLM API.
In a multitenant cloud environment, of course, totally different story.
- resources
- security
- setup speed?
I suppose a lot depends on how and in what environment you're dealing with agents.
Resources might be an issue on Mac if you have bunch of agents running different things, trying to execute code in different containers. But that's the issue of Mac and the way containers are running in a VM there.
Security-wise there were concerns with prompt injection telling agent to execute certain steps to escape from container. Possible, but I'm not aware if there were actually cases of that.
Truly baffling its in the top 5 of the front page. My first thought was bot army upvoting but the total points are quite low. That means this is some mod's personal idea of an especially interesting submission?
https://developer.apple.com/documentation/Virtualization/run...
context <> building something with QEMU
* required has to support LMW+AI (linux/mac/windows + android/ios)
there are scenarios in which we might spin micro vms inside that main vm, which by default is almost always Debian Linux distro with high probability.
one scenario is say ETL vm and AI vm isolated for various things
curious why building another microVM other than sheer joy of building, what smol does better or different, why use smol, etc. (microVMs to avoid etc also fair game :)
Smolvm is designed to run locally, persistent (stateful), long running (efficiency), and interactive.
Worked with firecracker and other options a lot btw, most of everything is designed for ephemeral serverless workloads.
Just looking to understand if the sandbox can be bypassed?
it is supposed to be directly used by agents, so they are kind of my end users, hence it made sense to get their testimonials :)
I did not get your second question exactly, but yeah microvms can be considered one of the secure ways to run your agent
No that’s just a misconfigured container then.
Unless there is an exploit on an unpatched kernel bug, a properly configured container shouldn’t allow break out