> Docker containers are not enough isolation for anyone that cares about jailbreak scenarios.
For the vast majority of developers, containers are enough, which is why they are ubiquitous while vms are less common. Ofc that ubiquity has led to lazy configuration, which is how the jailbreaking can occur. Knowing what you are doing with containers is a requirement to use containers as an AI sandbox.
the big thing containers don't allow is for the agent to run and use docker itself without compromising the host
I'm not sure where "vast majority" cuts in but I would say a huge number of developers use docker and it is inconvenient at best if your AI harness can't actually run and test the infra it is building against
> Only real alternative is to use microvms. My goto solution for this are apple/containers.
Why microVMs? I never ever run a container, AI harness or other, in something else than a full on VM. I could use a microVM but in any case I really don't see why I'd run a container on one of my bare metal OS: the place of a container is inside a VM (or microVM).
Especially for AI harnesses where the threat of an escape is very real: the more defense in depth, the better.
And If I can use rootless Podman instead of "rootfull" Docker, the better. Most of my containers are Podman btw.
> My goto solution for this are apple/containers.
To each his own: my goto solution is an actual server on my LAN with shitload of cores and memory and plenty of scripts to provision VMs etc.
I really don't understand why people are YOLO'ing containers on their bare metal OS.
I agree. I thought everybody knew to never use docker for high security, because it is "security lite". Might as well just use firejail. I presume that an agent knows more about networking and virtualization than I do. The only real solution is using multi-tenant level vm isolation, while presuming that the agent still might break out of their vm. So the vms need to be hosted on their own physical box that only runs the kvm provisioning host (or similar), and is firewalled on its own isolated network. It's a bit of a pain of course, but anything less feels almost like security theatre rather than meaningful to me. Otherwise you need to stick to the remote chatbots only.
multi-tenant level vm isolation does not solve, imho, specific issues like data exfiltration (ssh private key, api tokens) or privilege escalation, as the vm still contains the whole kernel and userspace inside. So breaking out of the vm may be a realistic scenario.
Yes of course, the secrets have to be isolated from the VMs, preferably at the network gateway and not on the same KVM host. But as far as I know there is no safer containerization technology than a VM, and the only way to be more secure would be to have a physical computer per agent process? A KVM does not use the host kernel and user space, and provides hardware level isolation (the CPU hypervisor etc), that's the point. I think that once you are inside of vm, just using firejail is the better approach, since you have more direct control over the OS level controls that are being leveraged by various container solutions anyways. At any rate, that's what I did.
If you can't isolate a computer on your network, you probably can't isolate your network from the internet, so it's an irrelevant exercise at that point. And yes, probably you can't do any of those things and any frontier model could technically hack your network, but I don't think there's a better way to do it?
Many thanks for the insight. Actually you are right, kvm provides a different level of isolation. If there is a better way to do it... Not sure about that. It seems this is somehow unexplored territory right now, and the current hype about frontier-models capable of """everything""" is difficult to fight against.
Entire VMs bring quite a lot overhead, though, I picture it as many agents being able to run in isolated environments in the very same dev laptop.
My current approach has been to use podman so far. It supports libkrun, so I may give a try to microVMs in my current project.
I'm using it as my main driver since months.
Support for running agent harnesses in unprivileged podman containers is on my feature list. :-)