What is an isolated agent environment?

One agent, one computer, any harness. An isolated agent environment is the dedicated machine the Spinup Agent works on: its own files, tools, packages, browser state, secrets, and network controls, with the harness inside swappable on top. The agent is the durable identity above it: workspace-owned, with a lifecycle and a recorded history. The active machine is replaceable capacity.

Why It Matters

Agents need more than logical separation

For real agent workloads, isolation has to contain mutability, not just separate processes. The moment a run can install packages, write files, log into websites, or handle sensitive inputs, the environment boundary becomes part of the product.

Browser sessions stay scoped to one agent

Browser automation produces stateful sessions, cookies, downloads, and screenshots that should stay scoped to a single environment.

Package installs compound without boundaries

Package installs and temporary files alter the runtime over time. That mutability stays manageable only when the environment boundary is clear.

Security controls belong at the agent level

Secrets and outbound network access should be agent-level controls, not an afterthought bolted onto a generic worker pool.

State persists with one agent identity

Persistent state is easier to reason about when one environment maps to one agent identity. Files, packages, and artifacts belong to a specific agent, not a shared pool.

Sandbox Vocabulary

Sandbox language is useful, but incomplete

Sandbox is a useful starting term because it points to isolated code execution. Spinup uses the term isolated agent environment when the runtime also needs persistence, tools, state, and agent-level controls.

Sandbox names the boundary

Most teams already use sandbox for isolated code execution, which makes it a natural starting point.

Environment names the operating model

Spinup adds files, packages, browsers, secrets, and network policy around one agent, not just a disposable execution slot.

The distinction matters in practice

Once state and controls live with the agent, the runtime does more than sandbox a single run.

FAQ

Common questions about isolated agent environments

How is an isolated agent environment different from a sandbox?+

A sandbox is the isolation primitive: it keeps code from touching the host. An isolated agent environment is the operating model around it, including a persistent filesystem, scoped secrets, network policy, and harness configuration that all attach to one agent identity. Sandbox is what contains the run; environment is what the agent lives inside between runs.

How is this different from running each agent in its own container?+

Process or container isolation only separates execution. An agent environment also scopes the mutable surface: filesystem state, installed packages, browser sessions, secrets projection, and outbound network access. Two agents in the same account get distinct environments, not just distinct processes inside a shared worker pool.

What persists in an isolated agent environment between runs?+

The filesystem persists between runs, including installed packages, downloaded artifacts, browser state, and any files the agent writes. Secrets, harness configuration, and network policy are scoped to the environment so the agent picks up where it left off instead of rebuilding the setup from scratch.

How are secrets and network access scoped to a single environment?+

Secrets are projected per environment from the control plane and never shared across agents in the same account. Network access is the environment's own outbound surface today; allow-list and egress rules per agent are on the roadmap. Both controls follow the agent identity, not the underlying compute.

Isolated Environments in the Spinup Runtime

From sandbox language to a complete environment model

The goal is one persistent environment per agent, with clear controls for state, secrets, and network policy. Safe code execution is the floor, not the product.

Early access

One environment per agent. Not one process per run.

Request access if this is the runtime shape your team has been missing.

We reply with a booking link and review the fit before inviting your workspace.