matchlock

I think matchlock ( https://github.com/jingkaihe/matchlock ) is the right design for this context (at least for secrets and keys) - a combination of virtual machines (not just containers, it is built on top of firecracker) with credential swapping just like iron proxy - the agents do not have access to the secrets at all but they receive placeholders instead and their network calls are intercepted and secrets are injected when the network requests happen... still does not solve the exfiltration problem you mentioned, though.

There are a number of utilities for this. I use jai: https://jai.scs.stanford.edu/ but also have seen nono: https://github.com/always-further/nono smolvm: https://github.com/smol-machines/smolvm zerobox https://github.com/afshinm/zerobox and matchlock https://github.com/jingkaihe/matchlock They all have pros and cons. Pick the one that suits you best. Then you're also agent harness flexible (I use opencode).

Matchlock[0] is probably the best solution I've come across so far WRT problem 1 and 2: > Matchlock is a CLI tool for running AI agents in ephemeral microVMs - with network allowlisting, secret injection via MITM proxy, and VM-level isolation. Your secrets never enter the VM. In a nutshell, it solves problem #2 through a combination of a network allowlist and secret masking/injection on a per-host basis. Secrets are never actually exposed inside the sandbox. A placeholder string is used inside the sandbox, and the mitm proxy layer replaces the placeholder string with the actual secret key outside of the sandbox before sending the request along to its original destination. Furthermore, because secrets are available to the sandbox only on a per-host basis, you can specify that you want to share OPENAI_API_KEY only with api.openai.com, and t

I've been collecting a list of sandboxing related projects as well, some lower level than others. I wish I had time to evaluate them all: - https://github.com/jingkaihe/matchlock - https://github.com/mishushakov/libkrun-go - https://github.com/earendil-works/gondolin - https://github.com/butter-dot-dev/bvisor - https://github.com/amlalabs/amla-sandbox - https://github.com/eryx-org/eryx - https://github.com/containers/bubblewrap (not new) - https://github.com/coplane/localsandbox - https://github.com/sd2k/conch - https://github.com/Gerharddc/litterbox - https://github.com/finbarr/yolobox - https://github.com/coventry/sandbox-codex - https://github.com/osks/ctenv - https://github.com/tianon/gosu - https://github.com/colony-2/shai - https://github.com/rcarmo/agentbox - https://github.com/coder/httpjail - https://github.com/bytecodealliance/c

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

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