Google Cloud and Anyscale are introducing an experimental Ray library that brings gVisor-based sandboxing directly into distributed Ray clusters. The motivating context is reinforcement learning: Ray is becoming the common runtime for post-training workloads, and on GKE it is used for everything from multimodal data pipelines to frontier RL. As agentic and reasoning models evolve, the critical bottleneck is securely orchestrating isolated sandboxes at scale for dynamic rollouts, generated code, and multi-turn tool interactions.

Ray Sandboxing is designed to fit the existing Ray programming model rather than introduce a separate abstraction for isolated execution. A sandbox is represented as a Ray Actor: Ray’s scheduler decides where it runs and reserves CPU and memory, the actor manages its lifecycle, and gVisor provides the isolated execution environment on the node. Starting in Ray 2.58, framework authors and researchers can manage sandboxed environments with the same Ray APIs they already use. For example, creating a gVisor sandbox from an OCI-compatible image returns a Ray Actor handle, and calls to exec are normal Ray Actor calls, so the sandbox can be placed anywhere in the cluster. The actor is a proxy that forwards operations to gVisor.

The sandbox API covers the core lifecycle needed by agentic workloads: creating environments from OCI container images, setting CPU and memory limits, configuring environment variables and networking, executing commands, transferring files, inspecting sandbox state, and terminating environments. For lower-level use, SandboxRuntime gives direct access to local gVisor sandboxes and lets users modify the OCI specification before it is passed to gVisor; the article shows this could be used to build a pool of local sandboxes inside an actor.

The choice of gVisor is deliberate. Generated code is treated as untrusted, and gVisor is Google’s open-source application kernel that implements a large share of the Linux system-call interface in userspace, creating an extra isolation boundary between workloads and the host kernel. It is OCI-compatible, works with standard container images, and avoids exposing a Docker daemon or host Docker socket. OCI sandboxes are lightweight enough to be created dynamically, provide stronger isolation than running generated code in ordinary containers, and have sub-second startup and low per-sandbox memory overhead, which makes them useful as fine-grained distributed resources. Future Ray versions plan to add other sandboxing runtimes such as Agent Substrate or Kata Containers. Readers who want to try Ray Sandboxing on GKE are pointed to the Ray sandboxing User Guide and the GitHub issue.