4 ms·

A deep dive on agent sandboxes

68 points by icyfox 9mo ago

pama 9mo ago
I would like to see more articles about agent sandboxes. With agents gaining popularity we need a higher fraction of users to understand containers and sandboxes and their risk profiles, and then to communicate their understandings to friends and family. It is a harder task than explaining ChatGPT, and it often feels like a hindrance.
- sea-gold 9mo ago
  This was also a great read: https://www.luiscardoso.dev/blog/sandboxes-for-ai https://www.luiscardoso.dev/blog/sandboxes-for-ai
ashishb 9mo ago
6 months back I started dockerizing my setup after multiple npm vulnerabilities. Then I wrote a small tool[1] to streamline my sandboxing. Now, I run agents inside it for keeping my non-working-directory files safe. For some tools like markdown linter, I run them without network access as well. 1- https://github.com/ashishb/amazing-sandbox https://github.com/ashishb/amazing-sandbox
- nullishdomain 9mo ago
  This looks awesome! Do you have a mental process you run through to determine what gets run in the sandbox, or is it your default mode for all tools?
  - ashishb 9mo ago
    > This looks awesome! Do you have a mental process you run through to determine what gets run in the sandbox, or is it your default mode for all tools? Here's what I use it for right now - yarn - npm - pnpm - mdl - Ruby-based Markdown linter - fastlane - Ruby-based mobile app release tool by Google - Claude Code - Gemini CLI Over time, my goal is to run all CLI-based tools that only need access to the current directory (and not parent directories) via this.
    - tapete1 9mo ago
      Why not just use the standard Linux tool bubblewrap?
- deleted 9mo ago
  [deleted]
- Gerharddc 9mo ago
  Very nice! Quite a coincidence, but the NPM disaster also prompted me to build litterbox.work as a possible solution. It is a very different approach though.
  - ashishb 9mo ago
    Interesting project. This won't work on Mac, right?
    - tapete1 9mo ago
      Of course not. But it is not needed, as Mac users are not interested in data safety.
    - Gerharddc 9mo ago
      Unfortunately not since it is very much designed for Linux. I imagine it should work fine inside a Linux VM on Mac though.
  - tapete1 9mo ago
    Why not just use the standard Linux tool bubblewrap?
    - Gerharddc 9mo ago
      The main reason is that in addition to sandboxing, I also wanted something similar to dev-containers where I can have a reproducible development environment. I guess that can also be achieved with Bubblewrap, but when you want to run containers anyway, it seems silly to not just use Podman.
gouthamve 9mo ago
Hugged to death? Seeing SSL failure to the site from CloudFlare.
zmj 9mo ago
devcontainers, devcontainers, devcontainers
- bigwheels 9mo ago
  Totally, devcontainers are fantastic! In this agent sandboxing space there's also Leash, which in addition to Docker/Orbstack/Podman provides a sophisticated macOS-native system extension mode - https://github.com/strongdm/leash https://github.com/strongdm/leash
- binsquare 9mo ago
  I don't think containers are enough especially for the security side of things. Imo microvm's+ dev containers seem like a good fit though
