Probably. If I remember correctly, containers on Linux are implemented using the kernel's namespaces. The same ones which became famous for the vulnerabilities they surfaced in previously unexercised code.

I'm already using virtdev, my own solution built on top of QEMU.

Thank you, that means a lot !

My pleasure! You can find my fork here: https://github.com/clawkwork/gvisor-tap-vsock — the diff is tiny, just a hook in the TCP/UDP/ICMP forwarders that consults an allow-list before dialing

(Years ago I had puppet and cobbler provisioning VMs over PXE and then iPXE. FWIU foreman is more actively maintained than cobbler, which is built on Django web framework.)

Vagrant manages VMs and virtual networks, in Ruby.

ansible-molecule creates, converges, and destroys VM(s) and containers, in order to test ansible playbooks and ansible roles in clean build roots.

podman machine manages VMs:

- podman-container-tools/podman-machine-os: machine image files: https://github.com/podman-container-tools/podman-machine-os/...

`podman kube play` over `podman machine` might solve for agents that need multiple VMs/containers

- Podman Desktop can work with the same local k8s setups as Docker Desktop. Though there's certainly more state to manage with k8s for agent session farm, k8s probably has better logging and quotas than a VM management script on each node.

OpenShift on OpenStack is one way to do containers over VMs over bare metal.

Microshift also does container-selinux.

There is not an apparmor policy set for containers?

bwrap and liboverlayfs and libseccomp are almost but not quite containers.

There are stronger container isolation layers that are more like a full or lightweight VM, that might be better for agent sessions: gVisor, firecracker vm, Todo

Cloudflare workerd is the open source part of cloudflare workers, which run lightweight WASM and JS VMs with multi-tenant isolation.

It takes far less resources to run a cloudflare worker than to run a container on cloudflare. So, if it's possible for an agent to operate within a WASM runtime ~container, that's probably more optimal for agent sessions.

Cloudflare/artifact-fs does lazy shallow git clones with a FUSE filesystem.

- "Show HN: VM-curator – a TUI alternative to libvirt and virt-manager" https://news.ycombinator.com/item?id=46750437

https://news.ycombinator.com/item?id=46825026 ; amla sandbox, agentvm, ARM64 MTE

https://news.ycombinator.com/item?id=46825119 ; container2wasm , vscode-container-wasm-gcc-example ; build WASM containers with Dockerfiles

docker and podman support multiple WASM runtimes for running WASM containers, e.g. for agent sessiobs

I initially thought that was the case: literally the same weights but with an incredibly obnoxious "safety classifier" tacked on. Now I'm uncertain because people on HN have told me it's a different model altogether with further fine tuning for safety or something.

That's a good idea. I don't have Fable at the moment, when it comes back I'll ochestrate those tests.

Opus did manage to iron out a lot of fail open bugs during development though, and Fable's like a hundred times more relentless than Opus. I'm not saying it's a definitive result or that my VM firewall thingy is unhackable... I'm just saying it put a smile on my face.

The core abstraction seems identical to Fly.io Sprites: give the coding agent its own real Linux machine, put a hard network/isolation boundary around it, then yeet.

Sprites arguably has the better security boundary, since the agent isn’t sitting adjacent to my laptop and home network.

I am developing a super light similar thing here

https://github.com/daitangio/take-ai-control

It is docker + vscode friendly. I tested it with major systems (copilot, codex, Claude Code and pi.dev) Comments Wellcome!

I use mkosi: https://github.com/systemd/mkosi

Which is just a front for systemd-nspawn. It's annoying you have to edit the config.nspawn to mount a directory if you start it with the "shell" command, instead of booting. But apart from that, it's brilliant.

Funny that they're both written independently and in Go. Sometimes there's just a best way to do things I guess

Also the readme (and thus likely the whole thing) is clearly LLM-generated.

Doesn't have to be arbitrary, and managing users requires a lot more nuance (endless permission toggling/configuring) than just running a VM that is more of a whitelist.

