I need isolation, but I also need to give my agents secure access to internal package registries, logs, internal infra, designs, emulators, browsers, docs etc. At a large company, work can span dozens of repositories. And on top of that, I need dozens of these.
I built this at work. Engineers use krunkit VMs with proper memory ballooning, GPU acceleration. Retina RDP, credential injecting proxy for etc.
This seems like a fun toy for single project development, but nothing close to what you need as an engineer in a corporate environment.
Mines based on libvirt and uses cloud-init for creating the images, with shared golden images across projects.
Skimming your docs it wasn't totally clear to me if your images are built per project, or COW from shared toolchains.
Looks like you have a few features in there that I might take some inspiration from though, eg the proxying stuff.
Funny how many of us are trying to solve the same problem at the moment.
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)
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.
Happy to hear what other people are thinking. It seems like putting an intercepting HTTP proxy is getting popular in other projects.
See this user for example: https://github.com/filippo-agent
> GitHub ToS actually allows that since April
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.
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)
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.
That project is underrated.
I have built my agent harness around smolvm and it has been working wonderfully.
I have seen a single bug up to now (iirc you cannot take a snapshot from a machine you rehydrate from a pack) but found a workaround.
I think the only thing I would love a solution for is the ability to bind credentials even when you use tailscale. You cannot right now because the traffic goes through the tailscale interface.
Anyway. smolvm is simply amazing.
This sort of wrapping setup of VMs in a higher level project is encouraged by BinSquare, the creator of smol machines, as recently on X he has been touting its embeddability.
As I read it, .git protection stops the VM from changing hooks, and --clone leaves the hook behind since a clone doesn't copy hooks. However, the hook is still in the folder on the host. Does devvm inspect and warn when a folder already has hooks before you start?
Like Docker Sandbox this meets what I think should be our standards in the AI age: kernel isolation and secret shielding in addition to network and disk isolation.
I have been working on a similar project because I haven't seen one before that to me didn't have security design deficiencies. This project looks to have made good design decisions around security.
The things that are design choices for these tools are
* agent integration
* docker image composition
* are vms more persistent or throw away
* managing configuration
- a bunch of gitops repos: terraform mono repo, argocd-esk conf repo, grafana provisioning repo, etc.
- frontend + backend repo (tbh may merge these to a mono-repo, but here we are)
I think the auto detection is interesting, but tbh with my solution I've been happy with just install all the tools regardless of what a specific project needs - with a COW base layer this is cheap.
`sbx`, safehouse and the like
Bubblewrap would just be a better alternative for this.