linolevan 9mo ago
The secret proxy trick is something I expect to become standard at some point in the near future. I first saw this trick being used in Deno Sandboxes (https://docs.deno.com/sandboxes/security/ https://docs.deno.com/sandboxes/security/) but it's cheap/easy to implement so I'd be surprised if this doesn't become the standard for a lot of these BaaS platforms.
jeffrallen 9mo ago
> turning complete Dude, really?
Gerharddc 9mo ago
Very interesting read, I had no idea agents already had so much sandboxing built in! It does seem like this is probably not enough though. A few months ago I built https://github.com/Gerharddc/litterbox https://github.com/Gerharddc/litterbox (https://litterbox.work/ https://litterbox.work/) primarily to shield my home directory from supply-chain attacks, but I imagine it could be very useful for defending against rogue agents too. Essentially it is a dev-container-like system for Linux built on rootless Podman with a strong focus on isolation and security. A key difference to normal dev-containers is that it encourages placing your entire dev environment (i.e. also the editor etc.) inside the container so that you are even protected from exploits in editor extensions for instance. This also makes it safer to allow agents (or built tools) to for instance install packages on your system since this is not the "real" system, it is only a container. Another important feature I added to Litterbox (and one I have not seen before) is a custom SSH agent which always prompts the user to confirm a signing operation through a pop-up. This means that things inside a Litterbox do not have unrestricted access to your normal SSH agent (something which could provide rogue actors access to your Github for instance).
AdieuToLogic 9mo ago
Cool article. It makes me think about an "old school Unix" approach which might work for some use-cases. Essentially, the untested brainstorming-only idea is: 1. Make $HOME have 0751 permissions 2. Assume the dev project exists in $HOME/foo and has 0715 permissions 3. Assume $HOME/foo/src is where all source code resides and has 0755 permissions (recursively) 4. Install the agent tools with a uid:gid of something like llm:agent 5. Turn on the setuid/setgid bits for executable(s) in the agent tools or make wrapper script(s) having same which delegate to agent tools This would ensure agent tooling could not read nor modify $HOME, only be able to read $HOME/foo (top-level project directory) and its files (assuming `o+r` is the default), and could only modify files in $HOME/foo/src having `o+w` permission as well. If agent directory creation in $HOME/foo/src is desired, enable `o+w` on it and directories within it. There is probably some "post agent use" processing that would be needed as well.

68 points by icyfox 9mo ago

pama 9mo ago

I would like to see more articles about agent sandboxes. With agents gaining popularity we need a higher fraction of users to understand containers and sandboxes and their risk profiles, and then to communicate their understandings to friends and family. It is a harder task than explaining ChatGPT, and it often feels like a hindrance.

sea-gold 9mo ago
This was also a great read: https://www.luiscardoso.dev/blog/sandboxes-for-ai https://www.luiscardoso.dev/blog/sandboxes-for-ai

ashishb 9mo ago

6 months back I started dockerizing my setup after multiple npm vulnerabilities. Then I wrote a small tool[1] to streamline my sandboxing. Now, I run agents inside it for keeping my non-working-directory files safe. For some tools like markdown linter, I run them without network access as well. 1- https://github.com/ashishb/amazing-sandbox https://github.com/ashishb/amazing-sandbox

nullishdomain 9mo ago
This looks awesome! Do you have a mental process you run through to determine what gets run in the sandbox, or is it your default mode for all tools?
- ashishb 9mo ago
  > This looks awesome! Do you have a mental process you run through to determine what gets run in the sandbox, or is it your default mode for all tools? Here's what I use it for right now - yarn - npm - pnpm - mdl - Ruby-based Markdown linter - fastlane - Ruby-based mobile app release tool by Google - Claude Code - Gemini CLI Over time, my goal is to run all CLI-based tools that only need access to the current directory (and not parent directories) via this.
  - tapete1 9mo ago
    Why not just use the standard Linux tool bubblewrap?
deleted 9mo ago
[deleted]
Gerharddc 9mo ago
Very nice! Quite a coincidence, but the NPM disaster also prompted me to build litterbox.work as a possible solution. It is a very different approach though.
- ashishb 9mo ago
  Interesting project. This won't work on Mac, right?
  - tapete1 9mo ago
    Of course not. But it is not needed, as Mac users are not interested in data safety.
  - Gerharddc 9mo ago
    Unfortunately not since it is very much designed for Linux. I imagine it should work fine inside a Linux VM on Mac though.
- tapete1 9mo ago
  Why not just use the standard Linux tool bubblewrap?
  - Gerharddc 9mo ago
    The main reason is that in addition to sandboxing, I also wanted something similar to dev-containers where I can have a reproducible development environment. I guess that can also be achieved with Bubblewrap, but when you want to run containers anyway, it seems silly to not just use Podman.

gouthamve 9mo ago

Hugged to death? Seeing SSL failure to the site from CloudFlare.

zmj 9mo ago

devcontainers, devcontainers, devcontainers

bigwheels 9mo ago
Totally, devcontainers are fantastic! In this agent sandboxing space there's also Leash, which in addition to Docker/Orbstack/Podman provides a sophisticated macOS-native system extension mode - https://github.com/strongdm/leash https://github.com/strongdm/leash
binsquare 9mo ago
I don't think containers are enough especially for the security side of things. Imo microvm's+ dev containers seem like a good fit though

linolevan 9mo ago

The secret proxy trick is something I expect to become standard at some point in the near future. I first saw this trick being used in Deno Sandboxes (https://docs.deno.com/sandboxes/security/ https://docs.deno.com/sandboxes/security/) but it's cheap/easy to implement so I'd be surprised if this doesn't become the standard for a lot of these BaaS platforms.

jeffrallen 9mo ago

> turning complete Dude, really?

Gerharddc 9mo ago

Very interesting read, I had no idea agents already had so much sandboxing built in! It does seem like this is probably not enough though. A few months ago I built https://github.com/Gerharddc/litterbox https://github.com/Gerharddc/litterbox (https://litterbox.work/ https://litterbox.work/) primarily to shield my home directory from supply-chain attacks, but I imagine it could be very useful for defending against rogue agents too. Essentially it is a dev-container-like system for Linux built on rootless Podman with a strong focus on isolation and security. A key difference to normal dev-containers is that it encourages placing your entire dev environment (i.e. also the editor etc.) inside the container so that you are even protected from exploits in editor extensions for instance. This also makes it safer to allow agents (or built tools) to for instance install packages on your system since this is not the "real" system, it is only a container. Another important feature I added to Litterbox (and one I have not seen before) is a custom SSH agent which always prompts the user to confirm a signing operation through a pop-up. This means that things inside a Litterbox do not have unrestricted access to your normal SSH agent (something which could provide rogue actors access to your Github for instance).

AdieuToLogic 9mo ago

Cool article. It makes me think about an "old school Unix" approach which might work for some use-cases. Essentially, the untested brainstorming-only idea is: 1. Make $HOME have 0751 permissions 2. Assume the dev project exists in $HOME/foo and has 0715 permissions 3. Assume $HOME/foo/src is where all source code resides and has 0755 permissions (recursively) 4. Install the agent tools with a uid:gid of something like llm:agent 5. Turn on the setuid/setgid bits for executable(s) in the agent tools or make wrapper script(s) having same which delegate to agent tools This would ensure agent tooling could not read nor modify $HOME, only be able to read $HOME/foo (top-level project directory) and its files (assuming `o+r` is the default), and could only modify files in $HOME/foo/src having `o+w` permission as well. If agent directory creation in $HOME/foo/src is desired, enable `o+w` on it and directories within it. There is probably some "post agent use" processing that would be needed as well.