Is a container enough, or do I need a microVM?

It depends on what runs inside. For your own code with an injection risk, a hardened container with no credentials and constrained egress is usually proportionate. For arbitrary code from untrusted sources, assume the shared kernel can be escaped and use a microVM.

How does this differ from least-privilege tooling?

Least privilege bounds what the agent may ask for; the sandbox bounds what happens when something runs anyway. One governs the request, the other the environment it executes in, and agents that run code need both.

The sandbox slows everything down. Is it worth it?

Compare against the alternative cost, not against zero. Most of the latency is environment startup, which pools and pre-warmed images largely remove; the failure it prevents is a compromise of the host that runs the agent.

Safety & oversightUpdated 2026-08-22 · Version 1.0

Sandboxed Execution

Run everything an agent generates or invokes inside a disposable, isolated environment with no ambient credentials, a bounded filesystem, controlled egress and hard resource caps. The sandbox is not there because the agent is malicious; it is there because the agent's input can be.

Evidence: Industry observationConfidence: HighSource: Industry observationSource: Personal experienceSource: Paper

Machine-readable: JSON

Definition

Sandboxed execution is the practice of running agent-generated code and agent-invoked actions inside an isolated, ephemeral environment whose filesystem, network, credentials and resources are bounded by the host rather than by the agent, so that a hijacked or mistaken agent cannot affect anything outside it.

Problem

An agent that executes code on the host inherits the host: its credentials, its filesystem, its network position. One successful injection or one confidently wrong command is then indistinguishable from a compromise of the machine.

When to use it

Use it whenever an agent runs code, executes shell commands, installs packages or processes untrusted files. The threshold is low: if the agent can cause execution, the execution belongs in a sandbox.

Solution

Make it ephemeral. Create the environment per task, destroy it after, and never carry state forward that the next task did not ask for. Persistence is how a one-off compromise becomes a foothold.

Remove ambient credentials. Nothing in the environment should be usable simply because it is present; inject only the narrowly scoped secrets the task needs, for its duration.

Bound the filesystem to the working set. Mount the repository or the input, nothing else, and mount read-only whatever does not need writing.

Constrain egress inside the sandbox, not around it. The isolation and the network policy are the same control from the attacker's point of view, and a sandbox with open network is a jail with a phone.

Cap resources — CPU, memory, disk, wall-clock, process count. Runaway consumption is the failure mode that arrives first and most often, usually without any adversary at all.

Log what crossed the boundary: which files came in, which came out, which destinations were reached. The boundary is only useful if you can see what passed through it.

Components

An isolation primitive: container, microVM or equivalent, chosen for the strength the workload needs.Ephemeral lifecycle management, with destruction as the default rather than a cleanup step.A secret-injection path scoped to the task and its duration.A network policy applied inside the sandbox boundary.Resource quotas and timeouts, enforced by the host.Boundary logging: inputs, outputs and destinations.

Benefits

Converts 'the agent ran something bad' from an incident into a discarded container.
Makes it safe to give an agent genuine execution ability, which is often what makes it useful at all.
Bounds honest mistakes as well as attacks — the same control catches an infinite loop and an injected payload.
Gives a clean place to observe: everything the task touched crossed one boundary.

Risks

Isolation weaker than assumed: a shared kernel is not a security boundary against determined escape, and treating a container as a microVM is a category error.
Credentials smuggled in for convenience — one mounted config file undoes the whole pattern.
Sandboxes that quietly become persistent because rebuilding is slow, so the ephemerality that carried the guarantee is gone.
Escape via the shared surface that remains: mounted volumes, the orchestrator API, or the network the sandbox still reaches.

When not to use it

Read-only agents with no execution capability, where there is nothing to isolate and the cost buys nothing.
Latency-critical inline paths where environment startup dominates the task and a narrower control — a restricted interpreter, a pure function — fits better.
When the sandbox would need the very credentials it exists to withhold, which is a sign the task should be split rather than isolated.

Technologies

ContainersmicroVMs (Firecracker / gVisor)Ephemeral workspacesResource quotas and timeoutsScoped secret injection

Examples

A coding agent that clones into a fresh container per task, with the repository mounted, no cloud credentials present and egress limited to the package registry. A malicious dependency install destroys a container and nothing else.
A data-analysis agent executing generated Python in a microVM with the input dataset mounted read-only, no network at all and a wall-clock cap. The generated code can be wrong; it cannot be expensive or exfiltrating.
A document-processing agent that opens untrusted PDFs inside a disposable environment, because a parser exploit in an uploaded file is a real path to the host and the file arrived from outside.

KPIs

Share of executions sandboxed: The coverage number. Anything running outside the sandbox is the actual security posture, regardless of what the sandboxed share does.
Sandbox lifetime: How long environments live. Rising lifetimes mean ephemerality is eroding into persistence.
Resource-cap hits: Tasks stopped by a quota or timeout. A useful mix of runaway generations and genuine limits set too tight.
Secrets present at runtime: Count of credentials reachable inside the environment. The target is the minimum the task needs, and often zero.

Observed failure modes

The convenience mount: a home directory, a credentials file or a socket mounted in so a task would stop failing.
Persistent reuse: the environment stops being per-task because rebuilding costs too much, so state and compromise both survive.
Open egress inside the boundary: strong isolation with a free network is containment against the filesystem only.
Orchestrator reachability: the sandbox can call the API that manages sandboxes, which is escape by design rather than by exploit.

Lessons learned

Isolate execution before you trust generation. The sandbox is what makes it reasonable to let an agent run code at all.
Ephemeral is the security property; isolation alone only postpones the problem.
The credential that is not present cannot be stolen — and it is the only control that holds after an escape.
Most sandbox activations are honest mistakes, not attacks. That is the pattern working, not evidence it was unnecessary.

FAQs

Is a container enough, or do I need a microVM?: It depends on what runs inside. For your own code with an injection risk, a hardened container with no credentials and constrained egress is usually proportionate. For arbitrary code from untrusted sources, assume the shared kernel can be escaped and use a microVM.
How does this differ from least-privilege tooling?: Least privilege bounds what the agent may ask for; the sandbox bounds what happens when something runs anyway. One governs the request, the other the environment it executes in, and agents that run code need both.
The sandbox slows everything down. Is it worth it?: Compare against the alternative cost, not against zero. Most of the latency is environment startup, which pools and pre-warmed images largely remove; the failure it prevents is a compromise of the host that runs the agent.