Google Cloud Brings gVisor Sandboxes to Distributed Ray Clusters

As reinforcement learning and AI post-training workloads become increasingly complex, distributed compute frameworks need to handle more than model training and inference.

They also need to safely execute dynamic workloads such as model-generated code, rollouts and multi-turn tool interactions.

Google Cloud and Anyscale are addressing that challenge with an experimental sandboxing library for Ray that brings gVisor-based isolated execution directly into distributed Ray clusters.

The capability is designed to make sandboxes work as native Ray resources. Instead of introducing a separate execution model, the sandbox can be scheduled, allocated resources, created, destroyed and recovered using Ray's existing programming patterns.

The approach uses gVisor, Google's open-source application kernel, as the initial sandbox runtime. Google Cloud says the combination is intended to provide an additional isolation boundary for untrusted, model-generated code while retaining the lightweight characteristics needed for dynamic AI workloads.

The announcement is particularly relevant to reinforcement learning, agentic AI and post-training systems where AI-generated code and tool interactions may need to run repeatedly across distributed infrastructure.

Why Sandboxing Matters for Distributed AI

Ray has become a common runtime for orchestrating complex post-training workloads.

Google Cloud says frameworks including veRL, NeMo-RL, SLIME, MILES and SkyRL use Ray to coordinate components such as distributed trainers, inference engines and rollout workers.

As agentic and reasoning models evolve, however, the execution environment itself becomes an important part of the architecture.

AI workloads can involve dynamic rollouts, generated code and interactions with tools. Running model-generated code means treating that code as untrusted.

That creates a requirement for an execution environment that can be created dynamically while maintaining an isolation boundary from the host system.

Google Cloud's new Ray sandboxing approach is designed around that requirement.

Rather than treating sandboxing as an external system, the project makes the sandbox part of Ray's resource model.

Sandboxes Become Ray Primitives

A central design decision behind the project is to represent each high-level sandbox through a Ray Actor.

Google Cloud explains that a sandbox shares several characteristics with other resources managed by Ray.

It needs to:

• Be placed on a machine

• Receive CPU and memory resources

• Be created and destroyed

• Recover from failures

• Scale alongside surrounding workloads

Under the new approach, the Ray scheduler determines which node should run the sandbox and reserves the associated CPU and memory resources.

The sandbox Actor manages the sandbox lifecycle, while gVisor provides the isolated execution environment on the selected node.

Starting with Ray 2.58, framework authors and researchers can manage sandboxed environments using the same Ray APIs and patterns used for other workloads.

This is important because it avoids introducing an entirely separate abstraction for sandboxed execution.

Creating a gVisor Sandbox With Ray

The high-level sandbox API is designed to make sandbox creation look similar to other Ray operations.

The Google Cloud example starts Ray, creates a sandbox using an OCI-compatible container image, assigns CPU and memory resources, and then executes a command inside the sandbox.

Here is the source example:

import ray

from ray.experimental import sandbox

ray.init()

# Create a gVisor sandbox environment and return an actor handle for a proxy actor

sb = sandbox.create(

cpu=1.0,

memory="512Mi",

image="python:3.12-slim"

)

# Execute code inside the sandbox

result = ray.get(

sb.exec.remote("python -c 'import sys; print(sys.version)'")

)

print(result.stdout)

The example creates a gVisor sandbox using the python:3.12-slim OCI-compatible image.

The sandbox.create() call specifies 1 CPU and 512 MiB of memory for the environment.

It then returns an Actor handle for a proxy Actor.

The command is executed through:

sb.exec.remote(...)

Google Cloud explains that these calls are normal Ray Actor calls, meaning the sandbox can reside anywhere in the Ray cluster. The Actor acts as a proxy that forwards operations to gVisor.

This model allows sandboxed execution to fit into distributed Ray workloads without requiring developers to manage the sandbox location manually.

What the Ray Sandbox API Supports

The experimental sandbox API covers the core lifecycle operations required for dynamic AI workloads.

According to Google Cloud, the API supports:

• Creating environments from OCI container images
  

• Setting CPU and memory limits
  

• Configuring environment variables
  

• Configuring working directories
  

• Configuring networking
  

• Executing commands
  

• Reading and writing files
  

• Uploading and downloading files
  

• Inspecting sandbox state
  

• Terminating or deleting environments
  

This lifecycle-oriented approach is significant for agentic workloads because sandboxes may need to be created for individual tasks and then removed when those tasks are complete.

The source does not provide a broader production deployment architecture or specific workload sizing recommendations.

A Lower-Level Approach With SandboxRuntime

Google Cloud also provides a lower-level API through SandboxRuntime.

This interface provides direct access to local gVisor sandboxes and allows users to modify the OCI specification before it is handed to gVisor.

The source demonstrates this approach by building a pool of local sandboxes inside a Ray Actor.

import ray

from ray.experimental.sandbox.runtime import SandboxRuntime

@ray.remote

class SandboxPool:

def init(

self,

size: int = 3,

image: str = "python:3.10-slim"

    ):

self.runtime = SandboxRuntime()

