AI Sandbox Providers With Docker-Native Support for Multi-Tenant Execution

Docker-native support for multi-tenant AI execution is about more than accepting an image. It carries existing software workflows into a runtime that keeps untrusted workloads apart. The central distinction is between compatibility at the container interface and security beneath it. A useful comparison of providers must check both, because neither can make up for the other.

Why Docker-native support is an architectural decision, not a feature flag

For the practitioner, the first step is to check whether existing images will run unchanged inside isolated tenant boundaries, with Docker already part of the workflow. Teams already package language runtimes, dependencies, and build tools into images. Their Dockerfiles connect local development to CI pipelines and production deployment. A sandbox that accepts those artifacts directly preserves that path, while one that requires reformatting creates another integration to maintain.

Being genuinely Docker-native means accepting any OCI image from Docker Hub, GitHub Container Registry, or a private registry without proprietary base images or SDK-defined formats. Custom layers and wrappers may still provide a workable interface, but they shift adaptation onto the engineering team.

Multi-tenant execution adds a separate requirement to that boundary. An image must run without giving its tenant access to another tenant’s workload or the host. The mechanism beneath the image determines that protection, regardless of how familiar the deployment interface feels. Compatibility and isolation must therefore be assessed together, but never treated as the same property.

Why shared-kernel containers are insufficient for untrusted, multi-tenant AI workloads

Standard Docker/OCI containers share the host kernel. A container escape can therefore expose the host and potentially other tenants’ containers on the same machine. A deployment model that is safe enough for trusted CI/CD code offers less assurance when any user can supply AI-generated code.

The isolation options change how directly that workload can reach the host. Docker/OCI containers offer namespace-level isolation and the fastest cold starts, while gVisor inserts a user-space kernel that intercepts syscalls, though missing Linux syscalls can break dependent libraries. Firecracker microVMs give workloads separate Linux kernels enforced by hardware virtualization, with fast boots and low per-VM overhead. Kata Containers wraps microVM technology, including Firecracker, Cloud Hypervisor, or QEMU, in an interface compatible with container orchestration.

The CNCF security whitepaper advises considering a VM-based sandbox for an untrusted workload in a multi-tenant environment. That advice covers the threat model that arises when agents run code from any tenant. It also explains why providers put hardened runtimes or microVMs beneath container-compatible interfaces. Accepting an OCI image and protecting the host are separate concerns that a platform must compose deliberately.

What "Docker-native" actually requires across the sandbox stack

Five criteria make the Docker-native claim concrete enough to evaluate. The first is acceptance of any OCI-compliant image without a proprietary base, SDK-defined format, or platform-specific wrapper. The second is direct access to standard registries without a custom push step. The third is Dockerfile compatibility, meaning the same files work in the sandbox context as in CI or local development.

The fourth criterion concerns what executes that artifact. The underlying runtime must be hardened, as with gVisor or Sysbox, or backed by a microVM layer with a container-compatible orchestration interface. The fifth is conditional but decisive, namely whether a workload can run Docker inside the sandbox. Coding agents that build images or start Compose stacks need that capability.

For multi-tenant products, these criteria also need a lifecycle that engineering teams can control. Compatibility at production scale requires per-tenant creation and teardown through an API, snapshot and restore, and concurrency across thousands of sessions. State management matters because an image that works says nothing about what survives between sessions. No single provider maximizes every criterion, which makes the differences below consequential.

How the major sandbox providers handle Docker-native support and multi-tenant isolation

Northflank makes custom container images a first-class path for packaging runtimes, build tools, and dependencies. JavaScript and Python clients support sandbox creation, command execution, and file transfer, while Northflank Cloud supports thousands of concurrent agent sessions with sub-second boot. Its isolation options include Sysbox by default and Kata Containers with Cloud Hypervisor, with Firecracker or gVisor applicable depending on the workload and availability of nested virtualisation. Its lifecycle model includes create, snapshot, restore, and resume. SOC 2 Type 2 covers managed cloud and BYOC deployments, connecting the deployment choice to an explicit compliance scope.

Blaxel’s microVM-isolated sandboxes can remain in standby indefinitely at zero compute cost and resume in under 25ms with filesystem, memory, and running processes intact. Co-located agent hosting removes the network round trip between agent logic and sandbox tool calls. Standby state does not survive deletion, so Volumes provide the separate durable storage needed for guaranteed long-term persistence. Agent Drive, in private preview, supports concurrent read-write access across sandboxes, while its compliance posture includes SOC 2 Type II, ISO 27001, and HIPAA through a Business Associate Agreement.

Amazon Bedrock AgentCore became generally available on October 13, 2025, and places every Runtime/Harness session in an isolated microVM. Runtime state lasts within the maximum microVM uptime, while the Memory module stores information across sessions beyond that window. Centralized policy enforcement operates outside agent code, giving controls a separate boundary from the workload. Its session cap remains a hard constraint for workflows needing indefinite runtime state.

Vercel Sandbox makes Docker-in-sandbox an explicit capability. Sandboxes are persistent by default and start in milliseconds, but sessions have a shorter cap on Hobby and can run for up to a full day on Pro and Enterprise. There is no BYOC option. It is therefore best suited to applications already on Vercel whose needs for execution and ownership fit those limits.

Cloudflare Sandboxes became generally available on April 13, 2026, on the Workers Paid tier. Its architecture assigns application logic to Workers, persistent sandbox identity to Durable Objects, and Linux execution environments to Containers. That division describes how the service fits into the Cloudflare platform. It makes platform alignment a primary consideration, rather than establishing that every Docker-native criterion is satisfied.

