From Fork to Fleet: Designing an Agent Sandbox Cloud

Abhishek Bhardwaj from OpenAI’s RL and agent infrastructure team discusses the architectural challenges and solutions for building a secure and scalable agent sandbox cloud. The talk is framed as a first-principles exploration of sandboxes, their necessity, and key design intuitions.

Introduction and Motivation for AI Agent Sandboxes

Initially, large language models like ChatGPT struggled with tasks requiring verifiable answers, such as mathematical calculations or code execution. While capable of answering questions like “3 + 3 = 6” due to extensive training data, they fail on novel or less common queries (e.g., “how many hours in a strawberry”). The key unlock for these models was providing them with tool-calling capabilities—the ability to execute code. This allows models to “hill climb” and achieve high performance on tasks with verifiable rewards, such as math and programming.

From a training perspective, a typical loop involves a harness presenting a task, the model responding (potentially with code execution), the harness executing that code, and a grader verifying the result. This feedback mechanism trains the model to both identify when to use tools and to generate effective code.

Product-Side Challenges: Security and Sandboxing

On the product side, running model-generated code introduces significant security risks. Although models are generally expected to generate non-malicious code, security best practices dictate treating all generated code as untrusted. Potential threats include attempts to gain root access, exploit kernel vulnerabilities, or exfiltrate data from other users’ sandboxes. Sandboxes are crucial to isolate this untrusted code, ensuring it can perform its tasks without compromising the host system or other users’ data.

While agents can run locally (e.g., Open Interpreter on laptops), the speaker emphasizes that the future lies in persistent, long-running agents in a cloud environment. This aligns with the broader trend of cloud computing, overcoming limitations of local execution like power management or connectivity.

Research vs. Product Sandbox Requirements

Sandbox requirements differ between research and product contexts, though security and reliability are universally critical:

• Research: Optimizes for throughput, aiming to run many training loops and rollouts in parallel to explore various solutions quickly.
• Product: Prioritizes low latency for immediate user interaction and high reliability to prevent user churn and ensure consistent service.

Both contexts require robust security to protect infrastructure and data, as well as high reliability to avoid wasting expensive GPU tokens.

Three Pillars of an Agent Sandbox Cloud

The talk focuses on three core pillars for designing such a cloud:

1. Runtime: How to securely execute untrusted code on a single node.
2. Persistence: Providing agents with durable storage, akin to a disk for a human user.
3. Orchestration: Scaling and managing sandboxes across a fleet of machines.

Pillar 1: Runtime Isolation Technologies

Linux Execution First Principles

Linux executes code with threads as the smallest unit. The kernel provides privileged access via system calls. CPUs operate in different privilege rings: ring zero for kernel mode (highest privilege) and ring three for user mode. System calls involve a hardware context switch to ring zero. The two main attack vectors in Linux are gaining root access (highest privilege in ring three) and kernel exploits (running code in ring zero, giving full system control).

Simplest Execution: fork() and exec()

The most basic approach is an API server that fork()s a process and exec()s the model’s tool. While offering native performance, this method is highly insecure. The forked process has direct kernel access, making it vulnerable to exploits. It also leads to noisy neighbor problems, where a runaway process can consume all resources and crash the node.

Containers: Namespaces and cgroups

Containers improve isolation using two Linux primitives:

• Namespaces: Isolate resources like PID, mount points, and networks, providing an abstract view to processes within the container.
• cgroups: Control and limit resource consumption (CPU, memory) for a group of processes, mitigating noisy neighbor issues.

Despite these improvements, containers still share the same host kernel. An attacker can still attempt to exploit the shared kernel boundary. Seccomp can filter system calls to reduce the attack surface, but it’s difficult to configure without inadvertently blocking legitimate agent functions, hindering flexibility.

GVisor: An Application Kernel Alternative

GVisor addresses the shared kernel problem by implementing many system calls in user space using a Go-based

• Tags:
• AI Agents
• Infrastructure
• Security
• OpenAI
• Orchestration
• Cloud Infrastructure
• MicroVMs
• Sandboxes
• Virtualization
• Containerization
• Persistence
• KVM
• GVisor
• Linux Kernel