With agentjail ( https://github.com/LuD1161/agentjail ), I've tried to contain coding agents in os-native sandboxes (sbpl for macos and similarly for linux, <4ms start time) + policy guardrails evaluated by Open Policy Agent (OPA), policies written in rego.

Protocol aware network proxy coming soon Then you can match a DSL and block particular network requests.

This ensures you no longer fear --dangerously-skip-permissions and stop babysitting agents

What else would you want to see in this project? Please star the repo, if you like the idea :)

I think the most secure setup, though not so convenient for the average user, is a separate machine with QEMU/KVM. The machine should be isolated adequately, such that even if compromised, it shouldn't be able to cause damage or gain access to other machines. Additionally, a proxy server on your machine or elsewhere could hide sensitive credentials. A helper binary on your computer would then control spawning new disposable VMs with premade images and your SSH key. The images can be lightweight or the desktop version with a remote VNC.

I was using VMs for agents, but wanted something lighter and faster, so I made flar, which bubblewraps the agent, its config/history and the project directory. The agent runs in your usual environment but has no access to anything other than what it's been explicitly granted, short-circuiting prompt injections (or intentional secret exfiltration on the part of the agent or model) as well as any supply chain exploits the agent might accidentally introduce.

https://github.com/swelljoe/flar

It starts instantly, as it's a namespace, rather than a full VM or container that has to be downloaded/built/updated on start.

It defaults to dangerously skip permissions mode, but is much safer than the very porous sandbox the agents provide, and the agent can't reach outside of it even if told to, by the user or a prompt injection.

I am certainly no expert in this space so it is quite possible I'm missing something critical, but what seems to work for me is a Podman image I built on my computer with some basic things I need (using OpenCode, but I imagine any other agent could be used instead):

  FROM docker.io/archlinux:base
  RUN pacman -Syu --noconfirm && \
      pacman -S --noconfirm \
      base-devel \
      git \
      curl \
      uv \
      opencode && \
      pacman -Scc --noconfirm
  RUN mkdir -p /etc/opencode 
  WORKDIR /workspace

From there I just run the Podman image from the command line (using a Fish function) that mounts the specific project I'm working on to /workspace. I guess there might be some vulnerabilities with shared kernels and such, but it seems like an easy way to have some isolation.

> clawk forward add my-project 3000

> clawk network allow my-project api.example.com

Can you describe the implementation details? How did you implement the firewall without root?

I vibecoded virtdev, a virtual machine orchestration project just like this one:

https://github.com/matheusmoreira/virtdev

It was designed to not require root, and the nftables firewall ended up becoming the only exception. I'm very curious about how you implemented this. Did you find a better way?

yoloAI does something similar:

- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker

- Sandbox on Mac using Docker (Docker Desktop or Orbstack), Podman, Apple containers, Seatbelt, Tart (Tart lets you run simulators).

- Network restriction

- Secrets control (file mounts or credentials broker)

- NO ambient data (ENV is replaced with a minimal and local-to-sandbox one, no host-side filesystem access beyond what you explicitly allow)

- Workdir protection: Your work dir is never modified until you apply the changes, either standalone or as a git commit. You can also diff before applying. Git runs SANDBOX side in case the repo has filters.

- Uses copy-on-write if your filesystem supports it (most modern ones do)

- Has built-in support for claude, codex, gemini, aider, and opencode, but you can also launch it in "shell" mode and run whatever you want.

- Supports VS code tunnels, so you can remotely access in VS code if you don't want to use the terminal.

- Full lifecycle support: Launch, attach, stop, restart, wait, one-shot, clone, destroy

- MCP passthrough

- Layered API (golang) if you want to sandbox other things

- Self-contained binary. No external requirements other than the backends you want to use. Defaults to a ~/.yoloai dir for config/data, but you can point it anywhere.

- FOSS

https://github.com/kstenerud/yoloai

