11 ms·
Matchlock – Secures AI agent workloads with a Linux-based sandbox
- __alexs 8mo agoWhy would secrets ever need to be available to the agent directly rather than hidden inside the tool calling framework?
- deleted 8mo ago[deleted]
- jingkai_he 8mo agoCreator 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.
- rfoo 8mo agoSometimes people are too lazy to write their own agent loop and decided to run off-the-shelf coding agent (e.g. Claude Code, or Pi in case of clawdbot) in environment.
- _pdp_ 8mo agoExactly.
- athrowaway3z 8mo agoHave I told you about our lord and savior: `useradd`
- CuriouslyC 8mo agoWould you let a pro blackhat loose on your system with just a different user account?
- athrowaway3z 8mo agoYou'd let the pro blackhat loose in your VM on your own system? 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.
- dist-epoch 8mo ago> You'd let the pro blackhat loose in your VM on your own system? AWS/GCP/Azure allow that all day every day.
- rvz 8mo agoUntil you are (or if the agent runs) one privilege escalation away from the whole system being taken over. So useradd isn't enough.
- ushakov 8mo agovery cool, if you want cross-platform microvms, there's an interesting project called libkrun that powers projects like Podman and Colima. here's a Go binding: https://github.com/mishushakov/libkrun-go https://github.com/mishushakov/libkrun-go demo (on Mac): https://x.com/mishushakov/status/2020236380572643720 https://x.com/mishushakov/status/2020236380572643720
- codethief 8mo agoSince when does libkrun power Podman? Last time I checked, Podman used non-virtualized containers based on `crun`.
- codethief 8mo ago(Though you can certainly configure Podman to use krun[0], which fires up a libkrun VM inside a crun container.) [0]: https://github.com/containers/crun/blob/main/krun.1 https://github.com/containers/crun/blob/main/krun.1
- tyfnll 8mo agoOP may be referring to `podman machine` on macOS, which gives access to containers through a Linux VM via libkrun.
- pjio 8mo agoIf I'm already on Linux, how does it compare to using bubblewrap?
- jingkai_he 8mo agoCreator here. A few key differences: 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-exfiltrates-files 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.
- pjio 8mo agoThanks! I will keep it in mind as an even more secure alternative.
- raphinou 8mo agoI've been happily using a container to run my agents [1]. I tried to make it evolve with more advanced features, but it quickly became harder to use and I went back to a basic container which I just start with a run.sh script. Is a similar simple use possible with matchlock? 1:https://github.com/asfaload/agents_container https://github.com/asfaload/agents_container
- 0x696C6961 8mo agoI use a very similar setup. I initially used nix to manage dev tools, but have since switched to mise and can't recommend it enough https://mise.jdx.dev/ https://mise.jdx.dev/
- pmarreck 8mo agodoes mise use nix underneath or did you abandon nix entirely?
- rsyring 8mo agoMise doesn't use nix. I think the OP is stating he replaced nix with mise.
- pmarreck 8mo agoYeah I'm just confused why someone would go from a completely deterministic dependency management system back to a dice-rolling one especially when LLM's now exist where all the top tier ones are excellent at the Nix language 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
- the_harpia_io 8mo ago[flagged]
- ushakov 8mo agojust from looking at it on Linux it runs Firecracker: https://github.com/jingkaihe/matchlock/blob/main/pkg/vm/linux/backend.go#L107-L110 https://github.com/jingkaihe/matchlock/blob/main/pkg/vm/linu... on macOS uses the Apple's Virtualization.Framework Go wrapper: https://github.com/jingkaihe/matchlock/blob/main/pkg/vm/darwin/backend.go#L12 https://github.com/jingkaihe/matchlock/blob/main/pkg/vm/darw...
- the_harpia_io 8mo ago[flagged]
- jingkai_he 8mo agoCreator 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.
- TheTaytay 8mo agoThank you for matchlock! I’ve got Opus 4.6 red teaming it right now. ;) I think a secure VM is a necessary baseline, and the days of env files with a big bundle of unscoped secrets are a thing of the past, so I like the base features you built in. I’d love to hear more about the red team breakouts you’ve seen if you have time.
- engelo_b 8mo ago[dead]
- muyuu 8mo agoThis may sound obvious, but there must also be an enforcement of what's allowed into that sandbox. I can envision perfectly secure sandboxes where people put company secrets and communicate them over to "the cloud".
- engelo_b 8mo ago[dead]
- robotswantdata 8mo agoSandbox won’t be enough, distroless + “data firewall” + audit
- richardlblair 8mo agoIndeed, but a rock solid sandboxing and isolation strategy is step 0.
- DanMcInerney 8mo agoSandboxing is a great security step for agents. Just like using guardrails is a great security step. I can't help but feel like it's all soft defense though. The real danger comes from the agent being able to read 3rd party data, be prompt injected, and then change or exfiltrate sensitive data. A sandbox does not prevent an email-reading agent from reading a malicious email, being prompt injected, and then sending an email to a malicious email address with the contents of your inbox. It does help in implementing network-layer controls though, like apply a policy that says this linux-based sandbox is only allowed to visit [whitelisted] urls. This kind of architectural whitelisting is the only hard defense we have for agents at the moment. Unfortunately it will also hamper their utility if used to the greatest extent possible.
- jingkai_he 8mo agoCreator 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.
- deleted 8mo ago[deleted]
- ssd532 8mo agoWhat are the advantages of using this over lxd system container or if we want VM isolation them lxd VMs? Is it the developer experience or there are any agent specific experience which is the key thing here?
- deleted 8mo ago[deleted]
- jingkai_he 8mo agoThe 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.
- paxys 8mo ago1. Containers aren't a security boundary. Yes they can be used as such, but there is too much overhead (privilege vs unprivileged, figuring out granular capabilities, mount permissions, SELinux/AppArmor/Seccomp, gVisor) and the whole thing is just too brittle. 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.
- cpuguy83 8mo agoqemu has a microvm machine profile, also boots in ms. There are also tooling on Linux to do containers as microvm's, long before Apple containers were a thing.
- zachdotai 8mo agoI think for the first time ever, we are facing a paradigm shift in containment/sandboxing. 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.
- idiotsecant 8mo agoI have been saying for years that technology increasingly requires the development of memetic firewalls - firewalls that don't just filter based on metadata, but filter based on ideas. Our firewalls need to be at least as capable as the entities it seems to keep out (or in).
- CuriouslyC 8mo agoThat sort of firewall is going to be really expensive to run, to the point that it's a financial DOS vulnerability. What is feasible is simpler algorithms that emit alerts on a baseline pattern match, which then get routed to AI observers after some trigger threshold for mitigation. I wouldn't be surprised if someone has already deployed something like that, TBH.
- mejutoco 8mo agoI think a sandbox containing a program should only output data. And that data should conform to a schema. The old difference between programs and data instead of turing-complete languages everywhere.
- kittbuilds 8mo ago[dead]
- yencabulator 8mo ago> Now, we are attempting to sandbox something that potentially has the agency and reasoning capabilities to try and get itself out. 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.
- ajb 8mo agoWe definitely need a vendor-independent tool like this. Have been reviewing the Claude setup and, despite initially being hopeful since it uses bubblewrap, it's quite problematic: * 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.
- arianvanp 8mo agoClaude sandbox practically useless IMO. It gives read access to everything by default so its not deny-default.
- CuriouslyC 8mo agoThere are a lot of options in this space. Armin Ronacher is working on Gondolin (https://github.com/earendil-works/gondolin https://github.com/earendil-works/gondolin) for example. I built agentd as a layer in front of this stuff so you can expose secure shell capabilities over the network as a tool rather than baking it into the harness, or running the harness in that environment.
- cjbarber 8mo agoSee also: https://github.com/obra/packnplay https://github.com/obra/packnplay https://github.com/strongdm/leash https://github.com/strongdm/leash https://github.com/lynaghk/vibe https://github.com/lynaghk/vibe (I've been collecting different tools for sandboxing coding agents)
- indigodaddy 8mo agoLeash looks quite interesting thanks for posting
- robcholz 8mo ago[dead]
- throwaw12 8mo agoThis is very cool, is it possible to mount NFS as a storage layer?
- kittbuilds 8mo ago[dead]
- clarity_hacker 8mo agoThis is the confused deputy problem at the application layer. Sandboxing secures the environment, but if the agent has legitimate access to sensitive operations (email, database writes, API calls), prompt injection attacks work through approved channels. The only hard defense is explicit user confirmation for each action, which defeats the point of autonomy.
- stogot 8mo agoIs this just a copycat of the deno soundbox announcement from a few days ago?
- indigodaddy 8mo agoThis is great. Wish this was around when I started working on vibebin ( https://github.com/jgbrwn/vibebin https://github.com/jgbrwn/vibebin ), probably would have leveraged matchlock instead of Incus/LXC. I guess I could fork/branch and give it a go! Although for vibebin use case I actually need them to not be ephemeral. Edit, ooooh i see `--rm=false` nice Where do the images come from? What are our options around that and also using custom images etc?
- jingkai_he 8mo agoCreator 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.
- indigodaddy 8mo agoThanks for the response! How would matchlock microvms perform on a KVM VM without CPU passthrough, or is it not possible?
- jingkai_he 8mo agoI'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.
- indigodaddy 8mo agoAny chance you could look into potentially adding the option to use PVM (eg so a PVM mode instead of KVM) in your matchlock/firecracker implementation? See https://blog.alexellis.io/how-to-run-firecracker-without-kvm-on-regular-cloud-vms/ https://blog.alexellis.io/how-to-run-firecracker-without-kvm...
- 8mo ago
- pipejosh 8mo ago[dead]
- yencabulator 8mo agoHuh. You're converting FUSE requests into your own custom protocol (with copy-pasted protocol definition) over vsock. Interesting. Not sure I'd trust it with my data[0], but interesting. 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#issuecomment-667085798 https://github.com/firecracker-microvm/firecracker/pull/1351...) https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc060a46f9628d9cb11a0dc0283/cmd/guest-fused/main.go https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc0... https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc060a46f9628d9cb11a0dc0283/pkg/vfs/server.go https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc0... https://github.com/jingkaihe/matchlock/blob/123a4df680fb8cc060a46f9628d9cb11a0dc0283/pkg/vfs/realfs.go 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.
- robcholz 8mo ago[dead]
- vivzkestrel 8mo agoif you wanted to run this serverlessly on AWS how would you go about doing that?
- that_guy_iain 8mo agoThis is well cool, I swear to god a couple of kickass devs told me about this idea to get me to build it to build something cool. It's even cooler, since I kinda went in another direction and I'm going to build a container.d like system with an compatible API to run natively on Windows and Mac. I'm going to call it container.x but maybe something else.
- pipejosh 8mo agoSandboxing the filesystem is one layer but egress scanning is where it gets interesting. An agent inside a sandbox can still exfiltrate secrets through any HTTP request it's allowed to make. The request looks totally legitimate from the sandbox's perspective. You need something actually inspecting the content of outbound traffic for credential patterns.
- pipejosh 8mo ago[dead]