Sandboxes for AI agents
Give every AI agent its own disposable computer with full root. Let it install packages, run shell commands, and browse a filesystem — all sealed inside an isolated Cube.
Cubes from $2.92/moNo credit card to sign up
Why run this on a Cube
Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable.
A real computer, fully sandboxed
An agent gets root on its own microVM with its own kernel — free to install anything and run any command, while the per-cube sandbox keeps it walled off from your other workloads.
Disposable by design
Snapshot a clean base, hand a copy to each agent run, and delete it when the task finishes. Every run starts from a known-good state and leaves nothing behind.
One API call from your agent loop
Provision, run, and tear down Cubes straight from your code with the typed SDK, or let an MCP-aware assistant manage them in natural language through the Krova Cloud MCP server.
Only pay for active runs
Power a Cube off the instant an agent finishes and start it again in seconds for the next step. Compute is billed by the minute, so idle agents cost nothing.
It doesn't expire mid-task
Every competing sandbox is ephemeral by architecture, not by pricing choice — sessions are capped in hours, and a long-running agent gets cut off. A Cube has no session ceiling. The same machine covers a thirty-second tool call and a service you leave up for a year.
A fraction of sandbox pricing
At 2 vCPU and 4 GB, the published rates of the dedicated sandbox providers run an order of magnitude above ours for the same shape. The gap is largest exactly where isolation is a requirement rather than a nice-to-have — which is the whole reason a Cube exists.
How it works on a Cube
Back each agent session with a fresh Cube it can drive as its own machine.
- 01
Prepare a base image with your tools pre-installed and capture it as a snapshot.
- 02
Create a Cube from that snapshot for each agent run, so it starts clean every time.
- 03
Let the agent execute commands over SSH or the API with full root inside the Cube.
- 04
Power off or delete the Cube when the run ends — take a snapshot first if you want to inspect it later.
Frequently asked questions
Can the agent install its own packages and run arbitrary commands?
Yes. The agent has full root inside its Cube — package managers, systemd, kernel modules, anything. The microVM boundary keeps that freedom safely contained.
What happens if an agent breaks its environment?
Nothing outside the Cube is affected. Delete it and create a fresh one from your base snapshot, or restore the snapshot to roll back instantly.
How do I connect this to my agent framework?
Use the typed TypeScript SDK or REST API to manage Cubes from your agent loop, or point an MCP client at the Krova Cloud MCP server to let the model manage them directly. The MCP server exposes the whole lifecycle as tools — create, list, power off, restart, snapshot, restore, domains and port mappings — so an MCP-aware assistant can provision its own machine without you writing glue code.
How long can an agent run before the sandbox is killed?
There is no limit. A Cube is a server, not a session: it runs until you power it off or delete it. That matters for long-horizon work — a build that takes an hour, an agent that supervises a queue, or a task you want to inspect the next morning — where a session-scoped sandbox would have terminated underneath you.
How do I give every agent run an identical starting environment?
Set one Cube up exactly how you want it, snapshot it, then clone that snapshot for each run. Cloning reads the snapshot straight onto the new Cube's disk with no upload or archive step in between, the source snapshot is read-only so a bad run cannot damage the base, and each clone gets its own SSH key and network identity so copies never collide.
What stops one agent reaching another agent's Cube?
Two layers, both enforced in the kernel. Cube-to-cube traffic is dropped at the bridge, ARP included, and a second rule at the routing layer backs it up. On top of that each Cube runs its own kernel inside a per-cube jailer sandbox, so the isolation boundary is VM-grade rather than a shared kernel with namespaces over it.
Launch your first Cube
Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it.