OpenSandbox Review: Should You Self-Host Your AI Agent Sandbox?

OpenSandbox is one of the most complete open-source control planes for teams that want AI agents to run code, use browsers or operate a remote desktop on infrastructure they control. It combines lifecycle APIs, five sandbox SDKs, a CLI, an MCP server, Docker and Kubernetes backends, network policy, a credential broker and optional gVisor, Kata or Firecracker isolation. The Apache 2.0 license removes a software licence fee. It does not remove platform engineering.

Our verdict after reviewing the repository, current documentation, release process and roadmap on 16 August 2026: shortlist OpenSandbox when self-hosting, runtime choice and a portable API matter enough to justify operating the security boundary. Use a managed sandbox when speed to market and an external service owner matter more. Do not treat the local Docker quick start as evidence that a production multi-tenant deployment is secure.

This is a product-specific production-readiness review. For incident-led containment controls, use our 12-control AI agent eval sandbox checklist. For the host stack below the control plane, read our Linux infrastructure guide for AI agents. Keeping those intents separate avoids confusing a platform review with a general security standard.

What is OpenSandbox?

OpenSandbox is a self-hostable sandbox lifecycle and execution platform for AI applications. The current OpenSandbox repository is public under Apache 2.0 and lists Python, JavaScript or TypeScript, Java or Kotlin, C# or .NET and Go SDKs. It includes examples for Claude Code, Gemini CLI, Codex CLI, Qwen Code and Kimi CLI, plus Chromium, Playwright, VNC desktops and VS Code Web.

The older alibaba/OpenSandbox GitHub URL now redirects to the opensandbox-group organization. Several package coordinates still carry Alibaba naming. GitHub stars are a useful discovery signal, not a security or support warranty.

The official architecture documentation draws these boundaries explicitly. That separation is the product's strongest design choice: applications depend on public contracts, while Docker, Kubernetes, execution and egress details remain behind provider interfaces.

What does the viral OpenSandbox post get right?

The post correctly identifies the unusually broad surface. This is not just a Python wrapper around docker run.

• Code, files and processes: the execution daemon supports command streaming, background jobs, file operations and resource metrics.
• Browsers and desktops: official examples cover headless Playwright, Chromium with VNC, a full desktop and VS Code Web.
• Coding agents: documented examples run Codex CLI, Claude Code, Gemini CLI and other harnesses inside a sandbox.
• Portable clients: five base SDKs and OpenAPI contracts reduce dependence on one application language.
• Local to cluster: the same lifecycle surface can target a local Docker host or Kubernetes.
• MCP: the server exposes focused lifecycle, command and text-file tools to MCP-capable clients.

What the post compresses into one bullet is the important part: gVisor, Kata and Firecracker are not all active automatically. They are operator-selected runtimes with different prerequisites, compatibility and failure modes.

Is OpenSandbox actually isolated?

It can be, but the isolation level is a deployment decision. OpenSandbox can use ordinary runc, gVisor, Kata Containers or Kata with Firecracker. The official secure runtime guide says administrators install and configure the runtime first, then set it once at server level. The server validates availability at startup and applies that choice to sandboxes.

No runtime makes an over-privileged API key, writable control plane or open network safe. Containment is the product of the whole boundary, not the logo of the hypervisor.

Does Credential Vault keep API keys out of the sandbox?

Yes, for supported HTTPS traffic when it is configured correctly. The host-side SDK writes real credentials to the egress sidecar. The workload receives a fake or empty value. For an exact binding match, the sidecar injects the real authentication header into the outbound request and redacts vault responses.

The official Credential Vault guide also documents the constraints that a buyer should test: it requires dns+nft enforcement, Credential Proxy, a network policy and a default-deny posture. DNS-only mode is refused because direct-IP traffic could bypass policy. Transparent service-mesh sidecars in the same network namespace are not currently supported. Bindings should be narrowed by scheme, host, method and path.

This is a material advantage over placing a reusable provider key in the agent's environment. It is still a credential broker that your team deploys and protects. Test direct IPs, alternate DNS paths, redirects, encoded paths, certificate handling, logs and ambiguous bindings before production.

What will your team have to operate?

