Matchlock – Linux 기반 샌드박스로 AI 에이전트 워크로드를 보호합니다.

Matchlock – Secures AI agent workloads with a Linux-based sandbox

110 pointsby jingkai_he2026. 2. 8.43 comments

요약

Matchlock은 AI 에이전트 워크로드의 보안을 강화하기 위해 설계된 새로운 CLI 도구입니다. 이 도구는 격리되고 일회용인 Linux 마이크로VM 내에서 AI 에이전트를 실행하여, 민감한 자격 증명과 네트워크 접근이 기본적으로 엄격하게 제어되도록 합니다. 이 도구의 아키텍처는 비밀 정보가 VM에 절대 들어가지 못하게 하여, 코드를 실행해야 하는 에이전트에게 안전한 환경을 제공합니다.

__alexs•7시간 전

Why would secrets ever need to be available to the agent directly rather than hidden inside the tool calling framework?

[삭제된 댓글]

jingkai_he•7시간 전

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.

rfoo•6시간 전

Sometimes 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_•6시간 전

Exactly.

athrowaway3z•6시간 전

Have I told you about our lord and savior: `useradd`

CuriouslyC•5시간 전

Would you let a pro blackhat loose on your system with just a different user account?

ushakov•6시간 전

very 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

demo (on Mac): https://x.com/mishushakov/status/2020236380572643720

pjio•6시간 전

If I'm already on Linux, how does it compare to using bubblewrap?

jingkai_he•5시간 전

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.

raphinou•5시간 전

I'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

0x696C6961•5시간 전

I 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/

the_harpia_io•5시간 전

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?

ushakov•5시간 전

just from looking at it

on Linux it runs Firecracker: 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/darw...

jingkai_he•4시간 전

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.

insuranceguru•4시간 전

sandboxing is really the only way to make agentic workflows auditable for enterprise risk. we can't underwrite trust in the model's output, but we can underwrite the isolation layer. if you can prove the agent literally cannot access the host network or sensitive volumes regardless of its instructions, that's a much cleaner compliance story than just relying on system prompts.

muyuu•4시간 전

This 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".

robotswantdata•4시간 전

Sandbox won’t be enough, distroless + “data firewall” + audit

DanMcInerney•4시간 전

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•4시간 전

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.

[삭제된 댓글]

ssd532•4시간 전

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•3시간 전

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.

paxys•3시간 전

1. 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.

zachdotai•3시간 전

I 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•3시간 전

I 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).

ajb•3시간 전

We 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•3시간 전

Claude sandbox practically useless IMO. It gives read access to everything by default so its not deny-default.

cjbarber•3시간 전

Matchlock – Linux 기반 샌드박스로 AI 에이전트 워크로드를 보호합니다.

요약

댓글 (48)