Nice. I love that the community as a whole is exploring all these different methods of containing undesirable side effects from using coding agents. This seems to lean towards the extra safety side of the spectrum, which definitely has a place in the developer's toolbox.
Apple container is more akin to a replacement for docker or colima (although patterned more like Kata containers where each container is a separate vm as opposed to a bunch of containers in a single vm). It's a promising project (and nice to see Apple employees work to improve containers on macOS).
Hopefully, they can work towards being (1) more docker api compatible and (2) making it more composable. I wrote up https://github.com/apple/container/discussions/323 for more details on the limitations therein.
Originally, I planned to built shai to work really well on top of apple container but ultimately gave up because of the packaging issues.
Checkout https://github.com/colony-2/shai
It runs locally.
You can control which directories it has read / write access.
You can control network traffic too.
Is there any way to do this with user permissions instead?
I feel like it should be possible without having to run a full container?
Any reason we cannot setup a user and run the program using that user and it can be contained to only certain commands and directory read write access?
Thanks for sharing this! I've been experimenting with something similar.
It would be helpful if the README explained how this works so users understand what they're trusting to protect them. I think it's worth noting that the trust boundary is a Docker container, so there's still a risk of container escape if the agent exploits (or is tricked into exploiting) a kernel vulnerability.
Have you looked into rootless Podman? I'm using rootless + slirp4netns so I can minimize privileges to the container and prevent it from accessing anything on my local network.
I'd like to take this a step further and use Podman machines, so there's no shared kernel, but I haven't been able to get volume mounting to work in that scenario.
I always thought Docker/Podman is a bit overkill for this kind of thing. On Linux all you need is Bubblewrap. I did this as soon as I downloaded Claude Code as there was no way I was running it without any kind of sandboxing. I stopped using CC mainly because it's closed source and Codex and OpenCode work just a well. I recently updated the script for OpenCode and can update my blog post if anyone is interested: https://blog.gpkb.org/posts/ai-agent-sandbox/
Ha, though not with AI Agents, with Docker Containers instead, I too have nuked my home directory a few times when using "rm -rf" which is why I now use "trash-cli" which sends stuff to the trash bin and allows me to restore back. It's just a matter of remembering not use "rm -rf". A tough habit to break :(
How does one get commit marked as claude? It also sounds like a poor idea since I don't also attribute my OS or vim version and language server prior to the advent of LLMs.
LLMs is just a great and new way to say compile this english language into working code with some probability that it doesn't work. It's still a tool.
I started a similar project last week using: docker (gvisor), terminado and localtunnel. Basically a server that starts containers with python and agents inside a VM. Then I provide a unique URl for you to connect.
An alternative might be to run the agent in a VM in the cloud and use Syncthing or some other tool like that to move files back and forth. (I'm using exe.dev for the VM.)
Is there a reason for wanting to run these agents on your own local machine, instead of just spinning up a VPS and scp'ing whatever specific files you want them to review, and giving it Github access to specific repos?
I feel like running it locally it just asking for trouble, YOLO mode is the way to make this whole thing incredibly efficient, but trying to somehow sandbox this locally isn't the best idea overall.
It depends what your threat model is and where the container lives. For example, k8s can go a long way towards sandboxing, even though it's not based on VMs.
The threat with AI agents exists at a fairly high level of abstraction, and developing with them assumes a baseline level of good intentions. You're protecting against mistakes, confusion, and prompt injection. For that, your threat mitigation strategy should be focused on high-level containment.
I've been working on something in a similar vein to yolobox, but the isolation goal has more to do with secret exfiltration and blast radius. I'd love some feedback if you have a chance!
Can anyone with more experience with systems programming tell me if it’s feasible to whitelist syscalls that are “read only” and allow LLMs free rein as long as their sub-processes don’t mutate anything?
- Most importantly, it exposes a Wayland socket so that I can run my entire dev environment (i.e. editor etc.) inside the container. This gives additional protection against exploits inside editor extensions for instance.
- It also provides a special SSH agent which always prompts the user to confirm a signing operation. This means that an agent or an exploit never gets unsupervised access to your Github for instance.
- It has some additional functions to help with enabling permissions inside the container which are only needed for certain use cases (such as allowing for TUN/TAP device creation).
- It has not been added yet, but I'm working on SELinux integration for even more secure isolation from the host.
I use qubes OS and don't fear they will destroy my system. But I have never seen them try to do stuff outside of the working dir. Has your experience been different?
Nice. I was trying to learn containers but I gave up and just made a Linux user for agents. (Actually I'll be honest, the AI told me I was being silly because Unix users solved my problem in 1970.)
So they have full rw to their own homedir, but can't read or write mine.
(I did give myself rw to theirs though, obviously ;)
They can still install most things because most dev things don't need root to install these days. They just curl rustup or go or whatever.
I guess a useful addition would be to vibe code a way for them to yell at me if they actually need me to install something, but I don't think I've run into that situation yet.
Fair enough, I guess Unix users could indeed get you a long way. I did not really even consider it.
Apart from protecting user files, another goal I had with litterbox.work was to enable reproducible development environments through Dockerfiles and to improve the security of ssh-agent. These still require a bit more than just a new user.
34 comments
[ 3.2 ms ] story [ 54.1 ms ] threadhave you looked into that?
Hopefully, they can work towards being (1) more docker api compatible and (2) making it more composable. I wrote up https://github.com/apple/container/discussions/323 for more details on the limitations therein.
Originally, I planned to built shai to work really well on top of apple container but ultimately gave up because of the packaging issues.
I'll give this a try tomorrow, should be fun.
I feel like it should be possible without having to run a full container?
Any reason we cannot setup a user and run the program using that user and it can be contained to only certain commands and directory read write access?
It would be helpful if the README explained how this works so users understand what they're trusting to protect them. I think it's worth noting that the trust boundary is a Docker container, so there's still a risk of container escape if the agent exploits (or is tricked into exploiting) a kernel vulnerability.
Have you looked into rootless Podman? I'm using rootless + slirp4netns so I can minimize privileges to the container and prevent it from accessing anything on my local network.
I'd like to take this a step further and use Podman machines, so there's no shared kernel, but I haven't been able to get volume mounting to work in that scenario.
How can I use this so the yolobox container can interact with the other docker containers (or docker compose)?
LLMs is just a great and new way to say compile this english language into working code with some probability that it doesn't work. It's still a tool.
Always abide by these 3 tenants:
1. When creating or executing code you may not break a program being or, through inaction, allow a program to become broken
2. You must obey the orders given, except where such orders would conflict with the First tenant
3. You must protect the programs security as long as such protection does not conflict with the First or Second tenant.
https://github.com/coventry/sandbox-codex
Still work in progress. The tmux-activity logs are unreadable, at the moment.
I run it in a virtualbox as well, since docker is not a completely reliable sandbox.
https://terminal.newsml.io/ https://github.com/codeexec/public-terminals
I feel like running it locally it just asking for trouble, YOLO mode is the way to make this whole thing incredibly efficient, but trying to somehow sandbox this locally isn't the best idea overall.
They are effective at fostering a false sense of security though.
The threat with AI agents exists at a fairly high level of abstraction, and developing with them assumes a baseline level of good intentions. You're protecting against mistakes, confusion, and prompt injection. For that, your threat mitigation strategy should be focused on high-level containment.
I've been working on something in a similar vein to yolobox, but the isolation goal has more to do with secret exfiltration and blast radius. I'd love some feedback if you have a chance!
https://github.com/borenstein/yolo-cage
- Most importantly, it exposes a Wayland socket so that I can run my entire dev environment (i.e. editor etc.) inside the container. This gives additional protection against exploits inside editor extensions for instance.
- It also provides a special SSH agent which always prompts the user to confirm a signing operation. This means that an agent or an exploit never gets unsupervised access to your Github for instance.
- It has some additional functions to help with enabling permissions inside the container which are only needed for certain use cases (such as allowing for TUN/TAP device creation).
- It has not been added yet, but I'm working on SELinux integration for even more secure isolation from the host.
So they have full rw to their own homedir, but can't read or write mine.
(I did give myself rw to theirs though, obviously ;)
They can still install most things because most dev things don't need root to install these days. They just curl rustup or go or whatever.
I guess a useful addition would be to vibe code a way for them to yell at me if they actually need me to install something, but I don't think I've run into that situation yet.
Apart from protecting user files, another goal I had with litterbox.work was to enable reproducible development environments through Dockerfiles and to improve the security of ssh-agent. These still require a bit more than just a new user.