171–177 of 177 posts
Earlier quoted context omitted.
In a corporate environment they may not have that option
But they can run arbitrary VMs?
This is the right idea IMO but I don't want to trust a third party tool for it either (no offense OP!). Ever since I started running coding agents with shell access I've jailed them inside of VMs. Since I run Linux I can just use incus[0] for the VM management layer. It's extremely simple, and you can vibe code a shell script to customize your workflow in a few minutes. [0] https://linuxcontainers.org/incus/
Earlier quoted context omitted.
He described a separate machine where the execution and context would be hosted, not local sandboxes. Did I misunderstand how Gondolin works?
> Gondolin gives you that. Lightweight micro-VMs (QEMU by default, optional libkrun backend) boot in under a second on your Mac or Linux machine. The network stack and virtual filesystem are implemented entirely in JavaScript, giving you complete programmatic control over what the sandbox can access and what secrets it can use.
This is slightly insane
I suppose it will be slow too if the agent needs to grep over megabytes of data
How many of these are there now, a hundred? We get it, you can run an agent in a VM/container/sandbox. What about configuration management & rollbacks? What about the policy engine? What about dynamic credential management? What about the lethal trifecta? A sandbox is the easiest part and doesn't address the others.
This is the right idea IMO but I don't want to trust a third party tool for it either (no offense OP!). Ever since I started running coding agents with shell access I've jailed them inside of VMs. Since I run Linux I can just use incus[0] for the VM management layer. It's extremely simple, and you can vibe code a shell script to customize your workflow in a few minutes. [0] https://linuxcontainers.org/incus/
No offense taken! Curious what your actual setup looks like, and whether you do any network filtering on the incus VMs?
It uses cloud-init for the initial setup and injects the agent's config file and some other stuff in a ro mount from my laptop. That single subdirectory is mounted rw into a conventional location inside the VM. I inject only credentials to e.g. test environments that don't matter if they're exposed. The agent context instructs it that it can use full sudo and install any utilities from apt that it needs.
So for the ux I do incus-dev-vm.sh shell or incus-dev-vm.sh opencode etc.
A fun thing about this is I used nested virt to have the agent write the script - so I spooled up an incus VM myself first, then the agent can run with full privs inside there creating nested VMs to ensure its functionality.
Right now I'm not filtering anything on the VM - with my threat model only limited access is granted and I don't give creds to touch real infra. But you should be able to filter it on the host (I haven't researched the best approach however).