Agent Landscape #5: Sandboxing — The Missing Security Boundary

The Problem

Real incidents from production agents:

• Agent asked to "clean up old test data" → ran DELETE FROM users WHERE created_at < '2024-01-01' — on production

• Code-generation agent hallucinated pip install malicious-package → executed in the same process with network access

• Research agent sent company-internal documents to an external summarization API → data exfiltration via tool call

• Agent in an infinite retry loop called a paid API 10,000 times in 3 minutes → $2,400 bill

The root cause is always the same: the tool executes with the same permissions as the agent process. No isolation, no scoping, no limits.

This isn't a hypothetical risk — it's the reason enterprise CISOs block agent deployments. The question isn't whether your agent will hallucinate a dangerous action. It's when.

Research & Industry Context

Key Papers & Concepts

Firecracker (Agache et al., 2020, AWS) — lightweight microVMs that boot in <125ms with minimal memory overhead. The technology powering Lambda and Fargate. Proved that VM-level isolation can be fast enough for interactive workloads.

ToolEmu (Ruan et al., 2024, Stanford) — emulation framework for evaluating LLM agent tool-use safety. Simulates tool execution to identify dangerous behaviors (data leakage, unauthorized actions) without real-world consequences. Showed that even GPT-4 agents commit unsafe actions in 23% of risky scenarios.

Anthropic's "Computer Use" safety research (2024) — documented the risk model of agents with access to real computers. Key findings: prompt injection via screen content, unintended action cascades, and the need for human-in-the-loop gates at irreversible actions.

Sabotage Evaluations for Frontier Models (Anthropic, 2024) — framework for testing whether AI agents deliberately undermine oversight mechanisms. Directly motivates sandboxing: agents with unrestricted tool access can exfiltrate data or disable monitoring even without explicit intent.

How Industry Solves This

Anthropic (Claude Code): Permission system — tools categorized by risk level. Destructive operations require explicit user approval. File system access scoped to project directory. No network requests without user visibility.

OpenAI (Code Interpreter): Ephemeral sandbox per session — Python code runs in a containerized environment with no network access, no persistence between sessions, and resource limits. The gold standard for "code execution that can't hurt anything."

Cursor: Runs generated code in the user's own environment but with a diff-based approval UI. The user sees exactly what will change before it executes. Human-in-the-loop as the security boundary.

Replit Agent: Full VM-level isolation per user project. Agent can modify files, run code, install packages — all within a sandboxed Nix environment that's destroyed on session end.

AWS (Bedrock Agents): Lambda-based tool execution. Each tool is a Lambda function with IAM roles scoped to minimum permissions. Network isolated by VPC. Cost-bounded by timeout.

Common production patterns:

• Tiered approval (low-risk auto-approve, high-risk human-in-the-loop)

• Credential scoping (each tool gets only what it needs)

• Ephemeral by default (no state leaks between executions)

• Cost circuit breakers (kill execution if spend exceeds threshold)

• Audit logging (full input/output trace of every tool execution)

Open Source Solutions

Four approaches exist, each at a different point on the security vs. performance tradeoff.

Daytona — 73k stars

What it is: Secure, elastic infrastructure for running AI-generated code. Sub-90ms sandbox spin-up with snapshot/restore capabilities. The fastest-growing sandboxing project in the agent ecosystem.

Strengths:

• Sub-90ms sandbox creation (faster than E2B)

• Snapshot/restore — pause and resume execution state

• MCP server built-in (agents discover sandbox capabilities via protocol)

• Self-hostable on AWS/GCP (not managed-only)

Limitations:

• Newer project — less battle-tested in production

• Focus is code execution (not API-call sandboxing)

Verdict: The new default for agent code execution. Fastest, self-hostable, MCP-native.

E2B — 12k stars

What it is: Cloud sandboxes purpose-built for AI code execution. Each sandbox is a Firecracker microVM with its own filesystem, network, and process space.

(See sandbox flow diagram above)

Strengths:

• True VM-level isolation (not just containers)

• Fast boot (~150ms) — viable for interactive use

• Multi-language (Python, JS, R, Julia)

• Pre-built templates for common environments

Limitations:

• Managed service only (can't self-host easily)

• Code execution focus — doesn't help with API calls

• Cost per sandbox-hour adds up for long sessions

Verdict: Strongest isolation guarantee. Choose when security matters more than cost.

Modal — (proprietary)

What it is: Serverless Python compute. Decorate a function, it runs in the cloud with GPU/CPU scaling.

@modal.function(gpu="A10G", timeout=300)
def run_tool(code: str) -> str:
    return exec_sandboxed(code)

Strengths:

• Best DX for serverless Python

• Instant GPU access (no cluster management)

• Container caching (millisecond cold starts on repeat calls)

• Pay per second of actual compute

Limitations:

• Proprietary (can't self-host)

• Not agent-aware (general compute)

• Python-only

Verdict: Best when agent tools need GPUs. Pay-per-second without Kubernetes.

Docker-Based Sandboxing

What it is: Run each tool call in a fresh container with scoped permissions, network restrictions, and resource limits.

Strengths:

• Self-hostable (no vendor dependency)

• Fine-grained permission control

• Familiar to any ops team

• Can scope credentials per-container

Limitations:

• Slower cold start (~1-5s)

• Isolation weaker than VMs (shared kernel)

• Requires container orchestration

Verdict: Right choice when you need self-hosted sandboxing for API-call tools and already run Kubernetes.

The Isolation Spectrum

What Agents Need from Sandboxing

Comparison

Key Takeaway

Most agent frameworks run tools in-process — same trust boundary as the agent itself. Fine for demos. In production, the tool execution layer needs:

• Scoped credentials (principle of least privilege)

• Resource limits (prevent runaway cost/compute)

• Network restrictions (prevent data exfiltration)

• Audit logging (know what every tool call did)

The right abstraction: a Sandbox interface with multiple backends (Docker for dev, Daytona/E2B for production). The agent developer picks the isolation level; the framework handles the rest.