Sandboxes Explained: What Each Type Actually Isolates | Blog | Endor Labs

What it claims

Every sandbox isolates only some resources and leaves the rest shared. Incidents happen in the gap between what a boundary covers and what the operator assumed it covered. Before choosing one, decide which job it is doing:

• Security against an active adversary.
• Blast radius against buggy code.
• Reproducibility.

These need very different boundaries. A sandbox built for reproducibility will not survive an attacker, and one built for hostile multi-tenancy is too expensive for unit tests. For coding agents, the page argues that prompt injection cannot be filtered out, because injected instructions look the same as legitimate ones. The realistic goal is to make a successful injection "boring": nothing valuable in reach, nowhere to send it, and nothing irreversible without a human.

How it works

Points the summary does not carry:

• Two often-missed isolation axes.
• Network: a process that can reach 169.254.169.254 (the cloud metadata endpoint) can often mint credentials for the host's cloud role.
• Identity: environment variables, mounted credential files and SSH agent sockets pass ambient authority into the sandbox even when the filesystem is fully isolated.
• Containers depend on configuration, not technology.
• Weak setup: privileged mode, a mounted Docker socket, or host paths bind-mounted for convenience.
• "Serious boundary" setup: a tight seccomp profile, no added capabilities, a read-only root filesystem, a non-root user, and no egress.
• Startup costs stated on the page.
• Firecracker microVM boots in about 125 ms.
• Containers start in milliseconds.
• V8 isolates start in single-digit milliseconds, which is why Cloudflare Workers can run thousands of tenants per process.
• Language-runtime isolation costs microseconds.
• Java's SecurityManager was deprecated for removal in Java 17.
• Defense in depth. Browsers stack a process per site, privilege-stripped renderers and Site Isolation, and are still escaped at Pwn2Own most years. The page's conclusion is that strength comes from the stack, not from any single wall.
• Agent architecture is two layers. Agents run arbitrary code as routine work; for example, npm install executes install scripts written by strangers. The page therefore puts the agent inside a container or microVM and applies action policy on top. Each layer handles a different failure:

flowchart TD
  A[Agent tool call] --> B{Action class}
  B -->|read| C[Auto-approve]
  B -->|write / shell / install / push / network| D{Human approves?}
  D -->|no| E[Blocked]
  D -->|yes| F[Execute]
  C --> G[Container or microVM]
  F --> G
  G --> H{Egress allowlist}
  H -->|registry, Git host| I[Allowed]
  H -->|metadata endpoint, other| J[Blocked]
  G -.-> K[Audit log: transcripts, diffs, approvals]

• The container layer handles "this build script is malicious."
• The policy layer handles "the agent was talked into something reasonable-looking and wrong."

The page ranks egress allowlisting as the highest-value control and the one most often skipped.

Limits

• Human-in-the-loop approval degrades fastest. An agent that prompts forty times an hour trains its operator to approve without reading.
• Reviewable is not the same as approved. A diff only gives approval meaning if someone actually reads it.
• An agent's effective permissions build up over a session. They span hours and hundreds of tool calls, so they cannot be reasoned about statically the way a seccomp profile can. You only know them afterward if you logged them at the time.
• This is a vendor primer with no measurements. It calls gVisor and Kata "cost-performant" without numbers. Its own coverage of current agent tooling and its gaps is deferred to later articles in the series.