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.
I don't think the current filepath.Join in realfs.go protects the host against a malicious guest, at all. I'm assuming this is configured as Guest --FUSE--> guest-fused (inside VM) --VSOCK--> realfs.
(The Firecracker people have explicitly refused to have virtio-fs, to keep it minimal: https://github.com/firecracker-microvm/firecracker/pull/1351...)
https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc0...
https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc0...
https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc0...
[0]: Well, I already know I won't trust hanwen/go-fuse with my data, so that part is a bit moot.
* The definitions of security config in the documentation of settings.json are unclear. Since it's not open source, you can't check the ground truth.
* The built in constructs are insufficient to do fully whitelist based access control (It might be possible with a custom hook).
* Security related issues go unanswered in the repo, and are automatically closed.
Haven't looked into copilot as much but didn't look great either. Seems like the vendors don't have the incentives to do this properly.
So I'm on the lookout for a better way, and matchlock seems like a contender.
here's a Go binding: https://github.com/mishushakov/libkrun-go
demo (on Mac): https://x.com/mishushakov/status/2020236380572643720
Because I myself am never going to anything else ever again, unless it's a derivative of the same idea, because it's the only one that makes sense
https://github.com/obra/packnplay
https://github.com/strongdm/leash
https://github.com/lynaghk/vibe
(I've been collecting different tools for sandboxing coding agents)
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.
2. lxd VMs are QEMU-based and very heavy. Great when you need full desktop virtualization, but not for this use case. They also don't work on macOS.
Using Apple virtualization framework (which natively supports lightweight containers) on macOS and a more barebones virtualization stack like Firecracker on Linux is really the sweet spot. You get boot times in milliseconds and the full security of a VM.
There are also tooling on Linux to do containers as microvm's, long before Apple containers were a thing.
1. Firecracker is still a smaller more deliberate surface area 2. qemu didn't have a microvm type at the time. Firecracker was the impetus for it
Where do the images come from? What are our options around that and also using custom images etc?
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.
See https://blog.alexellis.io/how-to-run-firecracker-without-kvm...
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.
Just as Docker became the de facto standard for cloud containerization, we are seeing a lot of solutions attempting to sandbox AI agents. But imo there is a fundamental difference: previously, we sandboxed static processes. Now, we are attempting to sandbox something that potentially has the agency and reasoning capabilities to try and get itself out.
It’s going to be super interesting (and frankly exciting) to see how the security landscape evolves this time around.
The threat model for actual sandboxes has always been "an attacker now controls the execution inside the sandbox". That attacker has agency and reasoning capabilities.
1. from isolation pov, Matchlock launch Firecracker microvm with its own kernel, so you get hardware-level isolation rather than bubblewrap's seccomp/namespace approach, therefore a sandbox escape would require a VM breakout.
2. Matchlock intercepts and controls all network traffic by default, with deny-all networking and domain allowlisting. Bubblewrap doesn't provide this, which is how exfiltration attacks like the one recently demonstrated against Claude co-work (https://www.promptarmor.com/resources/claude-cowork-exfiltra...).
3. You can use any Docker/OCI image and even build one, so the dev experience is seamless if you are using docker-container-ish dev workflow.
4. The sandboxes are programmable, as Matchlock exposes a JSON-RPC-based SDK (Go and Python) for launching and controlling VMs programmatically, which gives you finer-grained control for more complex use cases.
No because it's a dumb question and you don't want any stranger inside your home network regardless of firewall.
The comparison you get to make is in terms of the _extra_ security this project buys you.
Might I remind you of two things:
- You're advocating for installing random (?kernel) level software from the internet. That by itself is a real and larger treat than any potentially insecure things my `llm` user _might_ do in the future.
- User accounts security was the goto method for security for a long time. Further isolation was developed to accommodate: 'root' access for tenants, and finer resource limits controls. Neither I care to give an LLM.
So we only have build in firewall and sandbox duplication as the real feature. For the latter, my experience is that it's useless on a personal device, and slows down building or requires too much cache config. I'm not installing random crap, so i can live with the risk of lan exposure.
I'm happy with the maintenance/complexity/threat matrix of useradd.
AWS/GCP/Azure allow that all day every day.
So useradd isn't enough.