Posted by etoxin 5 hours ago
(I am testing this now as a backend for my pet project which currently supports firecracker and gvisor. No network.)
But, in any case, why put in effort doing something people don't expect or ask for? We can assume everyone running agents is either a) using their own sandbox, or b) doesn't care. I think we can guess which category most people fall into. You could maybe argue about responsibility, but I don't think you can argue about "serious engineering".
Exactly. It's not as though it's difficult. It never occurred to me to not do this from day one, and it astonishes me that anyone runs this stuff bare metal. Since then, I've brought several other people on board, and that's all they've ever seen: I don't think they'd know how to run outside a sandbox, and that's just fine.
Also if your thing doesn't work with `pi` out of the box, then low effort
Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.
But it’s not as well sandboxed for sure.
Eg, if used with Colima in macOS, it means I can run a devcontainer in an isolated VM and Nono inside the devcontainer can restrict a lot what can and cannot be done.
You get credentials proxying and network outbound limits.
How is Docker Sandbox better sandboxed?
cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand.
Also, the kernal is an interface too big for what an AI agent needs and is therefore offering a gigantic attack surface completely unnecessarily.
This is not my main point though. Both are based on cgroups and cgroups are the wrong tool for the job.
The same is not applicable for any kind of sandboxing for two reasons:
1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM
2. The kernal is a gigantic attack surface -> Use gVisor
[1] https://docs.cloud.google.com/kubernetes-engine/docs/resourc...
Say I want to use pi inside a container. If I wrap pi within a bubblewrap or within nono, how is that less secure than using a vm?
Also, I think most people run containers inside VMs anyway and not directly on their hosts (on Mac and windows you have to use a vm anyway).
For clarity I’m actually using podman, not Docker.
Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.
Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs.
So yeah, not "vulnerable".
On Linux, you can run docker directly on the host, but you can also very easily setup a vm with incus and run docker from there.
docker run --runtime krun hello-world
Though, they need to remove the login requirement.
Automating browsers with LLM agents properly requires a lot more work than Process.Start into powershell, but the advantages can be immense once you have achieved integration this way. Incrementally maintaining this integration is generally easy because human users cannot tolerate rapid changes either.
It's a hell of a lot easier to convince management to adopt a robot that looks and acts like a human employee than one that looks like a combine harvester. The combine is far more efficient, but it is also totally indiscriminate. Nothing constrains its appetite except for the invisible fence imposed by GPS. The amount of infrastructure required to keep farm equipment from running astray is incredible. In the context of agriculture, the added complexity is definitely worth it. We don't want to have to recreate the same thing with our technology if it can be avoided. Sandboxes and security isolation boundaries are not things to aspire to. These are costs to be paid for admission to something more valuable.