If you are a Nix flake enjoyer, I whipped up something similar to this (Claude Code-only right now) based on microvm.nix: https://github.com/cdata/katsuobushi/tree/main/lib/sandbox

Some highlights:

- Drives Claude Code as a quasi-subagent via "Channels," which supports multi-turn interaction with the host and suspend / resume

- Declarative configuration in the flake of exactly what is copied into the VM (besides the local project), what DNS origins are allowed, etc.

- Shared access to host Nix store / object DB via overlay FS

- Syncs code with the host over a shared (local) Git remote (no worktree mess to manage)

- Devshell commands for quickly dropping into the guest and viewing status of all VMs etc.

- VMs start in a couple of seconds

I just use kubernetes with a single PVC for the Claude folders. Works like a charm. Don’t need too much else. You can then start separate pods with different PVCs to different folders. Lives on a server, I can manage the auth by just making each pod description different.

Honestly works fine and you can use /rc to talk to them over the Claude phone app.

We need an agentic platform that has sandboxing built-in well. Giving agents a disposable VM is nice but I'm already hitting my Mac mini's space limit.

If the agent is running on your machine, it will suspend when you put your laptop asleep. I prefer using a remote Linux VM to let the coding agent keep working.

I’m quite happy with exe.dev for this. My laptop is asleep upstairs but I have an agent coding away in a browser tab on the tablet I’m using. I could also check on it from my phone.

But it might also be nice if a setup similar to exe.dev were available for self-hosting. I have a Mac Mini that I don’t really use much.

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

Have you seen https://news.ycombinator.com/item?id=48892015 and yoloai? https://github.com/kstenerud/yoloai

Seems like both projects are following very similar approaches.

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

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

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

> Requires macOS 14+ on Apple silicon. (Linux is supported via firecracker and currently experimental...)

So should be noted it's mostly macOS out of the box with some Linux support if I understand right.

Can't I just use a `docker run` command to run claude and bind in the current directory into the docker container?

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

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.

the natural evolution of AI tooling: first we gave them our laptops, then we gave them VMs, next they'll demand their own AWS accounts and a corporate card

Neat, could it leverage https://github.com/apple/container

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.

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

We are building the cloud version of this: hosted, isolated VMs. MacOS and Linux supported. Cloud means you can run many VMs in parallel.

https://bitrise.io/platform/remote-dev-environments

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!

(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

Thanks! There's no packet firewall at all, no iptables/nftables. On macOS the VM's NIC is a Virtualization.framework file-handle device. The daemon runs gvproxy, which terminates the guest's connections and re-dials them as host sockets, so I filter with an allow-list right before the dial. One caveat, since you asked about root specifically: that's the macOS path, and it only works thanks to the fd NIC. Firecracker on Linux only speaks a TAP, which needs root, so there I do shell out to sudo, but just for the device. The filtering is still the same userspace allow-list.

Privilege escalation (e.g. setuid), world-readable files might contain sensitive data, world-writeable files, unrestricted network access (including access to all locally running services)... If you have fully patched system without zero-days and it's configured in a perfect way, then, sure...

Container is quite like a "separate user" except you can explicitly define what it can access.

(Even if all your daemons have good auth, it's now quite common for _apps_ to open listening sockets without much auth...)

You're missing the fact you'd be sharing a kernel with the sandboxed agent. Virtualization presents an infinitely smaller attack surface.

VMs and containers are fairly isolated and reproducible. A separate user on your machine still depends on the programs installed locally.

Well, for one, Debian and Debian-based distros make your home directory readable by everyone by default.

Security is riddled by traps. If you can afford best possible level of isolation, why not do it?

you can also simply use Landlock and bwrap on Linux. Pi even has a plugin for that https://pi.dev/packages/pi-landstrip

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.

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.

On my Mac, every sudo requires either my fingerprint or password, and times out immediately.

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

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

In a corporate environment they may not have that option

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

am I doing that once per project, or?