And those installed programs could have vulnerabilities that just a non-root user account could still take advantage of. Perhaps not likely for an LLM to do, but more so if you let them loose on the internet and they end up coming across prompt injection that instructs exactly that :)

Seatbelt on macOS and Landlock over WSL2 on Windows 11. Landlock is also built-in, and WSL2 is a first-party downloadable component

that Pi extension, by contrast, gives you a popup whenever an agent tries to access something outside the current working directory and send a network request. that depends on configuration. also if agent tries to ssh into something that will also send a request for access, so child processes are covered

am I doing that once per project, or?

Yep, I broke locate when I made my home 700. Its user could not traverse my files anymore. I had to make it run as root. A better design would be to traverse each user home with that user id but apparently it assumes that the home dirs are 755.

Patched in Linux 7.1.3, which happens to be the exact kernel version I'm running. Update your kernels, folks.

npm, pip, cargo and everything else

All that stuff should also go into the agent user's home directory.

Threat model is supply chain attacks on unmaintained package repositories like npm, pip and cargo. Everything on my host comes from my Linux distribution's repositories. Everything else gets virtualized with extreme prejudice. I'll even virtualize my Steam games one of these days.

IMO the threat model is more letting the agent loose on issues/PRs in a public Github repo and it getting tricked into running a malicious payload.

Also, many of these sandboxing solutions provide features like network allowlists and credential masking/injection

They do try privilege escalation unprompted.

The agent might install hostile software, e.g. a npm package. Unfortunately, very common problem nowadays.

There are documented instances of LLMs casually using LPEs in order to achieve an objective: https://xcancel.com/sluongng/status/2060746160558543217

And that's without anything like prompt injection happening.

Colleague recently told me his agent tried to sudo. It failed but it saw that docker with root is available and just used that. I don't quite remember what it did, I think editing something in /etc.

Mainly networking and namespaces, same reasons why we run services on docker instead of old multi-user setups

And why would I do that when I can create a vm from a snapshot and be done in 30 seconds?

If you think those two contexts are equally secure, your machine is incredibly insecure and I hope you run daily incremental full system backups.

You have far too much data in unsecured locations, and you have far too little understanding of what an agent would do, to go "I trust whatever this user account will be doing on my machine".

There is a reason why VMs even are a thing at all: they can offer better security guarantees than alternatives.

A separate user is a good start but LLM tests themselves show they can cleverly bypass guardrails if they figure out they are in a sandboxed environment of some kind, right?

So, I read those test results as: an LLM is less likely to do something crazy if it thinks it has the whole environment to itself.

There are two sides to this. The first is security, which plenty of comments already covered. The second, and the real one for me: my tests spin up Docker containers, and I was building a Kubernetes tool (argocd/flux style) that needs a real cluster in the sandbox. In a container that means Docker-in-Docker, which always felt hacky. A VM is just a normal Linux box where Docker and k8s run like they do everywhere else. A separate user can't give you that, it shares your one kernel and whatever's already installed on the host.

Hadn't seen yoloai before. I really like new/diff/apply/destroy workflow, that's interesting. For my own needs the two things I was after were multi-repo worktrees (one sandbox spanning several repos, each on with its own worktree) and a single network restricted VM path I fully control, rather than many backends (I started with many backends at first but it was awkward to add network filtering to them). Lots of overlap though, nice work, and I'll be reading through yours.

why not just use something like smol VMs? So many VM's and I am confused on which one to use for what. I think we now need a VM orchestrator!

how does this compare with the aws lambda microvms?

Yet another one, only I wrote this one, so I prefer it: https://github.com/pjlsergeant/byre

You might prefer byre's simplicity, transparency, and ease of reasoning about: one local container, explicit access grants, readable generated Docker, and a workflow that stays close to normal development rather than introducing a larger sandbox platform. It's also very very easy to eject from if you want to stop using it.

Yes, Codex has its own sandbox which you can disable: https://learn.chatgpt.com/docs/sandboxing?surface=app

