Readit News logoReadit News
jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
indigodaddy · 11 hours ago
This is great. Wish this was around when I started working on 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 · 11 hours ago
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.

jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
the_harpia_io · 17 hours ago
defense in depth makes sense - microVM as the boundary, seccomp as insurance. most docs treat seccomp like it's the whole story which is... optimistic.

the opus 4.6 breakouts you mentioned - was it known vulns or creative syscall abuse? agents are weirdly systematic about edge cases compared to human red teamers. they don't skip the obvious stuff.

--privileged for buildkit tracks - you gotta build the images somewhere.

jingkai_he · 13 hours ago
It tried a lot of things relentlessly, just to name a few:

* Exploit kernel CVEs * Weaponise gcc, crafting malicious kernel modules; forging arbitrary packets to spoof the source address that bypass tcp/ip * Probing metadata service * Hack bpf & io uring * A lot of mount escape attempts, network, vsock scanning and crafting

As a non security researcher it was mind blown to see what it did, which in the hindsight isn't surprising as Opus 4.6 hits 93% solve rate on Cybench - https://cybench.github.io/

jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
ssd532 · 17 hours ago
What 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?
jingkai_he · 17 hours ago
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.

jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
DanMcInerney · 18 hours ago
Sandboxing 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 · 17 hours ago
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.

jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
the_harpia_io · 18 hours ago
containers are fine for basic isolation but the attack surface is way bigger than people think. you're still trusting the container runtime, the kernel, and the whole syscall interface. if the agent can call arbitrary syscalls inside the container, you're one kernel bug away from a breakout.

what I'm curious about with matchlock - does it use seccomp-bpf to restrict syscalls, or is it more like a minimal rootfs with carefully chosen binaries? because the landlock LSM stuff is cool but it's mainly for filesystem access control. network access, process spawning, that's where agents get dangerous.

also how do you handle the agent needing to install dependencies at runtime? like if claude decides it needs to pip install something mid-task. do you pre-populate the sandbox or allow package manager access?

jingkai_he · 18 hours ago
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.

jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
pjio · 19 hours ago
If I'm already on Linux, how does it compare to using bubblewrap?
jingkai_he · 19 hours ago
Creator 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-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.

jingkai_he commented on Matchlock – Secures AI agent workloads with a Linux-based sandbox   github.com/jingkaihe/matc... · Posted by u/jingkai_he
__alexs · 20 hours ago
Why would secrets ever need to be available to the agent directly rather than hidden inside the tool calling framework?
jingkai_he · 20 hours ago
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.
jingkai_he commented on Show HN: Opsmate - LLM Powered SRE Assistant   github.com/jingkaihe/opsm... · Posted by u/jingkai_he
jingkai_he · 10 months ago
Hi, I am the creator of opsmate. Here are some interesting use cases of opsmate:

* write prometheus query for you - https://asciinema.org/a/715257

* troubleshoot a kubernetes production issue - https://asciinema.org/a/fNsUcClB2X1hupC8pY3Aatag1

* troubleshoot a remote vm that doesn't have opsmate installed - https://asciinema.org/a/715281

* analyse your database schema - https://asciinema.org/a/3FNuT7JdySxnAM29GUdXuqw6L

Deleted Comment

u/jingkai_he

KarmaCake day65April 13, 2025View Original