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

What it is

The piece frames agent sandboxing as a distinct, structural problem rather than a weaker version of classical sandboxing: it names three underlying motivations for sandboxing generally — security (active adversary), blast radius (buggy code), reproducibility (consistent behavior) — and argues most "is X a real sandbox" debates are actually disputes about which of these three someone meant.

How it works

Two under-discussed isolation surfaces anchor the argument: network egress and identity/ambient authority. On network, the piece gives a concrete mechanism — an isolated process with unrestricted egress can reach the cloud metadata endpoint 169.254.169.254 and mint itself credentials for the host's cloud role, meaning filesystem isolation alone is a false sense of security. On identity, it notes processes inherit ambient authority via environment variables, mounted credential files, and SSH agent sockets — so a filesystem-isolated sandbox can still leak a token usable elsewhere.

For agent sandboxes specifically, it introduces a two-layer model: a container/microVM layer handles "this build script is malicious" (e.g., a malicious npm install script), while a separate policy layer handles "this agent was talked into something reasonable-looking and wrong." It also makes a structural distinction from classical sandboxes: a classical sandbox bounds a single process and can be reasoned about statically (seccomp profile, mount list); an agent session accumulates permissions and context over hundreds of tool calls, so its effective authority can only be known after the fact by having logged it at the time.

flowchart TD
    A[Agent process] -->|egress unrestricted| B[169.254.169.254 metadata endpoint]
    B --> C[Mint host cloud-role credentials]
    A -->|filesystem isolated only| D[Still has env vars / SSH agent socket / mounted creds]
    D --> E[Token usable outside sandbox]

Preconditions / Affected

Applies to any sandboxed process (container, VM, or agent) that retains unrestricted network egress or inherits ambient credentials (env vars, mounted credential files, SSH agent sockets) despite filesystem-level isolation.

What to do

• Treat egress allowlisting as the highest-value and most-often-skipped control; block the cloud metadata endpoint by default.
• Scope credentials narrowly and short-lived (e.g., a token for one repository, not an org-wide PAT).
• Classify agent actions by reversibility: auto-approve reads, gate writes/network calls/package installs/git push/shell commands behind review.
• Layer defenses: container/microVM for arbitrary code execution risk, plus a separate action-policy layer for prompt-injection-driven misuse.
• Log command transcripts, file diffs, tool-call records, and approvals at the time they happen, since session authority can't be statically reasoned about afterward.

Caveats

The piece is explicit that prompt injection has no clean technical fix ("you cannot filter your way out of it") — the stated mitigation is only to limit blast radius (nothing valuable in reach, nowhere to send it, nothing irreversible without a human), not to prevent the injection itself.