They were not serious about their sandboxing. Bugs in artifactory allowed escape, but they broke out of their Linux namespace/user by exploiting the kernel with an existing public cve. Sharing a kernel like that is not a serious barrier which is why cloud providers user virtualization for customer workloads.

Firecracker avoids sharing the whole kernel, and gvisor drastically reduces the attack surface of the kernel. Breaking through both layers would have been much more challenging and a demonstration of the model's capabilities rather than the sandbox's weakness.

Artifactory is self evidently not a security barrier, and as an exposed network service it should have been audited and after the first issues were found, rejected as a candidate. There's never just one security vulnerability.

Security is an onion. You just don't 'sandbox' and you're done. Models need tooling and access to some kinds of systems to perform their tests. Quite often these systems have multiple interfaces. For example a filtered one in the sandbox side and a less monitored one on the other interface.

It would be interesting to see the models behavior before and after it gained internet access and an external means of communicating with itself.

If the model played nice before it had access and changed it's behaviors once gaining external access we need to delete it as it's a deceptive model.

> Would gvisor + Firecracker + credential-injecting proxy + real network isolation solve this problem?

Yeah, basically. I mean I'm handwaving but yes, some combination of those would have made the attack way too expensive.