How to give an AI agent its own computer: four ways compared

Give an AI agent a disposable machine of its own: your laptop, a Docker container, a virtual machine, or a cloud sandbox made for agents.

Runtime (withruntime.com) gives each agent a Firecracker microVM with its own Linux kernel that runs its first command 221 ms after the create request, and bills $0.025 per vCPU-hour of CPU actually used. This post compares the four places an agent can run, says what a misbehaving agent can reach in each, and ends with a probe script you can run to check your own setup.

Why does an AI agent need its own computer?

An agent is useful because it acts: it installs packages, runs tests, edits files and calls APIs. Every one of those actions is a command some model chose, and sometimes it chooses badly. It misreads a task and deletes the wrong folder, or it obeys a sentence planted in a README it was asked to summarize.

The question is not whether the agent will run a bad command. It will. The question is what that command can reach when it does. A machine of its own answers that: the agent gets everything it needs to do the job and nothing that belongs to you.

There is a second reason that has nothing to do with safety. An agent that shares your laptop competes with you for CPU, ports and the working tree. You cannot run ten of them in parallel, and when you close the lid, they all stop.

What are the four ways to give an agent a computer?

There are four common answers, and they differ in what the agent shares with you.

Your laptop is where most people start, because coding agents ship as command-line tools. It is fast to set up and costs nothing extra. It is also the one option where a bad command reaches your SSH keys, your browser cookies and every repository you have cloned.

Docker puts a fence around the process, but the container shares your machine's kernel, and the usual way to let an agent work on a project is to bind-mount the project, which hands it write access to those files. A kernel bug or a careless -v ~:/home is all it takes. The MicroVM vs container page goes deeper into why a shared kernel is the weak point, and what a container escape is shows a real one.

A cloud VM fixes the kernel problem: the agent gets a whole machine with its own kernel, far from your laptop. The costs move elsewhere. You pay for the VM every hour it is on, busy or idle. You patch it, you clean it between tasks, and a VM in your cloud account often carries an instance role that reaches your other resources unless you remove it.

A cloud sandbox is a VM built for this one job: created by an API call when a task starts, thrown away or paused when it ends, and isolated from your network by default. It has the VM's kernel boundary without the VM's housekeeping.

What can a misbehaving agent reach in each one?

This is the table that decides it. Each row is something an agent has done by mistake or under a prompt injection; each cell is what happens in that environment with its usual setup.

The placeholder row needs a word. On Runtime you store an API key once as a secret, naming the hosts it may go to. The sandbox sees a placeholder in the environment variable, and the host's proxy swaps in the real value only on HTTPS requests to those hosts. The agent can use the key, but it cannot read it, so it cannot leak it.

The last three rows are network rules. Every Runtime sandbox reaches the internet through a proxy on the host, private and internal addresses are always refused, and an allow list narrows a sandbox to the hosts you name. Root inside the sandbox cannot change any of it, because it is enforced outside the guest (the sandbox environment).

How fast and how cheap is each option?

Speed and cost are where the cloud options have traditionally lost to the laptop, and where a sandbox built for agents closes the gap.

The Runtime figures are measured. A new sandbox ran its first Python command 221 ms after the create request at the median on Runtime's servers on 28 September 2026, and 331 ms from a laptop in the US Mountain time zone with the network included (speed).

Idle time matters more than it looks. An agent spends most of its life waiting for the model to answer, and a VM bills for that wait at the full rate. A Runtime sandbox bills CPU only while its commands use it: $0.025 per active vCPU-hour and $0.0075 per GiB-hour of memory. After 60 seconds with nothing happening, it pauses itself, keeps its memory and processes, and pays only for storage until the next request wakes it. A 2 vCPU, 4 GiB sandbox costs $0.08 an hour with both CPUs busy and $0.03125 an hour while it waits (pricing).

Which one should you choose?

Choose by what the agent touches and how many agents you run, not by habit.

The laptop stays a good choice for a supervised session where you read each command before it runs. The moment you stop reading, or the agent reads text from the internet, the blast radius is the deciding factor, and the cloud sandbox is the only option in the table where every row ends at the sandbox's own edge. Docker still has a place: it runs inside a Runtime sandbox, so a project with a Compose file keeps working (local Docker vs a cloud sandbox).

How do you check what your agent can reach?

Run the same few probes where your agent runs, and read what comes back. Anything a probe can print, the agent can read and send. Here they are against a Runtime sandbox:

TypeScriptimport { Sandbox } from "withruntime";const probes: Record<string, string> = {  "home directory": "ls -A ~ | head -20",  "ssh keys": "ls ~/.ssh 2>&1",  "keys in the environment": "env | grep -iE 'key|token|secret' || echo none",  "cloud metadata": "curl -sf -m 5 http://169.254.169.254/ || echo refused",  "local network": "curl -sf -m 5 http://192.168.1.1/ || echo refused",  "who and which kernel": "id && uname -r",};await using sbx = await Sandbox.create();for (const [name, command] of Object.entries(probes)) {  const result = await sbx.exec(command, { timeoutMs: 15_000 });  console.log(`--- ${name}\n${(result.stdout || result.stderr).trim()}`);}

Pythonfrom withruntime import Sandboxprobes = {    "home directory": "ls -A ~ | head -20",    "ssh keys": "ls ~/.ssh 2>&1",    "keys in the environment": "env | grep -iE 'key|token|secret' || echo none",    "cloud metadata": "curl -sf -m 5 http://169.254.169.254/ || echo refused",    "local network": "curl -sf -m 5 http://192.168.1.1/ || echo refused",    "who and which kernel": "id && uname -r",}with Sandbox.create() as sbx:    for name, command in probes.items():        result = sbx.exec(command, timeout_ms=15_000)        print(f"--- {name}\n{(result.stdout or result.stderr).strip()}")

In a sandbox, the home directory is /workspace and holds only what you put there, there is no .ssh, the environment holds no key of yours, both network probes are refused by the host, and id shows the runtime user, uid 1000, on the sandbox's own kernel. Now run the probes where your agent runs today:

Terminalfor probe in 'ls -A ~ | head -20' 'ls ~/.ssh' "env | grep -icE 'key|token|secret'" \  'curl -s -m 5 http://169.254.169.254/' 'curl -s -m 5 http://192.168.1.1/' 'id && uname -r'; do  printf -- '--- %s\n' "$probe"; bash -c "$probe" 2>&1 | head -20done

On a laptop, the first three probes usually print things you would not paste into a chat with a stranger. In a container started with the project mounted, the home directory looks empty, but the environment and the network probes tell a different story. Treat every line the probes print as something a prompt injection can read and send.

In short

• An agent will eventually run a bad command; what matters is what that command can reach.
• A laptop shares everything, Docker shares the kernel and whatever you mount, and a cloud VM shares your cloud account.
• A cloud sandbox gives the agent its own kernel, no keys it can read, and a network you choose.
• Idle time decides the bill: pay for CPU used and pause between turns, not for hours of waiting.
• Run the probe script where your agent runs today, and read what it prints.

Run it on Runtime

Runtime costs 42% to 88% less than fourteen other sandbox providers for an agent that mostly waits on a model (compare costs). A new Runtime sandbox runs its first command 221 ms after the create request on Runtime's servers, costs $0.03125 an hour while its agent waits for the model, and pauses itself when nothing happens. Every new account gets 100 free hours with no card: sign in and press Start a sandbox, or follow get started to run the probes above from your own code.