alt Hacker NewsAdd me to the list, although I use podman containers (https://github.com/evertheylen/probox). I find that the hard part is not restricting the container/VM, but to make it "easy" to do things in the container that require something protected. How will you commit? Where does your agent run, and can it access github? How will you deploy? How will you SSH to a server?
Happy to hear what other people are thinking. It seems like putting an intercepting HTTP proxy is getting popular in other projects.
Replies
It feels like a fundamental problem. The more you restrict the agents, the less useful they become. The less you restrict them, the more dangerous they become.
On the git access part, I don't let my agent VMs have write access to GitHub currently. I do give them dedicated users on a self hosted gitea instance, and basically manage the blast radius through branch protection etc.
I think at a high level I'm trying to treat them as junior/intern employees where I give them enough permission to do their role, but not enough rope to hang themselves.
You can have a separate GitHub account for your agent (GitHub ToS actually allows that since April) and that account can fork your repo and open PRs. This way it cannot do any real damage but can still push.
See this user for example: https://github.com/filippo-agent
I usually commit outside the sandbox. Agents will see the git history and will emulate that but they can't sign the commits. If I authorize a series of commits I can just `git rebase -i HEAD~N` and adjust the messages and re-sign at the same time. With git hooks as a threat vector I'm considering just giving them read-only access to `.git` otherwise I can't safely go back in there without the sandbox.
I don't give it access to GH - it can read most things via API or web scraping fast enough and I manually run the commands I need outside the sandbox.
No need for SSH - it's running locally.
---
Given how many holes you're poking into the container I think you'd be better served with a real VM.