alt Hacker NewsHow about, what sandboxing are you using to prevent the LLM from doing something you don’t want? I’m using nono.sh and have restricted network and file access. I use nono’s proxy so the LLM never gets access to api keys. I create a separate api key for each service specifically for LLM usage, and I restrict those keys as much as possible
Replies
I built something which auto-containerizes the agents for you (gvisor isolation, with credentials injected via proxy and url allowlist), but still allows orchestration between the agents, and a desktop app as well: https://github.com/bsklaroff/yaac
Tried nono.sh but it seemed cumbersome. I think it lets the whole agent run in the sandbox, so whenever you need to change something, you have to restart the whole thing, if I remember right.
Also tried Docker Sandboxes which worked fine during the try out but my trust in Docker products with regards to security is low in general, so I'd wanted to wait a bit whether problems show up.
Then used Codex for the built-in sandbox but it's buggy like hell, documented features just do not work properly. Nobody there every seemed to actually try using the stuff they are documenting as working.
Ended up with 3code right now, which also has built-in configurable sandboxing.
I have been working on a shared folder that sync between agents (https://www.filestash.app/agents/). The control plane [1] handles pretty much all storages protocols / platform (S3, SFTP, NFS< SMB, ....), you add the controls / permission boundaries and everything is auditable + traces, and the sync client is at the edge [2] to sync the data it actually has access.
I wrote my own bash wrapper around bubblewrap and pasta: https://github.com/andrei-dubovik/jail
The wrapper also keeps history, memory, etc. split by project folder, so agents working in different projects don't know each others' history. If anything, `--resume` is a split second easier.