Cursor has something similar. I don't know about Claude Code but I assume it does as well since Anthropic has open sourced their own sandboxing tool.

It looks like they have the right idea but their workspaces are based on GitHub worktrees rather than separate VM’s.

Yeah but I ‘d rather run it remotely and not run agents on my laptop at all.

but building this vs buying 50 VMs from exe.dev for $20/mo doesn't add up for me.

Assuming they never raise their prices (which they almost certainly will), you'll pay $240 per year for this. For that price you could pick up a second hand Mac mini today, though not bleeding edge I guess.

Local first is also a feature, for work you often can't run company code on a remote VM that isn't company owned. Remote dev envs are on the roadmap though, that's one of the reasons why I designed the declarative clawk.mod manifest

But that's the it!

You quietly dropped rollbacks and the lethal trifecta from your list, the two exact things my project is great at. It's got qcow2 delta images and a fully customizable egress firewall backed by standard nftables.

You substituted in application proxies and firewalls for package repositories. Implementing those is what I came to this thread for. Already planning a custom network stack to replace passt. It will have those features soon. Credential management too.

It doesn't do anything all the other solutions don't already do

That's just false. I built virtdev because I literally didn't find any other tool that implemented KVM virtualization, cheap expendable contextual VMs and configurable egress firewall with minimal, soon to be zero root access requirements. Virtdev also manages daemon life cycle correctly via user mode systemd, which is something I just don't see other projects do.

Vagrantfile and OS agnosticism are not why I built virtdev. Vagrant has no security focus at all, and I explicitly opted out of declarative YAML because GitHub Actions is painful enough.

since it's not built-in

By this logic, no composable tool has any value. I chose to provide mechanism, not policy. The primitives are there.

it's another component the user will need to bring with them

Yes, as files committed to a dotfiles repository. A one time configuration.

shameless plug (im a contributor to): https://github.com/jskswamy/aide/ covers you, with configuration driven through yaml and credential management with sops.

Isn’t the point of LLM to recreate the wheel?

No libraries, no frameworks. Let AI recreate it from scratch … every time

Yeah, but I explicitly chose to make my own anyway because I wanted to fully own the code and none of the existing solutions worked the way I wanted.

There is absolutely nothing wrong with reinventing the whell. It's entirely possible to do it and end up discovering you've made a better wheel.

`vagrant snapshot` exists.

everyone loving these linux sandboxes, even Apple wrote one https://github.com/apple/containerization/tree/main/examples...

I also wrote one where you can choose to use a container or a vm, with a MITM proxy on top https://github.com/agentcage/agentcage

mostly macOS out of the box. I've tested it on linux and it worked but it's not my daily driver. I'll make the platform scope clearer in the README

A lot of the work that coding agents do requires tons of random access to files, which MacOS is particularly slow at. Not because the hardware is bad, mind you. Mac SSDs are amazing. It’s the file system. Secondly, MacOS supervises processes for security reasons and coding harnesses spawn tons of processes. There is a lot of CPU overhead embedded in that supervision.

That's actually how clawk runs it: the agent process (claude/codex) runs inside the Linux guest on a PTY, not on macOS

Is there anyone who is NOT building another AI sandbox solution?

When firing up agent VMs for my personal projects, I tried to completely separate SSH keys as well. Surprisingly annoying to have multiple keys for, say GitHub, and restrict the agent to use a deploy key.

I saw this project enables ssh-agent forwarding, so my question; is this a non-issue to begin with? Or just not your focus currently.

Is it similar to devcontainers?

Ah, that makes sense. I've only recently started playing with this stuff, and I've been focusing a lot of just getting somewhat good at using LLMs for projects while developing my own intuition, so everything I do just uses the mounted project and uv directly. As soon as things get more complex, I imagine I'll end up with a full wrapper as well.

