We built ERA to fix this – local microVM-based sandboxing for AI-generated code with hardware-level security. Think containers, but safer. Such attacks wouldn't touch your host if running in ERA.
GitHub: https://github.com/BinSquare/ERA
Quick start: https://github.com/BinSquare/ERA/tree/main/era-agent/tutoria...
Would love your thoughts and feedback!
For example if I am coding with Kilocode and phpstorm. How would I use these microVms and what is the cloudflare worker for? I currently run a regular set of docker containers to run my code, how does this compare?
To answer your questions :)
- How would I use these microVms and what is the cloudflare worker for?
This is unlikely the right solution for you, it's more geared towards people building kilocode (because they have an agent that independently writes code + executes that code).
The microvm's are for developers running locally wanting to execute untrusted code written by an ai - example is running codex or gemini-cli. Cloudflare workers are for users who want their own "sandbox infra" so they can execute untrusted code written by ai with their production app (not local hopefully)!
- I currently run a regular set of docker containers to run my code, how does this compare?
Very little difference for your use case unless you expect to do more hostile coding.
But I'll try to explain why VM's are different than containers in the security area:
Containers are not considered as production-level security boundary. One of the main reason is because containers share the kernel with the host machine running the container.
Security penetration engineers do not consider exploiting `some` linux kernels to be high effort because depending on the version, libraries, etc there are CVE's to exploit: https://www.cisa.gov/known-exploited-vulnerabilities-catalog...
However, virtual machines are battle tested sandbox tech designed to have strong protection by having host and the VM have individual operating systems AND dedicated virtualized hardware. This is also the main environment you can rent from big providers. Some more info here: https://www.wiz.io/academy/containers-vs-vms
So this product is a microVM which combines security of VM's + a layer to make it easy and fast like containers to get the best of both worlds.
You absolutely can spin up a container or a vm and run your agents in it - but you make trade offs. Containers are easy and fast. Vm's use more resources but are more secure. Most people in production run containers in vm's to get benefits of both!
This is a product that tries to get the best parts of both containers (devX + speed) and vm's (security). The innovation here is using micro-vm's which are really really lightweight and fast to start compared to traditional vm's. Props to libkrun team for creating that: https://github.com/containers/libkrun
This product is effectively wrapper that has some fixes + devX glue that makes the experience hopefully faster. I try to improve the cleanup, logging, resources monitoring as an example: https://github.com/BinSquare/ERA/blob/main/era-agent/vm_serv...
The recipes and skills stuff is pretty experimental, we're trying to see if we can make this a full environment where agents can just have all the tools they need to build along with full privilege (sudo) because it's inside a microvm!
I don't think I'll use your project, but it's great that you're thinking about these things. We need more security initiatives in the "AI" space.
What I find interesting: I’m running all kinds of agents (for good or bad, make fun of me if you like): not just coding agent products, but “hand rolled” as well, and they all have features which require some filesystem or environment state (tools, skills, instructions etc). They are each subtly different in those requirements, but some patterns are emerging and it seems to me that OP is seeing this as well - and noting that this aligns with the Agent Sandbox domain which is not “solved” yet. Consider that a Dockerfile sets up an environment for the code you want to deploy, which is better than the shell script you use on your local - it’s becoming more apparent to me that there’s a similar need here, which isn’t satisfied by the abstractions we already have, and lots of folks are poking around these domains to find something that fits.
See these posts: https://firecracker-microvm.github.io https://www.koyeb.com/blog/what-is-a-microvm
Is there a way to install / run these from node.js / npm as well (not global), instead of installing them to the whole system ?
Would be a bon for IDEs to run code sandboxed locally!
Here's the work-in-progress here: https://github.com/BinSquare/ERA/tree/main/era-agent/sdk/nod...
I'm not very familiar with node to be fair so it's taking a little longer for me to get that going.
When running a bunch of parallel agents locally, they can step on each other's shoes a bit. The ideal setup is to give them isolated workspaces, have them pull code in, do work, then push code back upstream.
When they do work, they sometimes go off the rails. They'll delete files they don't understand or think are irrelevant, explore other parts of the FS and get confused once their context is contaminated. By giving them a sterile workspace, it allows near risk-free multi-agent operations.
Containers offer most of this, but I was concerned about the security boundaries if it really goes haywire. For example, if I have an agent working at a very low level, it might start messing with the OS in a way that can damage things in a difficult way to reverse. They get confused easily.
Anyway, bookmarked. I will check it out in more detail when I get to that portion of my workflow. Thanks again.
Let me know if you run into any issues
Rather than relying on the usual trade-off between Firecracker-style microVMs and syscall-level sandboxing like gVisor, ERA takes a different path—leveraging libkrun to deliver “lightweight yet VM-like” isolation without compromising the developer experience. That balance is genuinely impressive.
What stood out to me while exploring the repository:
・Deeper isolation than gVisor—no direct access to the kernel surface
・A clearly safer boundary than containers, without the overhead of Firecracker
・Practical issues with libkrun (buildah, krunvm, case-sensitive volumes) are addressed with care in the README and setup scripts
・Maintains ~200ms microVM startup, making it fast enough to integrate naturally into agent execution loops
・Local-first by design, yet flexible enough to support Cloudflare Workers for orchestration when needed
・Well-crafted recipes and examples that go beyond the basics and support real-world usage
This isn’t just about “running microVMs”—it’s about delivering a tool that developers can actually rely on. It feels far from a proof of concept; it’s something you’d want to keep in your toolbox.
Running AI agents safely on local machines is still an open challenge with no clear standard. In that context, ERA’s approach—seamlessly integrating microVMs into everyday development workflows—is both timely and valuable. I have deep respect for the thoughtful implementation and design philosophy behind it.
0123456789ABCDE•2mo ago
you wrote that this is local but what's up with the cloudflare subdir? do we need a cf account to run this?
binsquare•2mo ago
The microvm's are our local solution so devs can use it.
But we thought people might to do some production work to not run local stuff - so we added a compatibility layer with cloudflare :D. Good note, didn't even think about that being kind of confusing.
No CF account needed to run this!