Alibaba open-sources OpenSandbox to make AI agents safe to deploy
Alibaba releases OpenSandbox, an open-source unified API for isolated and secure code execution that integrates with LangGraph, Claude Code, and Gemini CLI.
Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchAI, startups & growth insights. No spam.
TL;DR: Alibaba released OpenSandbox on March 3, 2026 — an Apache 2.0-licensed, production-ready sandbox platform that gives AI agents isolated, secure environments for code execution. It ships with SDKs for Python, TypeScript, and Java/Kotlin, integrates natively with LangGraph, Claude Code, Gemini CLI, and OpenAI Codex, and runs on both Docker and Kubernetes. The project directly targets the most dangerous gap in the agentic AI stack: the absence of a standardized execution layer that prevents agent-generated code from compromising host systems.
execd daemon does inside each container and why it matters for performanceEvery serious AI agent — whether it is writing code, browsing the web, running tests, or training a model — eventually needs to execute something on a real machine. That execution has historically happened in one of two ways: directly on the host system (fast, dangerous) or inside loosely configured containers (safer, inconsistent). Neither approach scales. Neither is standardized.
The OWASP Top 10 for Agentic Applications, published in late 2025 and updated in early 2026, identifies unexpected code execution (RCE) as one of the highest-impact risks in autonomous AI systems. The mechanism is straightforward and well-documented: an attacker injects malicious instructions into the data an agent processes — a PDF, a webpage, an email, a RAG document — and the agent, unable to reliably distinguish instructions from data, generates and executes code it was never supposed to run. On an unsandboxed host, that is a full system compromise.
The supply chain dimension is worse. SecurityScorecard confirmed in early 2026 that 135,000 agent framework instances were exposed to the public internet with insecure defaults. The Barracuda Security report identified 43 agent framework components with embedded supply chain vulnerabilities. The OpenClaw malicious skills crisis — the largest confirmed supply chain attack targeting AI agent infrastructure to date — compromised approximately one in five packages across the ClawHub registry.
The engineering response to these threats has been fragmented. Teams building agents in LangGraph use one sandbox setup. Teams using Claude Code use another. Teams running OpenAI Codex use a third. Each integration requires custom infrastructure code, custom lifecycle management, and custom security validation. The result is duplicated effort and inconsistent security posture across the same organization.
OpenSandbox is Alibaba's answer to that fragmentation. Released on March 3, 2026 under the Apache 2.0 license, it provides a single, unified API for isolated code execution that works across frameworks, languages, and runtime environments.
OpenSandbox is a general-purpose sandbox platform for AI applications. The GitHub description is precise: it offers multi-language SDKs, unified sandbox APIs, and Docker/Kubernetes runtimes for scenarios including Coding Agents, GUI Agents, Agent Evaluation, AI Code Execution, and RL Training.
The key word is "unified." OpenSandbox is not another container wrapper. It is an abstraction layer that decouples how agents request execution from how that execution actually runs. A developer writing a LangGraph pipeline calls the same OpenSandbox API whether the underlying runtime is a local Docker container or a distributed Kubernetes cluster. The infrastructure details are invisible to the agent code.
The Apache 2.0 license is a deliberate choice. It permits commercial use, modification, distribution, and sublicensing without copyleft restrictions. For enterprises evaluating whether to build production agent infrastructure on top of OpenSandbox, the licensing removes the legal friction that often slows adoption of open-source security tooling.
OpenSandbox's architecture separates concerns across four distinct layers. Understanding these layers explains both why the system is secure and why it is portable.
| Layer | Role | Key Components |
|---|---|---|
| SDKs Layer | Client interface for agent developers | Python SDK, TypeScript SDK, Java/Kotlin SDK |
| Specs Layer | Standardized communication protocol | OpenAPI specifications for lifecycle + execution |
| Runtime Layer | Execution backend management | FastAPI server, Docker runtime, Kubernetes runtime |
| Sandbox Instances Layer | Isolated execution environments | Containers with execd daemon, Jupyter kernels |
SDKs Layer. This is what agent developers touch directly. Current SDKs cover Python, TypeScript, and Java/Kotlin. C# and Go are on the roadmap. The SDK abstracts all sandbox lifecycle operations — creation, execution, file management, teardown — into simple API calls that look the same regardless of what is running underneath.
Specs Layer. OpenSandbox standardizes communication via OpenAPI specifications that cover two domains: sandbox lifecycle (create, pause, resume, destroy) and code execution (run, stream output, manage state). These specs are the contract between the client SDKs and the runtime layer. Any compliant runtime that implements these specs can be swapped in without changing agent code.
Runtime Layer. A FastAPI-based server manages sandbox lifecycles and routes requests to either Docker or Kubernetes. Docker serves local development. Kubernetes serves production-scale distributed execution. The same API call works in both environments. This is the layer that eliminates the "works on my machine" problem that has plagued sandboxed agent development.
Sandbox Instances Layer. Each sandbox is an isolated container running a Go-based execution daemon called execd. The daemon connects to internal Jupyter kernels, enabling stateful code execution — variables and state persist between execution calls within a session, which is critical for multi-step agent workflows. Output is streamed in real-time over Server-Sent Events (SSE). The container also provides full filesystem management scoped to the sandbox, with no access to the host filesystem.
The choice to implement execd in Go is significant. Go's goroutine model handles concurrent execution requests efficiently at low memory overhead. The daemon's integration with Jupyter kernels means agents get interactive, stateful execution rather than one-shot script runs — the same capability that makes Jupyter valuable for data scientists applies here to agent workflows that need to build state across multiple execution steps.
Real-time output streaming over SSE means agents do not need to poll for results. Output arrives incrementally as code executes, which matters for long-running tasks like model training or large-scale data processing. For GUI Agents, the sandbox provides a full VNC desktop environment — the agent can interact with graphical applications inside an isolated display, never touching the host display server.
OpenSandbox ships with four pre-configured sandbox types, each optimized for a distinct workload category.
| Sandbox Type | Primary Use Case | Key Capability |
|---|---|---|
| Coding Agents | Software development tasks | Full dev environment, language runtimes, package managers |
| GUI Agents | Browser automation, desktop interaction | Full VNC desktop, display isolation |
| Code Execution | High-performance script execution | Optimized compute, stateful Jupyter kernel |
| RL Training | Reinforcement learning workloads | Isolated training environments, resource controls |
Coding Agents sandboxes are the most immediately relevant for teams building software development automation. These environments include full language runtimes, package managers, and development tooling. An agent writing, testing, and iterating on code stays entirely within the sandbox — it cannot reach the host filesystem, network, or process space.
GUI Agents represent a less-discussed but growing workload type. Agents that need to navigate web interfaces, interact with desktop applications, or perform browser automation have historically required either direct host access or complex virtual display setups. OpenSandbox provides a VNC desktop inside the sandbox, isolating display operations completely.
Code Execution sandboxes are optimized for high-performance computation — data processing pipelines, analysis tasks, and scripted operations that need fast startup and clean teardown. The stateful Jupyter kernel means these sandboxes support interactive, iterative workflows rather than just single-shot execution.
RL Training sandboxes address a requirement that most sandbox platforms ignore: reinforcement learning agents need environments they can interact with, reset, and modify repeatedly. Providing isolated training environments with controlled resource limits prevents runaway training processes from consuming host resources or interfering with other workloads.
The practical value of OpenSandbox depends heavily on how well it integrates with the frameworks and model interfaces teams are already using. The current integration list is targeted at the dominant tools in production agentic deployments.
| Integration Type | Tools |
|---|---|
| Model Interfaces | Claude Code, Gemini CLI, OpenAI Codex |
| Orchestration Frameworks | LangGraph, Google ADK |
| Automation Tools | Chrome, Playwright |
LangGraph is the most widely adopted stateful agent orchestration framework in production. LangGraph models agent workflows as directed graphs where agents are nodes and shared state flows between them. OpenSandbox integrates at the execution node level — when a LangGraph agent needs to run code, it calls OpenSandbox rather than executing directly on the host. The stateful nature of OpenSandbox sandboxes aligns with LangGraph's emphasis on durable, persistent execution state.
Claude Code is Anthropic's terminal-based coding agent. It operates with significant autonomy — reading, writing, and executing code across a codebase. Without sandboxing, Claude Code's execution happens on the developer's local machine or CI environment. OpenSandbox integration means Claude Code's execution can be routed through isolated containers, containing any unintended side effects from generated code.
Gemini CLI and OpenAI Codex round out the model interface coverage. These integrations mean teams are not locked into a single model provider to benefit from OpenSandbox's security guarantees. The same sandbox infrastructure works regardless of which model is generating the code being executed.
Google ADK (Agent Development Kit) integration matters for teams building on Google's agent infrastructure. ADK is optimized for Gemini but model-agnostic, and its integration with OpenSandbox means Google's orchestration layer can leverage Alibaba's execution layer — a cross-vendor integration that would have been unusual to see even 18 months ago.
Playwright and Chrome integrations serve GUI Agent workflows. Browser automation inside a sandbox prevents web-based prompt injection attacks from escaping the browser context and reaching the host system.
The sandboxing landscape in 2026 offers several approaches with different security and performance tradeoffs. Understanding where OpenSandbox sits requires mapping the full spectrum.
| Approach | Isolation Level | Performance | Production Ready | API Standard | Framework Integration |
|---|---|---|---|---|---|
| No sandbox | None | Highest | N/A | N/A | Native |
| Docker containers | Process-level | High | Yes | Custom per team | Custom |
| gVisor | Syscall mediation | Medium | Yes | Custom per team | Custom |
| Firecracker microVMs | Hardware boundary | Medium-Low | Yes | Custom per team | Custom |
| Kata Containers | VM-level | Medium | Yes | Custom per team | Custom |
| E2B | Container-level | High | Yes | Unified | LangChain, some others |
| OpenSandbox | Container-level | High | Yes | Unified | LangGraph, Claude Code, Gemini CLI, Codex, ADK |
The critical differentiator in this table is not isolation level — it is the combination of a unified API standard and broad framework integration. gVisor and Firecracker provide stronger hardware-level isolation, but they require custom integration work for every framework. A team using LangGraph and Claude Code would need to build two separate integration layers. OpenSandbox provides one.
For teams evaluating threat models: NVIDIA's security guidance for agentic workflows recommends hardware-boundary isolation (Firecracker microVMs, Kata Containers) for the highest-risk workloads — cases where the code being executed is fully untrusted and potentially adversarial. OpenSandbox's container-level isolation is appropriate for the majority of production agent workloads where the risk profile is lower but the operational complexity budget is limited.
The honest assessment: OpenSandbox trades the strongest possible isolation guarantees for standardization and developer experience. For most teams building production agents in 2026, that is the right trade.
The practical implication of OpenSandbox's unified API is worth making concrete. Consider a team migrating from local development to production deployment.
In local development, they configure OpenSandbox against a Docker runtime. Sandboxes spin up as local containers. The agent code calls sandbox.create(), sandbox.execute(code), sandbox.read_file(path), and sandbox.destroy() using the Python SDK.
In production, they switch the runtime configuration to Kubernetes. The agent code does not change. The same SDK calls now trigger distributed container scheduling across a Kubernetes cluster. Lifecycle management, resource limits, and cleanup are handled by the OpenSandbox runtime layer.
This is the architectural bet Alibaba is making: that standardizing the execution API is more valuable than optimizing for any single runtime. The history of infrastructure tools suggests they are right. The teams that won in containerization were not the ones with the best individual container implementations — they were the ones who standardized the interface.
OpenSandbox's security model addresses four of the most common agent execution threat vectors documented in the OWASP Top 10 for Agentic Applications 2026.
Uncontrolled code execution. Agent-generated code runs inside an isolated container with no access to the host filesystem, network, or process space. A prompt injection attack that causes an agent to generate malicious code cannot reach the host. The blast radius of a compromised agent is contained to the sandbox instance.
Filesystem access. The execd daemon provides filesystem management scoped to the sandbox. Agents can read and write files within their sandbox. They cannot traverse to the host filesystem. This prevents data exfiltration attacks that rely on agents reading sensitive files outside their intended scope.
Resource exhaustion. Container-level resource controls prevent a runaway agent process from consuming host CPU, memory, or disk. This matters for RL Training workloads in particular, where feedback loops can cause unconstrained resource consumption if not bounded.
State persistence between attacks. Because each sandbox instance is isolated, a compromised sandbox does not provide a foothold into other sandbox instances or the host. Multi-tenant agent deployments can run multiple sandboxes simultaneously without cross-contamination.
What OpenSandbox does not fully address: network-level isolation beyond the container boundary, supply chain attacks on the sandbox images themselves, and kernel-level exploits that escape container isolation. Teams with high-security requirements should layer gVisor or Firecracker underneath OpenSandbox's container runtime for defense in depth.
OpenSandbox's current SDK coverage and the published roadmap signal where Alibaba is taking the project.
| Language/Runtime | Status |
|---|---|
| Python SDK | Available |
| TypeScript SDK | Available |
| Java/Kotlin SDK | Available |
| C# / .NET SDK | Roadmap |
| Go SDK | Roadmap |
The addition of C# and Go will materially expand the enterprise addressable market. C# is the dominant language in Microsoft-stack enterprise environments. Go is increasingly the language of choice for infrastructure tooling and backend services. Both SDK additions are straightforward given that execd itself is written in Go — the language support for execution already exists, the SDK wrappers are the remaining work.
The Kubernetes runtime support is already production-ready, which positions OpenSandbox for large-scale enterprise deployments without a migration step. Teams can start on Docker locally and push to Kubernetes in production using identical agent code.
OpenSandbox arrives at a specific moment in the maturation of agentic AI infrastructure. The model layer has largely commoditized — most teams use multiple models and route tasks based on cost, latency, and capability. The orchestration layer has consolidated around a small number of frameworks, with LangGraph and OpenAI's Agent SDK leading production deployments.
The execution layer has remained the most fragmented. Every team building production agents has had to answer the same questions independently: where does agent code run, how is it isolated, how is lifecycle managed, how does it integrate with the orchestration framework? OpenSandbox is a credible attempt to answer those questions once, at the infrastructure level, in a way that is framework-agnostic.
Alibaba's position in this market is not accidental. The company operates one of the largest cloud infrastructures in Asia through Alibaba Cloud, and agent execution at scale is a core use case for that infrastructure. OpenSandbox is both a genuine open-source contribution and a proof point for Alibaba's agent execution capabilities.
The Apache 2.0 license means competitors — including cloud providers building their own agent infrastructure — can adopt, modify, and redistribute OpenSandbox. This is a deliberate ecosystem play. Alibaba benefits from becoming the reference implementation of standardized agent execution, even if individual cloud providers deploy their own variants.
What is OpenSandbox? OpenSandbox is an open-source sandbox platform released by Alibaba on March 3, 2026. It provides AI agents with isolated, secure environments for code execution through a unified API that works across Docker and Kubernetes runtimes. It is licensed under Apache 2.0.
What agent frameworks does OpenSandbox integrate with? OpenSandbox has native integrations with LangGraph and Google ADK for orchestration, Claude Code, Gemini CLI, and OpenAI Codex for model interfaces, and Playwright and Chrome for browser automation.
What programming languages does OpenSandbox support? OpenSandbox currently ships SDKs for Python, TypeScript, and Java/Kotlin. C# and Go SDKs are on the development roadmap.
How is OpenSandbox different from just using Docker containers? Docker containers provide isolation but no standardized API, no framework integration, and no lifecycle management designed for AI agent workflows. OpenSandbox adds a unified API layer, framework-specific integrations, a Go-based execution daemon with Jupyter kernel support, real-time output streaming over SSE, and both local and production-scale runtime options through a single interface.
What security threats does OpenSandbox address? OpenSandbox contains agent-generated code within isolated containers, preventing uncontrolled host access, filesystem traversal, cross-sandbox contamination, and resource exhaustion. It directly addresses the RCE and prompt injection execution risks identified in OWASP's Top 10 for Agentic Applications 2026.
Can OpenSandbox be used in production at scale? Yes. The Kubernetes runtime support is production-ready and supports distributed, large-scale sandbox scheduling. The same API used in local Docker development works against the Kubernetes runtime without code changes.
What are the limitations of OpenSandbox's security model? Container-level isolation does not provide hardware-level boundaries. Kernel exploits that escape container isolation remain possible. Teams with the highest security requirements should layer gVisor or Firecracker underneath OpenSandbox's container runtime. Network isolation beyond the container boundary also requires additional configuration.
How does the stateful execution model work?
The execd daemon inside each sandbox connects to an internal Jupyter kernel, which maintains variable state and execution context between calls. Agents can run multiple code blocks sequentially with state persisting across calls — the same capability that makes Jupyter valuable for interactive development applies to multi-step agent workflows.
Meta's first Llama developer conference unveils a hosted Llama API, 1 billion downloads milestone, Llama 4 Scout and Maverick, and a new SDK that rivals OpenAI's platform.
Cursor launched Automations, a system that dispatches specialized coding agents automatically based on triggers — new commits, Slack messages, or scheduled timers — ending the prompt-and-monitor loop.
Check Point Research discloses two Claude Code vulnerabilities — CVE-2025-59536 (CVSS 8.7) for remote code execution and CVE-2026-21852 (CVSS 5.3) for API key theft — triggered by opening malicious git repos.