Unrelated: I enjoyed your latest blog entry. I recently starting thinking about how to show the work that is done with AI, and how we talk about it. I haven't come to any major conclusions (I wish!), but your post about the prompting being distinct from the actual work resonates with me. Reminds me somewhat of discussions about the art of photography compared to the art of editing photos as a distinct skill.

I restrict networking via my pfSense router, using VLANs. I also don't include any credentials in the container; the agents there can't push, pull, or really access anything else beyond the standard tools without any authentication.

I don't use Claude or any other paid agent at the moment, so if that were to change I'd probably modify the way I run this, but with this simple set up I'm not too worried about credentials leaking.

On your own machine that leaves two bad options. You approve every command (and babysit a prompt every few seconds), or you run --dangerously-skip-permissions and hope nothing important is one rm -rf or one leaked token away.

Literally everyone has the option to use a VM - it's built into Windows, UTM on MacOS, Docker on Linux. Yes, "a tool that automatically builds a VM" is useful, but we've had a third option (four, if you count "actually I disagree with the idea that it's only useful if it's fully agentic") from day one.

The network stack and virtual filesystem are implemented entirely in JavaScript

This is slightly insane

I suppose it will be slow too if the agent needs to grep over megabytes of data

Exactly the same setup for me. It works great and the whole setup consists of a single Vagrantfile which I maintain via Claude itself. All relevant dotfiles are synced to a folder on the host so e.g. conversations are preserved across reprovisioning of the VM. It's a simple solution, but very flexible.

quickemu[0] is sort of amazing for these type of use cases actually. I feel like I could use it more for this type of stuff.

[0]: https://github.com/quickemu-project/quickemu