self.sandboxes = [

self.runtime.create(

image=image,

memory="512Mi"

            )

for _ in range(size)

        ]

def run_command(self, index: int, command: str):

return self.runtime.exec(

self.sandboxes[index],

command

        )

def close(self):

for sb_id in self.sandboxes:

self.runtime.delete(sb_id)

# Deploy an actor managing a pool of local sandboxes

pool = SandboxPool.remote(size=3)

result = ray.get(

pool.run_command.remote(

0,

"python3 -c 'print(\"Hello from pool!\")'"

    )

)

print(result.stdout)

ray.get(pool.close.remote())

In this example, the SandboxPool Actor creates three local sandbox environments.

Each sandbox is created with a python:3.10-slim image and 512 MiB of memory.

The Actor then exposes a method for executing a command against a selected sandbox.

The close() method deletes the sandboxes when the pool is no longer required.

This example demonstrates a different usage pattern from the high-level API.

The first example focuses on creating and interacting with an individual sandbox through Ray.

The second shows how developers can use SandboxRuntime to manage multiple local sandboxes within an Actor.

Why Google Cloud Is Using gVisor

The security model becomes particularly important when workloads execute code generated by AI models.

Google Cloud states that running model-generated code means treating the code inside the environment as untrusted.

Ray Sandboxing uses gVisor as its initial sandbox runtime.

gVisor is Google's open-source application kernel. It implements a substantial portion of the Linux system-call interface in userspace, creating an additional isolation boundary between workloads and the host kernel.

The source also highlights several characteristics relevant to the Ray sandboxing design.

gVisor:

• Is OCI-compatible
  

• Works with standard container images
  

• Does not require exposing a Docker daemon to the sandbox
  

• Does not require exposing the host Docker socket to the sandbox
  

• Supports sub-second sandbox startup
  

• Has low per-sandbox memory overhead
  

These properties are relevant to workloads where sandbox environments may need to be created dynamically and used as relatively fine-grained distributed resources.

gVisor Adds Another Isolation Boundary

Traditional containers provide process isolation, but the Ray sandboxing architecture adds gVisor as another layer between the workload and host kernel.

The basic concept can be represented as:

Model-generated workload

↓

Ray sandbox

↓

gVisor

↓

Host kernel

↓

Underlying infrastructure

The key point is that the generated workload does not simply execute directly inside an ordinary container environment.

Instead, gVisor provides the initial sandbox runtime and an additional isolation boundary.

Google Cloud describes this combination as particularly useful for agentic workloads where dynamically created execution environments need to remain lightweight while providing stronger isolation than directly executing generated code in ordinary containers.

Why This Matters for Agentic AI

The announcement is closely connected to the changing architecture of AI systems.

Agentic workloads can involve more than a model generating a response.

They can involve:

• Dynamic code generation
  

• Tool interactions
  

• Multi-turn execution
  

• Rollouts
  

• Distributed workers
  

• Post-training workflows
  

When these operations require execution rather than simply generating text, the execution environment becomes part of the security model.

A sandbox can provide a controlled environment in which that activity takes place.

Google Cloud's approach makes the sandbox part of the distributed Ray infrastructure rather than treating isolated execution as an entirely separate system.

This is particularly relevant to reinforcement learning and post-training workflows where Ray coordinates multiple distributed components.

Ray Sandboxing Fits Into Existing Ray Workflows

One of the notable aspects of the announcement is that Google Cloud and Anyscale are not proposing a separate orchestration system for sandboxed workloads.

Instead, the sandbox is represented through Ray's existing Actor abstraction.

The Ray scheduler handles placement and resource allocation.

The sandbox Actor manages lifecycle operations.

gVisor handles isolated execution.

This creates a relatively straightforward conceptual flow:

Ray workload

→ Ray scheduler

→ Sandbox Actor

→ gVisor

→ Sandboxed execution

The model is designed to allow researchers and framework developers to work with sandboxed environments using familiar Ray patterns.

Sandboxes Can Be Managed Alongside Other Ray Resources

The architectural decision to treat sandboxes as Ray primitives has another implication.

Sandbox environments can be considered alongside other resources that Ray already manages.

A sandbox can require:

CPU

Memory

Placement

Lifecycle management

Failure recovery

Scaling

This aligns sandbox management with the distributed execution model already used by Ray.

The source specifically says the Ray scheduler reserves the corresponding CPU and memory resources when deciding where a sandbox should run.

Where the Experimental Library Fits Today

It is important to distinguish the current announcement from a broad production availability claim.

Google Cloud describes the Ray sandboxing library as experimental.

The announcement introduces the capability in partnership with Anyscale and positions it around distributed Ray clusters and AI workloads.

The source does not provide a detailed production-readiness assessment, enterprise SLA, security certification or benchmark comparison with alternative sandboxing technologies.

Those details were not disclosed in the announcement.

For organizations evaluating the technology, the experimental status is therefore an important part of the current context.

Future Runtime Support

gVisor is the initial sandbox runtime for the project.

Google Cloud says future versions of Ray are planned to extend support to other sandboxing runtimes, including:

• Agent Substrate
  

• Kata Containers
  

The announcement does not provide a release date or detailed roadmap for those additional runtimes.

