Product

Computers that stay up.

Every agent gets its own machine with your dependencies, your services, and your env vars. It survives restarts, keeps running after you disconnect, and you can reconnect from a terminal, Slack, or your phone.

Start an agent →Read the docs

What is an agent sandbox?

An agent sandbox is an isolated computer where a coding agent runs shell commands, opens a browser, starts services, and calls APIs under policy constraints. Unlike a disposable container for one script, Islo sandboxes stay up for hours, hold state between runs, and boot your real stack so agents can work unattended.

terminal

$ islo use swift-lantern --agent claude
→ restoring snapshot        api, web, postgres, redis
→ services up               4/4 healthy
→ agent attached            claude-code

$ # close your laptop; it keeps going
$ islo use swift-lantern
→ session resumed           running 41m

What you get

Your environment

The same setup as your laptop

Dependencies, config, and env vars match what your team runs locally, so the agent is not debugging a container that only resembles your project.

Real services

Postgres, Redis, a browser, your API

The whole stack comes up together. Agents test against services that are actually running instead of mocks that always agree with them.

Persistence

State survives the session

Snapshots capture a warm environment, including database state, so the next run starts where the last one finished instead of rebuilding from zero.

Continuity

Close the lid

Work continues after you disconnect. Reattach later from anywhere and the session is where you left it, mid-task and still warm.

Isolation

One blast radius per run

Each computer is isolated, so untrusted code and model output run somewhere that does not matter if it breaks.

Sandboxes in production

IntegrationOmnigent deploys agents on Islo sandboxes

Cloud sandbox hosting for agent workloads through Omnigent's deploy integration.

IntegrationHarbor runs benchmarks on Islo computers

Harbor's cloud sandbox provider for parallel eval runs with gateway-enforced isolation.

Where teams use it

Use caseUntrusted code

Run model output off your laptop

Use caseSimulation agents

Suites against a warm stack

Use caseMigrations

Long jobs that outlive a session

Guides and comparisons

ComparisonBest sandboxes for Claude Code

Docker, E2B, Daytona, AWS AgentCore, and Islo compared for real agent workflows.

EngineeringCoding agents need a new primitive

Why fast boot times matter less than a workstation-shaped runtime for long agent sessions.

GuideWhen to use Kubernetes Agent Sandbox

What the Kubernetes CRD solves and what product semantics you still need to build.

SecurityUnderstanding sandbox security

Isolation boundaries, blast radius, and why a sandbox alone is not the whole security model.

Common questions

How is this different from a container?

Containers share the host kernel, so a breakout or kernel bug can affect everything on that machine. Islo runs each agent computer in a microVM with its own kernel, which is a stronger isolation boundary for untrusted code and model output. These computers also stay up for hours, hold state between runs, and boot your real services alongside the code.

How long can a computer stay up?

Long enough for jobs measured in hours rather than seconds. Sessions survive disconnects and restarts, which is what makes unattended work possible.

Can I SSH in and look around?

Yes. Attach a terminal and use the machine directly, including editors like vim, which is usually the fastest way to understand what an agent actually did.

What happens to state between runs?

Snapshot a warm environment and restore it later. Seeded databases and installed dependencies come back instantly instead of being rebuilt on every run.

Can these run in our own cloud?

Yes. Run on Islo cloud or inside your own VPC when security review requires the compute to stay in your account.

Give your agent a real computer.

Build your first autonomous agent →Read the docs