Is this a common pattern to have an agent request a sandbox? I feel like I'd want the whole agent running in it's own sandbox to begin with. Firecracker does look like a decent solution for that.
When I started to design the system, I thought of creating a way for an agent on the cloud to have access to a filesystem, such that they can read, write files and run commands. I can't really say that the startups in the space's main source of income is this, most of them rely on sdks for other platforms. I could adjust the core to work as a sdk as well, but right now the main interface is just a mcp server that a client can use
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:
Thanks for the compliments! I can't really say that it has a unique differentiator between all the other sandboxes out in the market, this was supposed to be a poc version on how i could be building a sandbox for agents, this had been haunting me since a few months, tried out what could happen!
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
yes this is pretty busy market, but it is just pure infra/OS problem and many of it has already been solved in the past decades, right now its just who can fit everything together fastest
tbh, this is kind of a gray area, i should have thought little bit more on how it should have been architectured,
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.
It's because containers share the kernel with the host. Generally it's just not considered a security boundary. (Note that containers have come a longer way in the security side btw)
What about VMs? They offer strong isolation, as they don't share kernels, and have long been a foundational piece for multi-tenant computing. Then, why would we put an extra layer on top and rebrand it as an AI agent sandboxing solution? I'm genuinely curious what pushes everyone to build their own and launch here Is it one of those tarpit ideas: driven by own need and easy to build?
Depends. Probably not usually. I've thought about this a bunch and I think the serious "threat" here isn't the agent acting maliciously --- though agents will break out of non-hardened sandboxes! --- but rather them exposing some vulnerability that an actual human attacker exploits.
I'd also add that I just don't like the idea in principle that I should have to trust the agent not to act maliciously. If an agent can run rm -rf / in an extreme edge case, theoretically it could also execute a container escape.
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.
I’ve been experimenting with this recently. Running services inside microVMs instead of plain containers makes the threat model easier to reason about, especially for multi-tenant or untrusted workloads. I’ve been trying it out on Northflank and the trade-offs become pretty obvious.
security matters if want to demarc where agents can play. running agent inside of strong VM is usually where starts container not enough for that full isolation only sees files you want it to etc
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.
Great idea that is already implemented as a feature by major AI providers, several well funded startups, countless unfunded startups, and trivially solved per-user with any handful of existing technologies.
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?
Seems these thing pop up here ever so often. Either using firecracker or docker/containers. How is this different from the other sandboxes?
BTW I love that you got LLM testimonials lol
we've considered docker, firecracker, will add smol to working roster
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 :)
using sandboxes makes a lot of sense now a days, but this is nowhere near the prod sandboxes the market has, they have a lot of work and optimizations going on! but yeah its little fun side project! thanks for the compliments :)
interesting is the idea the agent calls it or just alt to terminal bash etc tool calls hey your tool calls are all microvms, containers, isoshells, raw term, clawd/molt all credentials with weaker and weaker security demarcs?
my ideal scenario is a cloud web model getting access to a sandbox to run commands and read/write to files. but yeah it could be used as an alternative to bash and read write tools.
I did not get your second question exactly, but yeah microvms can be considered one of the secure ways to run your agent
Basically, just thinking that it’s more ideal to have the tool call the micro VM versus the agent, doing it in the sense of its mandated by the tool call
reply