Additional details were not disclosed in the announcement.

What This Means for AI Infrastructure

The development highlights a broader shift in AI infrastructure.

As AI systems become more capable of generating code and interacting with tools, infrastructure has to account for execution as well as inference.

That creates a different security requirement from simply protecting a model endpoint.

A distributed AI platform may need to coordinate:

• Models

• Rollout workers

• Generated code

• Tools

• Sandbox environments

• Compute resources

• Security boundaries

Ray Sandboxing is designed to bring those sandbox environments into the same orchestration framework.

For infrastructure teams, the broader industry direction suggests that secure execution environments could become increasingly important as agentic workloads move into more complex production and research environments.

This is an industry implication based on the architecture described in the announcement, rather than a specific prediction from Google Cloud.

Why the Ray Actor Model Matters

The use of Ray Actors is more than an implementation detail.

It provides a familiar programming abstraction for developers already working with Ray.

Instead of learning a completely separate sandbox orchestration model, the developer can receive an Actor handle and interact with the sandbox using Ray calls.

In the source's first example:

sb = sandbox.create(...)

returns a proxy Actor handle.

The command is then executed through:

sb.exec.remote(...)

This means the sandbox interaction follows the same remote-call pattern used elsewhere in Ray.

That consistency is central to the project's design.

The Two Examples Show Different Levels of Control

The source's two code examples also demonstrate the intended range of usage.

High-level API

The first example is appropriate for developers who want to create a sandbox and execute commands without managing the underlying runtime directly.

Conceptually:

Create

→ Execute

→ Inspect

→ Terminate

Lower-level API

The SandboxRuntime example provides more direct control over local sandboxes.

Conceptually:

Create runtime

→ Create multiple sandboxes

→ Manage sandbox pool

→ Execute commands

→ Delete environments

This distinction makes the examples useful beyond simply demonstrating syntax.

They show how sandboxing can be integrated at different levels of a distributed Ray application.

Try Ray Sandboxing on GKE

Google Cloud directs developers interested in the capability to the Ray documentation and the Ray sandboxing User Guide.

The announcement specifically points users toward documentation for learning more about Ray Sandboxes and instructions for trying the capabilities on Google Kubernetes Engine (GKE).

The project also invites feedback through a GitHub issue focused on the future of Ray for reinforcement learning.

For developers evaluating the technology, these resources are the appropriate starting points because the library is experimental and the source does not provide a complete standalone deployment tutorial.

Ray Sandboxes documentation

Ray sandboxing User Guide

What Developers Should Take Away

The announcement introduces three important ideas.

1. Sandboxing can become part of distributed AI orchestration

Instead of treating secure execution as a separate infrastructure layer, Ray Sandboxing represents sandboxes as Ray-managed resources.

2. gVisor provides the initial execution boundary

The project uses gVisor to isolate sandboxed workloads from the host kernel while retaining compatibility with OCI container images.

3. AI infrastructure increasingly needs secure execution

As agentic and reasoning systems generate code and interact with tools, infrastructure needs mechanisms for safely executing dynamic workloads.

The Ray sandboxing library is an experimental step toward integrating that capability directly into distributed AI workloads.

The Bigger Picture

AI infrastructure is moving beyond a simple model-serving architecture.

Modern post-training and agentic workloads can involve distributed training, inference, rollout generation, tool interactions and model-generated code.

Each additional capability creates another infrastructure consideration.

Secure execution is one of those considerations.

Google Cloud and Anyscale's Ray sandboxing approach attempts to address it by combining Ray's distributed orchestration model with gVisor's sandbox runtime.

The result is an architecture in which the Ray scheduler handles placement and resources, Actors manage sandbox lifecycles, and gVisor provides the isolated execution environment.

The project remains experimental, but its design points toward an increasingly important area of AI infrastructure: making dynamic AI execution easier to orchestrate without treating security as a completely separate layer.

Key Facts at a Glance

Conclusion

Google Cloud and Anyscale are bringing gVisor-based sandboxing directly into distributed Ray clusters through an experimental Ray sandboxing library.

The goal is to address an increasingly relevant infrastructure problem: how to execute model-generated code, dynamic rollouts and tool interactions while maintaining an isolated execution environment.

The design makes sandboxes Ray primitives represented through Actors. The Ray scheduler handles placement and CPU and memory resources, while the sandbox Actor manages lifecycle operations and gVisor provides the isolated execution environment.

The source also demonstrates two approaches to using the capability. The high-level sandbox.create() API provides a straightforward way to create and execute workloads in a sandbox, while SandboxRuntime provides lower-level access for use cases such as managing pools of local sandboxes.

For AI infrastructure teams, the development highlights a broader trend toward integrating security and isolation directly into distributed AI orchestration.

As reinforcement learning, agentic AI and reasoning workloads become more sophisticated, the ability to execute dynamic workloads safely can become an important part of the infrastructure stack.

The project is still experimental, and Google Cloud has not disclosed broader production-readiness details. But by combining Ray's distributed scheduling model with gVisor-based sandboxing, the project provides a new approach to managing isolated execution within AI workloads.