OpenAI Agents SDK: Shipping Native Sandboxing Without the Hype

The gap between a working agent demo and a production-grade pipeline is rarely about model intelligence. It is almost always about infrastructure. For too long, operators have stitched together third-party containers, wrestling with ephemeral environments and fragile networking just to get an agent to safely execute code. The April 2026 update to the OpenAI Agents SDK fundamentally shifts this dynamic by introducing native sandbox execution as a first-class primitive.

This isn’t just a convenience feature; it is a necessary evolution for anyone building long-running agents that interact with files and commands. When we talk about “safer” automation, we are talking about deterministic boundaries. The new SDK allows us to separate the orchestration layer from the compute plane, ensuring that untrusted code execution doesn’t bleed into the control plane.

The Infrastructure Gap in Agent Development

In the early days of agent development, the primary challenge was getting the model to reason correctly. Today, the challenge is getting the model to act safely at scale. The problem has shifted from prompt engineering to infrastructure engineering. When an agent needs to read a file, run a script, or modify a database, it requires an execution environment. Historically, this meant spinning up Docker containers, managing their lifecycle, and handling the complex I/O between the agent’s control logic and the sandboxed compute.

This approach is brittle. It introduces latency, increases operational overhead, and creates security blind spots. The April 2026 update to the OpenAI Agents SDK addresses this by bundling primitives like sandboxing and MCP integration directly into the framework. This allows developers to define execution boundaries declaratively rather than imperatively.

Sandboxing is not a silver bullet, but it is the foundation. Without a secure execution environment, any security model built on top of it is compromised. The SDK’s new approach allows us to focus on the logic of the agent rather than the plumbing of the environment.

Native Sandbox Execution: What Changed

The core architectural change in the new SDK is the clear separation between the harness (the control plane) and the compute plane (the sandbox execution environment). The harness handles model calls, orchestration, and state management. The sandbox handles file I/O, command execution, and any potentially unsafe operations.

This separation is critical for security. By isolating the compute plane, we ensure that even if the agent is compromised or makes a mistake, the damage is contained within the sandbox. The SDK supports seven built-in hosted sandbox providers: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. It also supports custom implementations, allowing for flexibility in deployment.

The initial release prioritizes Python, with TypeScript support planned for future updates. This is a pragmatic choice, given Python’s dominance in the AI/ML space, but it means TypeScript developers will need to wait for parity. For now, the focus is on delivering a robust, secure foundation for Python-based agents.

The split between harness and compute also simplifies the developer experience. Instead of managing multiple services, developers can define their sandbox requirements in code and let the SDK handle the rest. This reduces the cognitive load and allows for faster iteration.

Designing Safe Workspaces and Manifests

One of the most critical aspects of sandboxing is the design of the workspace and manifest. The manifest defines the files, directories, and storage mounts available to the sandbox. It is the blueprint for the execution environment.

Best practices for manifest design include using relative paths and scoped mounted storage. This ensures that the sandbox is isolated and that it only has access to the resources it needs. Task specs should be defined in workspace files like AGENTS.md, which allows for clear separation of concerns between the environment configuration and the agent’s instructions.

Handling ephemeral workspace entries is also important. Sandboxes are often short-lived, so any state that needs to persist must be explicitly saved to a persistent store. Snapshot persistence can be used to save the state of the sandbox and restore it later, but this should be done carefully to avoid state drift.

The official documentation provides detailed guidance on manifest design, emphasizing the importance of defining boundaries clearly. You can find these best practices in the OpenAI API documentation on Sandbox Agents.

Orchestration Patterns for Safer Automation

With the infrastructure in place, the next step is to design orchestration patterns that leverage the sandbox effectively. There are two primary patterns for composing sandbox agents with non-sandbox agents: handoffs and agents as tools.

Handoffs are useful for moving document-heavy work from an intake agent to a sandbox reviewer. The intake agent can process the initial request and then hand off the task to a sandbox agent that has the necessary permissions and environment to perform the work. This separation of concerns improves security and maintainability.

Agents as tools involve exposing multiple sandbox agents as tools that can be called by other agents. This is done using Agent.as_tool() with a specific SandboxRunConfig. Each tool call can have its own isolated workspace, ensuring that the agents do not interfere with each other. This pattern is particularly useful for complex workflows that require multiple specialized agents.

Integrating MCP servers and local tools within the sandbox boundary is also possible. This allows the sandbox to interact with external systems in a controlled manner. However, this requires careful configuration to ensure that the sandbox does not have access to sensitive resources.

The technical guide on composing sandbox agents provides detailed examples of these patterns, including code snippets for implementing handoffs and tool-based orchestration.

Security Realities: Beyond the Sandbox

It is crucial to understand that sandboxing alone is not sufficient for security. It is a foundation, not a complete security model. A sandbox can be breached, and even if it is not, the agent within it can still make mistakes.

To build a truly secure system, sandboxing must be paired with least-privilege credentials, network restrictions, guardrails, and human-in-the-loop review. Least-privilege credentials ensure that the agent only has access to the resources it needs. Network restrictions prevent the agent from communicating with unauthorized endpoints. Guardrails provide additional layers of protection by validating the agent’s actions before they are executed.

Human-in-the-loop review is essential for long-running agents. Even with all the safeguards in place, there is always a risk of error. Having a human review the agent’s actions before they are committed to production can prevent catastrophic failures.

The article on building safer long-running agents emphasizes that sandboxing is just the first step. It provides a conceptual pattern for risk classification and policy enforcement that goes beyond the technical implementation.

Choosing a Provider: Modal, E2B, and Others

With the SDK supporting multiple providers, the choice of sandbox provider becomes a critical decision. The providers differ in terms of concurrency, cold starts, isolation, and cost.

Modal is often cited for its capabilities, including gVisor isolation, massive concurrency, and fast cold starts. This makes it a strong choice for high-throughput applications. E2B is another popular option, known for its ease of use and integration with the SDK.

When deciding between hosted providers and built-in Docker/Unix-local clients, consider the scalability requirements. Hosted providers are generally better for dynamic workloads, while local clients may be sufficient for development and testing.

The evaluation of best code execution sandboxes provides a detailed comparison of the available options, focusing on the technical capabilities of each provider.

Sources and further reading

• OpenAI updates Agents SDK, adds sandbox for safer code execution – Help Net Security
• OpenAI Agents SDK 2026: Native Sandbox and Subagents | AI Automation Global
• OpenAI Agents SDK 2026: Building Safer Long-Running Agents …
• Sandbox Agents | OpenAI API
• Concepts – OpenAI Agents SDK
• Best Code Execution Sandbox for OpenAI Agents SDK in 2026