BENGALURU, India — August 26, 2026, 6:02 PM IST — Ray has added an experimental sandboxing layer that lets AI training systems and coding-agent evaluators run model-generated code inside gVisor-isolated environments without introducing a separate scheduler or execution service.
The capability, available in Ray 2.58 through the ray.experimental.sandbox package, represents each sandbox as a Ray actor. Ray schedules CPU and memory, places the environment on a worker node and manages its lifecycle, while Google’s gVisor application kernel provides the isolation boundary between untrusted code and the host Linux kernel.
That integration matters because code execution is becoming a routine part of reinforcement-learning rollouts, software-agent benchmarks and tool-using AI systems. Platform teams have usually had to choose between running generated code too close to a worker process or operating a separate sandbox fleet with its own control plane. Ray’s approach brings placement, resource accounting, recovery and autoscaling into the same distributed runtime already coordinating trainers, inference engines and rollout workers.
What Ray 2.58 adds
Google Cloud and Anyscale announced the work on Tuesday. The initial release can create a sandbox from an OCI-compatible image, reserve CPU and memory, set a working directory and environment variables, control networking, execute commands, transfer files, inspect state and terminate the environment. The public documentation lists Linux on x86-64 or Arm64, Ray 2.58 or later and the gVisor runsc binary on every eligible node as requirements.
The sandbox actor is a proxy: an execution request is a normal Ray actor call, so the target environment can be placed anywhere in the cluster. By default, the root filesystem is read-only and the configured working directory is writable scratch space. Ray also exposes a lower-level runtime for teams that need to transform the OCI specification before gVisor starts the workload.
Anyscale says it and Google scaled the system to 100,000 gVisor sandboxes in 20 seconds on Google Kubernetes Engine across thousands of nodes. That is a vendor-run engineering result, not an independently reproduced benchmark, and the companies did not publish a complete cost, workload or cluster configuration in the announcement. It nevertheless identifies the intended operating model: large populations of short-lived environments that are created and destroyed continuously during agentic reinforcement learning.
Why gVisor changes the isolation boundary
Ordinary containers share the host kernel. gVisor instead implements much of the Linux system-call interface in a user-space application kernel and intercepts calls before they reach the host. This reduces the host-kernel attack surface and avoids giving the sandbox direct access to a Docker daemon or host Docker socket.
The design sits between conventional containers and heavier virtual-machine isolation. Ray’s documentation says gVisor sandboxes start in tens of milliseconds, use little memory and consume near-zero CPU while idle. Those are project claims rather than guarantees for every workload, but they explain why the runtime is being used for high-frequency agent tool calls and training rollouts.
The model is defense in depth, not a security proof. The Anyscale announcement explicitly says the overall security properties still depend on configuration and that guidance for workloads in which a model may actively attempt to escape the sandbox remains future work. Teams should not treat the presence of gVisor as permission to expose production credentials, sensitive mounts or unrestricted network paths.
Network policy becomes a first-class decision
Ray’s sandbox API currently offers four network modes. The default provides loopback only. A public mode enables internet egress, a host mode shares the node network namespace, and a sandbox mode uses gVisor’s isolated network stack. The choices are operationally significant: an evaluator that only needs to run tests should generally have no network, while an agent permitted to fetch packages or call an API needs narrowly scoped egress and separate credentials.
The release also lets operators remove Linux capabilities and set process limits through OCI-spec transforms. Those controls can reduce fork-bomb risk and block operations such as raw-socket creation, but they must be combined with resource quotas, execution timeouts, image provenance, secret isolation and audit logs. A sandbox is one layer in the control path, not the whole path.
What developers and platform teams should do now
For teams already using Ray, the immediate advantage is architectural simplification. A coding-agent benchmark, an MCP execution tool or an RL rollout worker can request an isolated environment through familiar actor APIs while Ray continues to handle scheduling and autoscaling. Anyscale has also connected the feature to Harbor, an agent-evaluation framework that supports workloads such as SWE-bench and Terminal-Bench.
But production adoption should begin with a constrained evaluation. Pin Ray and gVisor versions, use immutable task images, keep the default no-network policy wherever possible, remove unnecessary capabilities, enforce CPU, memory, process and time limits, and destroy the environment after each job. Capture the image digest, agent identity, policy, command, exit status and artifact hashes so an execution can be reconstructed during an incident review.
Teams should also separate the sandbox worker pool from Ray’s control-plane services and from production data stores. Even when gVisor contains a process, an overly broad network route or credential can still turn a successful tool call into a data-exposure event. The more autonomous the agent, the less ambient authority its execution environment should inherit.
Important gaps remain
Ray labels the library alpha and warns that the API may change or disappear before becoming stable. The project’s open tracking issue still lists unresolved work around container-image management, dependency caching, suspension and resume, test setup and cgroup behavior. Anyscale says native GPU-backed sandboxes, Docker inside the sandbox, filesystem snapshots, cross-sandbox ports and a standalone REST service are planned rather than complete.
Compatibility also needs measurement against the actual workload. A gVisor project report from Tencent said targeted fixes improved the runsc pass rate by about 1.7 percentage points across 74,379 side-by-side comparisons with runc. That experience supports gVisor’s production potential, but it also shows why teams should maintain regression suites for system calls, filesystems and dependencies used by their agents.
The larger shift: execution is becoming AI infrastructure
Model choice still attracts most attention, but the Ray release reflects a quieter infrastructure shift. Agent quality increasingly depends on the environment around the model: schedulers, tools, state, network policy, isolation, evaluation and recovery. Bringing sandboxes into Ray turns isolated execution into a schedulable resource rather than an external service glued onto the training stack.
For GravityDevOps readers building agent platforms, the practical lesson is to design the execution boundary before granting a model tools. That boundary should connect with established LLMOps controls, retrieval and data-access policy described in RAG architectures, and the same testing discipline used in CI/CD systems. Ray 2.58 makes that work easier to integrate, but its alpha status makes careful validation—not automatic rollout—the appropriate next step.
Sources
Confirmed details were drawn from the Google Cloud launch announcement, Anyscale’s technical announcement, the Ray 2.58 sandbox documentation, the Ray project’s open implementation tracker and the gVisor project’s Tencent compatibility report.
