I work in evals, not technically alignment, but I have never put an agent in a virtual machine. Usually it’s in bypass-permissions mode. For something particularly sensitive, I’ll use auto permissions mode or ask-for-permissions mode. For something extremely sensitive, I put the agent in a docker container, but I try to avoid this whenever possible because it breaks a lot of workflows—except running evals themselves, which are typically in a container. Nothing super bad has ever happened from this, and I don’t expect it to because I can stay calibrated to the correct paranoia level as new information comes in about how capable new agents are of sabotage and how well monitors can catch them.
I will be pretty sad if I ever need to be paranoid enough to use a virtual machine for routine agent-assisted research. Claude-guard is great for a security level short of that, which will probably continue to be the most common.
A docker container is much easier to break out of than the sandbox that is applied automatically and invisibly to every app installed on iOS or Android.
[Added.] Although Linux is sorely lacking in internal security boundaries, and generally just has poor security properties, it does have Firecracker and gVisor, which were developed by Amazon Web Services and Google Cloud Platform respectively to enable their huge public clouds to run untrusted work loads submitted by customers without the constraint that each customer gets his own CPU. For the project he is announcing here (namely, claude-guard) Turntrout has chosen to use Firecracker when KVM is available and gVisor when it is not available. Both of them are effective choices for sandboxing potentially-adversarial code on Linux. A docker container in contrast is simply not an effective security boundary.
I work in evals, not technically alignment, but I have never put an agent in a virtual machine. Usually it’s in bypass-permissions mode. For something particularly sensitive, I’ll use auto permissions mode or ask-for-permissions mode. For something extremely sensitive, I put the agent in a docker container, but I try to avoid this whenever possible because it breaks a lot of workflows—except running evals themselves, which are typically in a container. Nothing super bad has ever happened from this, and I don’t expect it to because I can stay calibrated to the correct paranoia level as new information comes in about how capable new agents are of sabotage and how well monitors can catch them.
I will be pretty sad if I ever need to be paranoid enough to use a virtual machine for routine agent-assisted research. Claude-guard is great for a security level short of that, which will probably continue to be the most common.
Thanks for replying, this is an important update for me.
A docker container is much easier to break out of than the sandbox that is applied automatically and invisibly to every app installed on iOS or Android.
[Added.] Although Linux is sorely lacking in internal security boundaries, and generally just has poor security properties, it does have Firecracker and gVisor, which were developed by Amazon Web Services and Google Cloud Platform respectively to enable their huge public clouds to run untrusted work loads submitted by customers without the constraint that each customer gets his own CPU. For the project he is announcing here (namely, claude-guard) Turntrout has chosen to use Firecracker when KVM is available and gVisor when it is not available. Both of them are effective choices for sandboxing potentially-adversarial code on Linux. A docker container in contrast is simply not an effective security boundary.
Sadly, macOS cannot even run gVisor AFAICT. It’s only runc. :( This is near the top of my priorities for medium-term. See issues #580, #581, and #582.