My working threat model for my projects is less about "malicious agent trys to escape VM" and more "well meaning agent got confused and screwed up" - the added protection of a VM is desirable, and it's useful for stuff like nested virtualization (agent working on improving the VM orchestration), makes containers inside the sandbox straightforward

I hadn't seen the stuff about filtering spoofed packets so I'll probably add that.

Many of my projects use pnpm, which ideally uses hard links from a shared store of dependencies.

One of my goals is to reduce the disk overhead of VM based isolation, so I'd like a shared pnpm store across projects (and the same for maven, etc as well)

With https://virtio-fs.gitlab.io/ mounts, each mount inside the VM is a separate FS, and I can't hard link across them. I've tried playing around with ideas like bind mounting the directory structure from the host in a folder to have a single virtio-fs mount inside the VM - but the bind mounts still can't be hard linked across it seems.

I'm basically wondering if I'm missing something or just trying to do something that isn't possible.

All the host folders are on the same FS - but I don't want to organise the host system around the VM mounting needs, and I also don't want to mount extraneous directories into the VM (eg: simple solution could be just mount ~/projects but kinda self defeating)

(Fedora workstation host)

Happy to hear what other people are thinking. It seems like putting an intercepting HTTP proxy is getting popular in other projects.

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.

See this user for example: https://github.com/filippo-agent

    > GitHub ToS actually allows that since April

3. Account Requirements

We have a few simple rules for Accounts on GitHub's Service.

You must be a human to create an Account. Accounts registered by "bots" or other automated methods are not permitted. We do permit machine accounts:

A machine account is an Account set up by an individual human who accepts the Terms on behalf of the Account, provides a valid email address, and is responsible for its actions. A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions. You may maintain no more than one free machine account in addition to your free Personal Account.

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).

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.

I guess they can add all the sibling comments to the list, as well as mine: https://github.com/AdrianVollmer/Agent-Sandbox

(Python, Podman, Squid for network filtering)

https://linuxcontainers.org/incus/

my main bottleneck was exactly in usability: how to make it least effort to spin up per use case and keep the set of operating scripts small - i didn't want to build an app for this, just shortcuts to use existing app.

This sounds good. Cloud-init is still worth the time, I think (as I just said in another comment)