Live data from Hacker News

A deep dive on agent sandboxes

pierce.dev

11–20 of 22 posts

Re: A deep dive on agent sandboxes

#11
post #2

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.

This was also a great read: https://www.luiscardoso.dev/blog/sandboxes-for-ai

Re: A deep dive on agent sandboxes

#12
post #3

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

[deleted]

Re: A deep dive on agent sandboxes

#14
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://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).

Re: A deep dive on agent sandboxes

#15
post #3

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

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.

Re: A deep dive on agent sandboxes

#16
post #3

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

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.

Interesting project.

This won't work on Mac, right?

Re: A deep dive on agent sandboxes

#17
post #16

Earlier quoted context omitted.

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.

Interesting project. This won't work on Mac, right?

Of course not. But it is not needed, as Mac users are not interested in data safety.

Re: A deep dive on agent sandboxes

#18
post #5

Earlier quoted context omitted.

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?

> 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 directo…

Why not just use the standard Linux tool bubblewrap?

Re: A deep dive on agent sandboxes

#19
post #3

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

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.

Why not just use the standard Linux tool bubblewrap?

Re: A deep dive on agent sandboxes

#20
post #19

Earlier quoted context omitted.

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.

Why not just use the standard Linux tool bubblewrap?

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.
Post reply on HN