Cursory research with AI says

> ~3 clearly documented, publicly demonstrated full escapes directly through KVM kernel code over roughly 15+ years of widespread KVM deployment

Surely, there are more, but we could formally verify the correctness of the entire codebase, with the help of AI.

Then we'd have "jails" that work, as long as you don't connect them to the internet.

If you had a super smart AI, you could then totally airgap it if you wanted to.

Networking opens up a can of worms and there won't be zero vulnerabilities, but we can design safer software.

These cloud agents work as cloud infra, but we're kind of in the mainframe era, before personal computing. Personal OS for agents is somewhere in the future!

And an interesting extension of that idea: if an agent runs inside a microVM, can you have that VM transparently run on another host? Maybe we'll get for-real distributed and networked operating systems

Ultimately, we need better "jails" for agent processes, but the system primitives should be flexible in what can be exposed across jails. Or you could run multiple agents in the same jail if you want them to have unrestricted interaction with each other.

    1. a VMM hypervisor
    2. a network proxy / gateway

The network proxy can handle all the ingress/egress rules, credential injection, etc.

It's still not user friendly to do all this. I think the next version of operating systems will have each "agentic process" be a bundle of VM, files in the VM, and network rules.

Been brainstorming[1] a lot of this because I've been building some open core tools[2] for spinning up sandboxed agents on arbitrary computers. There's a lot of glue and parts to stitch together to work smoothly. Don't think we've had the "Docker moment" for this, let alone the "Dropbox moment" that makes this stuff work for non-devs.

[1]: https://github.com/gofixpoint/amika/blob/main/ROADMAP.md

[2]: https://github.com/gofixpoint/amika/

That said, most of the time, I only want an agent to work in one repo. I could give it multiple repos at once and instruct it to work in just one, but that risks it forgetting my instructions and it can load more context into the agent's window.

I think my main point was to have flexibility about the topology of VMs, repos, and agents.

But for most things, I find resuming with memory is more trouble than it's worth. If you always resume from memory, you lose the ability to control the state of a VM. It's much easier to define which services should run than to define which active RAM state should be purged

Similar to why "did you try turning it on and off again?" is good for system reliability.

A standalone machine is nice if you need more compute resources or if you want an always-on machine you can connect to from your laptop, phone, etc.

It doesn't look like Google's AX is quite the plug-and-play fit for running agents on a computer you own, since it requires setting up a K8S cluster, etc.

I think what's needed is something like a zero-setup combo of Tailscale and Firecracker

I'm trying to work towards that with my startup (https://github.com/gofixpoint/amika) but the bring-your-own-computer part doesn't work quite yet.

IMO, you want the flexibility to create either: (a) permanent devbox VMs, and (b) per-task VMs

Agent sandbox platforms tend to be tuned for the latter, which sometimes involves VMM hackery for fast boot, snapshotting VM filesystem and RAM, etc.

Some workflows are a lot simpler if the multiple agents share a VM. These are workflows where agents must share state. A simple one we have: making related changes in our public OSS repo and our private repo, and then testing the change.

And other times you want to split up the tasks onto isolated VMs so they don't interfere with each other (ie run two dev servers without database or port collisions).

I tweeted a bit about this (https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents

[1]: https://github.com/gofixpoint/amika

We're working on a "bring your own computer" feature which lets you take a spare Mac and slice it up into devbox VMs you can access from the cloud.

We could also integrate https://limrun.com/ as a simulator for xcode, etc on top of Amika VMs

My cofounder (Jakub) and I (Dylan) are building amika.dev (https://www.amika.dev/), which provisions multiplayer cloud workstations for coding agents and humans to share.

We call these VM workstations "Rigs". Each Rig is loaded with your git repo(s), development environment, and choice of coding agent(s). You and your teammates can steer the same agents from anywhere: the web (desktop or mobile), Slack or Linear, SSH, CLI, API, or apps like Codex and Cursor.

Here's a demo: https://youtu.be/o4tLUOb8Vvk

We built this after we started running many long-running agent tasks in parallel. Setting up isolated environments was tedious, work stopped when we closed our laptops, and triggering tasks from tools like Sentry or Linear was awkward. Sharing changes meant copy-pasting screenshots or asking each other to check out a branch and restart their dev servers.

So, we tried to fix that! Amika has the basics you'd expect from a cloud agent: expose preview URLs, share agent chat sessions, and chat with agents from Slack or Linear.

It also does some things differently:

    - run 1 or more agents simultaneously per rig, using any harness
    - direct control over the agents and the VMs
    - control things programatically, or with human-in-the-loop UI
    - connect from the Codex app, Cursor, or cmux
    - let rigs and their agents communicate with each other and create new rigs and agents
    - run rigs on Amika's cloud or your own cloud or computers

Importantly, this is NOT an agent harness, nor a sandbox provider.

We want Amika to run any agent harness on any computer, whether that's a desktop in your closet, an AWS Kubernetes cluster, or a sandbox cloud. Underneath the app, Amika schedules VMs on those hosts (via our sandbox router) and networks the VMs and their agents together.

Our core is open source at https://github.com/gofixpoint/amika

Our goal is to make the OSS really easy to self-host for individuals, while having a cloud platform for teams. The self-hosted story is not feature-compatible right now, but we're working to improve that.

Right now, we're giving all HN signups 2 VMs free for 2 weeks, then it's $30 / month + compute hosting costs. You can sign up at https://amika.dev. If you want to run on compute or cloud accounts you already own, it's cheaper. Send me an email at dylan+hn@amika.dev if you want to get BYOC or self-hosting working and I'll help you out.

Comments URL: https://news.ycombinator.com/item?id=49716282

Points: 7

# Comments: 5

   (A) it furthers human knowledge
   (B) it gets used in applied sciences, engineering, etc.

    1. proof that there is a solution
    2. a solution that you can work backwards from to build understanding

So, both of these pieces of info would be at least marginally useful for advancing human knowledge.

I'm working on exactly this bit (with some more tuning for messaging AI agents)

https://github.com/gofixpoint/amika

Doesn't run on your Mac Mini yet, but should get that enabled either this week or next

If you sign up (free) I'll send you an email when the "Mac Mini mode + full OSS self-hosting" is live

    1. auto-refresh base VM snapshots with latest delta of git commit changes
    2. extend the VM lifetime when it receives an interaction (chat, HTTP request, etc.) and sleep it when inactive
    3. oauth refresh of MCP servers, coding agent subscriptions, etc.
    4. support inter-VM and communication for agents and exec commands
    5. keeping track of agent work across VMs

A few examples:

Many remote agents products have a "one agent per VM" restriction, but it's better to have N agents across M VMs. For example, I have agents work on a singular VM in parallel worktrees and then stack the worktrees at the end on that VM for the final change.

Just give me OpenSSH with normal SSH key management. Lets you manage VM access the same way we've done it since the 90s.

Connect VMs in a network topology: we build our VM/agent scheduling + remote control product inside itself, so we often test interactions between user, control plane, and sandbox(es). If you can directly control VM creation and lifecycle, it's easy to spin this structure up and let agents work across it.

I should be able to use whichever coding agents I want, connected to the VM. Whether that's OpenCode or Pi Web in the browser, or loading the VM into Cursor or Codex app, or using the TUI or sending messages to agent(s) via API.