Live data from Hacker News

A deep dive on agent sandboxes

pierce.dev

21–22 of 22 posts

Re: A deep dive on agent sandboxes

#21
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?

Unfortunately not since it is very much designed for Linux. I imagine it should work fine inside a Linux VM on Mac though.

Re: A deep dive on agent sandboxes

#22
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.

Post reply on HN