does eBPF be serving for security enough? ec2 is heavy in terms of cost while containarium (https://github.com/FootprintAI/Containarium) can achieve both, safe & cheap.

What does Clawk do that Docker without exposed ports doesn't?

I use a raspberry pi for all my experiments

Or give them a dedicated user and you don't lose precious CPU cycles to run a VM/container: http://github.com/tarsgate/skynot

Check the 2nd section of article https://github.com/clawkwork/clawk#why-a-vm

A lot of people would yell "docker isn't secure!" but if you're running Docker on MacOS (and Windows, I think) you're already running a Linux VM. But if you really wanna let your agent YOLO their way along, Docker is kinda restrictive, so that a full VM lets it install things, start services, and so on.

i was quite shocked to learn that cursor is not scoped to current workspace, recently it just traversed my projects dir outside my current workspace and looked for patterns in code.

Amazing idea! Need to try that.

It was leveraging apple container in the first versions. They have the same foundation VZ (Virtualization.framework), build one container per VM. The reason I stayed with raw VZ instead of apple container is the network filtering feature

WDYT of yolobox ? https://github.com/finbarr/yolobox

I used lxc many years ago and used to support it in my company's products, but for this use case, bubblewrap is the obvious answer. It's exactly the right balance of isolation and simplicity. Any full container or VM thing is much heavier than a namespace with some bind mounts, which is what bubblewrap does.

I started out implementing it with podnan, but that's also far too heavy and complicated, as you need to equip it for your specific development needs. With bubblewrap (and, thus, flar) you gave your usual environment, the whole OS mounted read only, but anything sensitive in your home or other dirs that might be sensitive is unreachable.

The way I did it, I've got a convention where I store git checkouts in a specific directory on my laptop. I use the repo name as an argument and the wrapper script creates / shells into the per-project VM.

It uses cloud-init for the initial setup and injects the agent's config file and some other stuff in a ro mount from my laptop. That single subdirectory is mounted rw into a conventional location inside the VM. I inject only credentials to e.g. test environments that don't matter if they're exposed. The agent context instructs it that it can use full sudo and install any utilities from apt that it needs.

So for the ux I do incus-dev-vm.sh shell <projname> or incus-dev-vm.sh opencode <projname> etc.

A fun thing about this is I used nested virt to have the agent write the script - so I spooled up an incus VM myself first, then the agent can run with full privs inside there creating nested VMs to ensure its functionality.

Right now I'm not filtering anything on the VM - with my threat model only limited access is granted and I don't give creds to touch real infra. But you should be able to filter it on the host (I haven't researched the best approach however).

containarium did the same thing with lxc as a container isolation and use eBPF for network safeguard. https://github.com/FootprintAI/Containarium

+1 to Incus. In fact, our meta-harness of sorts, Sail, is built using Incus. The vision was to have Sail do for coding agents roughly what Kubernetes does for containers, i.e., orchestrating and dispatching engineering work to CC/Codex etc. Our small team of engineers has found decent success with this approach.

Our nixos sandboxes are mostly a cloud offering at this time. Scale is what we can offer additionally. Have secret injection built in too. I see you have suspend, resume we have the same. We have snapshots and cloning. Startup time is sub second with warm pools - which will go further down when we replace firecracker with Tarit soon.

1. Tarit - https://GitHub.com/instavm/tarit

Nice I started to vibecode something with bwrap.nix: https://github.com/riedel/nix-opencode-with-mitm (not anywhere near production ready) What I would really want is token injection outside the sandbox and good control over the network, why I tried integrating a mitm proxy outside the sandbox.

Made the exact same thing when apple containers were released - https://github.com/instavm/coderunner#run-claude-code-inside...

Ok! why should I switch away from running Firejail on Fedora? Ok SUID security thanks

Claude Cowork does this on Mac and ears several gigabytes of on disk storage, drives me crazy, because it does this if you click on it without ever using it.

Fly.io’s sprites.dev is a similar idea but on their hardware and you get a public/private domain to run a server too, I’ve found it pretty good.

Hey thanks for the question. I would like to answer it in a more descriptive manner with an example later.

Classifying a command can be a bit of a misnomer because it has two inherent problems:

1. You need a classifier. That means the security boundary becomes “can I trick or bypass the classifier?” Whether it is a smaller model or a pile of regexes, it will eventually have edge cases.

2. The token economics do not work, and it also needs to be fast. I do not want an eval evaluating another eval for every command.

So the approach I took is closer to how we normally build security systems: secure defaults and deterministic boundaries.

For example, to protect secrets, AgentJail can block access to paths like `~/.ssh`, `~/.aws/credentials`, `.env`, etc. at the OS level.

The OS is the deterministic boundary here. The ring-0 enforcement layer.

The more interesting problem is network access. You may genuinely want the agent to debug a production Kubernetes cluster, inspect an AWS resource, or query a production database. A blanket network deny would make the agent useless.

For that, I am taking a protocol-aware DSL approach. Something like:

``` deny if { request.host == "api.github.com" request.method == "POST" startswith(request.path, "/repos/") endswith(request.path, "/git/refs") }

ask if { request.host == "kubernetes.default.svc" request.method == "DELETE" }

allow if { request.host == "api.github.com" request.method == "GET" } ```

So instead of trying to classify whether a command is “dangerous,” the policy describes exactly which resources and operations are allowed, denied, or require approval.

The agent can still be probabilistic. The enforcement boundary should not be.

Does that answer to your question?

You mean, I should stop posting much about it ? Is it too aggressive posting Am sorry about that.

I'm afraid not. My impression is, most are just prompting for the tool they need right now, accept bugs and maybe even security gaps, but save time and pain not searching for an established tool. Which is fine and understandable for private things. But I wonder, how often this happens in professional environments. But maybe I'm just wrong... I have not seen any resarch or evaluation for this claims. Would be interesting, though

Really cool project. It's fascinating to see more developers pushing back against the complexity of modern container orchestrators.

This open-sourced project called Containarium (https://github.com/FootprintAI/Containarium) recently did with a very similar philosophy: keeping container environments lightweight, simple, and highly portable.

also support MCP and eBPF for convience and security too.

Been working on something similar, love to see more project in this area

I've been building watch.ly[0] which intercepts all network /fs traffic on the machine originating from the agent and pings you for approval.

[0] https://watch.ly