atechboy

Got it. I meant how this design compare to other sandboxing providers. For example, ephemeral sandboxes (e.g., E2B) where you spin up a clean VM for every tool call can reduce the blast radius, but maybe inefficient.

Looks like you are running tools/browser in the same VM. How safe is this? Do you see contention for ports/resources? How does it compare to offerings from other sandboxing providers?

That makes me wonder if it is a tarpit idea.

> A properly engineered sandbox would have prevented the escape.

The only sandbox that could have prevented this (as per my understanding) is a VM with no 0-day.

So you are using Modal VMs for training (I assume RL evals?).

> People run a pilot agent that scopes work and delegates it to sub-agents, each on its own VM: shape a project with the pilot, and the workers implement it and open PRs. One customer runs hundreds of machines at once, spun up and torn down from the CLI.

Are people spawning VMs for every tool call? If so, would love to understand why so, and why containers are not a good fit?

So the idea is to give each agent a VM to do several tool calls? or one VM for each tool call?

what commercial tools are enterprises using today to defend against such attacks? Do they really work? I mean, do they report/block malware after the fact or detect proactively. Because if the latter then, package registries should really be removing reported packages, right?

I'd be curious to see what it produces. Thanks for bringing it up!