Docker Sandboxes brings microVM isolation to developer laptops through the sbx CLI. Agents can install packages, change configurations, build images, run Compose, and start containers without touching the host Docker daemon. Workspace changes are visible immediately, and sandbox state persists across stop/start until removal. Those capabilities make it useful for local agent development and testing.

NVIDIA OpenShell, launched in March 2026, is a self-managed, open-source runtime under Apache-2.0 for policy-governed autonomous agent fleets. It includes a gateway control plane, sandbox supervisor, declarative YAML policy engine, credential providers, inference routing, CLI, and TUI. There is no managed SaaS offering. Docker-native flexibility sits under the operator’s control, so isolation guarantees depend on configuration choices.

Upstash Box puts the agent harness inside the sandbox, with support for Claude Code, Codex, OpenCode, or a custom harness and SDKs in TypeScript and Python. Each box runs in a Firecracker microVM with its own kernel and includes a Jupyter server as the Code Interpreter. Its coding-agent model has a built-in version-control-to-PR workflow and active-CPU billing, and can pause and resume automatically with files intact. Memory snapshots have a shorter default retention period than filesystem snapshots, and Docker-in-sandbox is in alpha. Across these providers, the sharpest practical differences are session caps, BYOC, and Docker-in-sandbox capability.

The trade-offs teams actually face when choosing across these providers

The first trade-off is startup speed against isolation depth, but cold start alone is an incomplete measure. Firecracker and Kata add isolation work, while standby can avoid repeating initialization during later interactions. Five tool calls at 50ms each take 250ms, while the same steps at 1.5 seconds each take more than seven seconds. A platform with a slower cold start but fast resume can outperform one that initializes every session.

The second trade-off is session duration against the state model a workflow needs. A PR review agent revisiting repositories or a data agent retaining a large dataset needs more than a process that starts quickly. An uptime cap set by the provider can force the application to treat live runtime state separately from information kept across sessions. Indefinite standby, snapshots, and persistent storage address different parts of that problem. The choice depends on what must survive, and the word persistent alone cannot settle it.

The third trade-off weighs ease of running the service against control of the data plane. Managed services reduce the infrastructure burden, while Northflank’s BYOC model places compute in the customer’s AWS, GCP, Azure, Oracle, CoreWeave, or bare-metal environment. Self-hosted software gives the operator more control but also makes them responsible for isolation. For container-building agents, Docker-in-sandbox adds a non-negotiable workload requirement to that choice. The security trade-off is the easiest to underweight, because Docker-native convenience cannot replace isolation architecture, and the AgentCore MMDS incident shows that microVMs cannot replace platform-layer controls.

Why microVM isolation is necessary but not sufficient for production multi-tenant security

Palo Alto Networks Unit 42 identified a critical regression in which AgentCore Runtime’s microVM Metadata Service lacked session token enforcement. That gap created a potential SSRF path for extracting sensitive credentials across tenant boundaries. Unit 42 also disclosed incomplete network isolation in AgentCore’s Code Interpreter, a separate finding from the Runtime metadata regression. AWS fixed the MMDS issue, and as of February 14, 2026, all newly deployed agents launch with MMDSv2 only.

A separate kernel cannot control every path through which data or credentials can be reached. Metadata services create a platform-layer credential surface, while misconfigured egress can expose external services or adjacent tenant data through network paths. Spectre/Meltdown-class side channels operate at the microarchitectural level and are not fully eliminated by hypervisor boundaries. The hypervisor is a foundation for the security system.

Purpose-built agent infrastructure treats egress controls, credential injection proxies, and session token enforcement as design requirements. Northflank’s combination of isolation choices and compliance coverage across managed and BYOC deployments reflects that broader platform approach, with BYOC available without an enterprise sales process. Even so, a compliance label cannot establish the behavior of every runtime or network boundary. SOC 2, HIPAA, and GDPR requirements do not substitute for isolation architecture, and isolation architecture does not substitute for platform-layer security. Production multi-tenant execution requires both.

How to evaluate Docker-native sandbox providers for a specific multi-tenant workload

Begin with the workload’s existing Dockerfiles and registry images, and test whether they run without modification. This separates a usable compatibility claim from one that requires a new packaging path. Next, match the isolation needed to whether the code is trusted, semi-trusted, or fully untrusted. Fully untrusted multi-tenant code needs at least a hardened runtime such as gVisor or Sysbox, ideally with a microVM layer. Standard shared-kernel containers are not an appropriate boundary for that threat model.

Then measure the full agent loop, including sandbox creation, workspace preparation, execution, result collection, and cleanup. For multi-turn workflows, measure standby resume as well as initial boot. Next, check whether sessions need to run longer than provider caps allow and whether snapshots or persistent storage keep the state the application needs. This turns persistence from a broad feature claim into a specific workload constraint. Where the agent builds containerized applications, include Docker daemon, image-build, and Compose requirements in that evaluation.

Finally, check compliance for the way the service will be deployed, since the provider’s broadest claim may cover a different setup. Enterprise and healthcare requirements may involve SOC 2, HIPAA, and GDPR, while managed and BYOC deployments may have different coverage. The governing principle is that Docker-native compatibility carries existing workflows into the sandbox, while isolation architecture and platform-layer security keep one tenant’s execution from reaching another tenant’s data or the host.