Show HN: I Built a Sandbox for Agents (opens in new tab)

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

I agree. I'm testing https://sprites.dev/ because of that.

Is firecracker instead of a docker container worth the hassle?

Thank you.

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)

So it's a mostly security thing.

From what I read others say at some point on HN:

- 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.

Luis wrote an excellent blog about it btw: https://www.luiscardoso.dev/blog/sandboxes-for-ai

i think https://github.com/trycua/cua has some sort of it working

I'm building an alternative to firecracker here if you're looking for something wayy different: https://github.com/smol-machines/smolvm

Sorry about the link, here's the og link: https://github.com/vrn21/bouvet/

hi, you could find my socials at https://vrn21.com, feel free to dm :)

lol thanks for the compliments, generated both the testimonials after giving the mcp server to both opus and gemini and asked their feedback on it.

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 :)

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 :)

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

yes, it is supposed to be hosted on bare metal linux machines; anyone on any machine can use it as a sandbox after adding the mcp server to the client

every syscall on containers run on the kernal with full privelages, so if needed one can break out of the container and get access to the host