jingkai_he

I'm predominantly using Linux vm workstation with nested virt enabled. It performs reasonably well with nested virtualisation.

I haven't tested the scenario of non-cpu-accelerated workload, but I'd expect the performance to be very poor.

That said it might be possible with PVM as the above thread has mentioned.

Creator of matchlock here. You can directly use Docker/OCI compatible images (e.g. ubuntu:24.04) as the rootfs with the `--image` flag.

You can also build image with `matchlock build -f Dockerfile -t foo:bar .` - Under the hood it builds the image using buildkit inside the microvm.

The main thing matchlock adds over general-purpose vm/container tooling is agent specific network and filesystem (wip) controls, so if an agent goes rogue it can't exfiltrate your API keys, and damage largely mitigated. You'd have to build all of that yourself on top of LXD (possibly similar to matchlock).

There's also the DX side - OCI image support, highly programmable, fuse for workspace sharing. It runs on both linux and mac with a unified interface, so you get the same/similar experience locally on a Mac as you do on a linux workstation.

Mostly it's built for the purpose of "running `claude --dangerously-skip-permissions` safely" use case rather than being a general hypervisor.

Creator here.

Agreed, sandboxing by itself doesn't solve prompt injection. If the agent can read and send emails, no sandbox can tell a legit send from an exfiltration.

matchlock does have the network-layer controls you mentioned, such as domain whitelisting and secret protection toward designated hosts, so a rogue agent can't just POST your API key to some random endpoints.

The unsafe tool call/HTTP request problem probably needs to be solved at a different layer, possibly through the network interception layer of matchlock or an entirely different software.

Creator of matchlock here. Great questions, here's how matchlock handles these:

The guest-agent (pid-1) spawns commands in a new pid + mount namespace (similar to firecracker jailer but in the inner level for the purpose of macos support). In non-privileged mode it drops SYS_PTRACE, SYS_ADMIN, etes from the bounding set, sets `no_new_privs`, then installs a seccomp-BPF filter that eperms proces vm readv/writev, ptrace kernel load. The microVM is the real isolation boundary — seccomp is defense in depth. That said there is a `--privileged` flag that allows that to be skipped for the purpose of image build using buildkit.

Whether pip install works is entirely up to the OCI image you pick. If it has a package manager and you've allowed network access, go for it. The whole point is making `claude --dangerously-skip-permissions` style usage safe.

Personally I've had agents perform red team type of breakout. From my first hand experience what the agent (opus 4.6 with max thinking) will exploit without cap drops and seccomps is genuinely wild.

Creator of Matchlock here. Mostly for performance and usability. For interacting with external APIs like GCP or GitHub that generally have huge surface area, it's much more token-efficient and easier to set up if you just give the agent gcloud and gh CLI tools and the secrets to use them (in our case fake ones), compared to wiring up a full-blown MCP server. Plus, agents tend to perform better with CLI tools since they've been heavily RL'd on them.