1. The control plane: API authentication, availability, versioning, backups for server-managed state and emergency termination.
2. The runtime fleet: Docker hosts or Kubernetes nodes, secure runtimes, kernel and runtime patches, image pulls and capacity.
3. Network boundaries: ingress authentication, deny-by-default egress, DNS, metadata endpoints, private ranges and per-workload exceptions.
4. Supply chain: approved images, digest pinning, SBOM and vulnerability policy, package mirrors and base-image rebuilds.
5. Observability: external logs for lifecycle events, commands, files, network decisions, identity, spend, policy denials and operator actions.
6. Data lifecycle: workspace persistence, snapshot retention, deletion, customer-data location and forensic holds.
7. Abuse and incident response: quotas, runaway-process limits, stop authority, credential revocation and tested containment.

OpenSandbox now documents namespace-based Kubernetes multi-tenancy with tenant-specific API keys. Docker mode does not support that feature. Namespace separation is useful, but a production review still has to cover cluster-wide controllers, registry access, node runtimes, shared telemetry and any route that crosses namespaces.

Is OpenSandbox production-ready?

It is ready for a serious production pilot, not for unreviewed production use. The repository is active, the architecture is explicit, official packages and images exist, and the project has more operational surface than many young agent tools. At the same time, component versions move independently and the project roadmap says a stable v1 API is not currently planned until lifecycle semantics, runtime behavior and SDK compatibility mature enough.

The project publishes a detailed release verification process for source archives, images and language packages. Use it, pin production images by digest and verify the artifact you deploy. Signed provenance improves supply-chain evidence. It does not prove the deployed configuration is safe.

OpenSandbox or a managed sandbox service?

Apache 2.0 means no OpenSandbox licence fee. It does not mean zero cost. Compare engineer time, cluster headroom, secure-runtime overhead, registry and logging cost, patching, on-call work and compliance evidence against managed usage fees. For a common unit across both options, calculate cost per accepted AI-agent action, not cost per sandbox minute alone.

A 30-day OpenSandbox pilot plan

1. Days 1 to 3, define the workload and threat model. Pick one reversible use case, list data, tools, destinations, credentials and unacceptable outcomes.
2. Days 4 to 7, build the local integration. Use the Docker quick start to validate SDK, command, file, browser or desktop needs. Do not call this the production architecture.
3. Days 8 to 12, choose the runtime boundary. Test the real workload on gVisor or Kata and record incompatible syscalls, startup behaviour, resource use and operational prerequisites.
4. Days 13 to 17, lock network and credentials. Start from default-deny egress, add the smallest host and path rules, enable Credential Vault and run exfiltration tests.
5. Days 18 to 22, add external evidence. Capture immutable lifecycle, command, file, network, identity, policy and cost events outside the sandbox.
6. Days 23 to 26, test failure and abuse. Exercise timeouts, infinite processes, disk pressure, package failures, direct IPs, tenant crossover, expired keys and emergency termination.
7. Days 27 to 30, compare the decision. Measure accepted task completion, p95 latency, review minutes, infrastructure cost, operator time and unresolved security findings against a managed baseline.

Scale only if the self-hosting advantage survives that complete comparison. Wavect's AI product engineering team can design the agent boundary, integrate the workload and build the validation harness. Our Twinsoft AI case study shows the production discipline around a real AI product. If you need a scoped decision before implementation, book an AI architecture review.

Primary sources and research boundary

This review uses public project material checked on 16 August 2026. We did not benchmark cold starts, run an independent escape test or validate a commercial support agreement. Version-specific behaviour should be rechecked before procurement.

1. OpenSandbox repository; license, SDKs, integrations, examples and current project scope.
2. OpenSandbox architecture; client, protocol, control-plane, runtime, data-plane and network boundaries.
3. Secure Container Runtime guide; operator configuration for gVisor, Kata and Firecracker.
4. Credential Vault guide; secret injection, matching rules, network prerequisites and service-mesh limitation.
5. Multi-Tenancy guide; Kubernetes namespaces, tenant API keys and Docker limitation.
6. OpenSandbox roadmap; current focus and stable API position.
7. Release Verification guide; signatures, attestations, workflow identities and digest verification.