Running AI-generated code: Ray and gVisor strengthen isolation

Google Cloud and Anyscale offer an experimental library that integrates gVisor environments with Ray clusters. The objective is specific: to allow agents, post-training pipelines or code generation systems to perform dynamic operations without giving this code direct access to the host receiving it.

Why code execution changes the risk level

An assistant who summarizes a document and an agent who launches a command do not present the same attack surface. As soon as a model can produce and run Python, manipulate files, call a system tool or install a dependency, the result must be treated as unreliable code. A malicious instruction hidden in a page, a generation error or a compromised dependency may lead the agent to perform an action that was not intended.

The classic container brings a first level of organization and isolation, but usually shares the host core. Exhibiting the Docker socket to a dynamic process is particularly dangerous, as it often amounts to giving it a very wide power on the machine. The project presented avoids this dependency and adds a boundary between the charge and the host kernel.

Ray turns sandbox into a distributed resource

Ray is used to coordinate distributed calculations: inference motors, workers Rollout, reinforcement drive and multimodal pipelines. Rather than adding a completely separate isolation system, the new library represents each sandbox as a Ray actor. The planner selects the node, stores the processor and memory, then the actor manages the environment life cycle.

From Ray 2.58, framework authors and research teams can use the same programming models as for their other loads. The announced API allows you to create an environment from an OIC image, set CPU and memory limits, set a working directory, control the network, execute commands, transfer files, read the status and then finish or delete the sandbox.

This choice is interesting for agent loads: a sandbox becomes a resource that can be placed, restarted, dimensioned and destroyed like other cluster components. It also becomes possible to build local pools to avoid recreating a complete environment for each short operation.

The role of gVisor in this isolation

gVisor is an open source application kernel developed by Google. It implements in user space a significant part of the Linux system call interface. The calls of an application therefore do not reach the host kernel directly in the same way as in an ordinary container. This additional layer reduces the exposure of the underlying system.

Runtime remains compatible with current OCI images. It does not require to open a Docker demon or its socket inside the environment. Google also highlights a lower than second start and a low memory overload per sandbox, two necessary features when environments need to be created on demand and in large numbers.

This layer should not be interpreted as an absolute guarantee. A sandbox is part of an in-depth defence strategy: network limitation, minimum permissions, ephemeral secrets, logging, quotas and systematic destruction of the environment remain necessary.

Use cases that go beyond the simple Python interpreter

The need arises in post-training, when models learn to solve tasks through testing performed in controlled environments. It also covers development assistants, data analysis tools, automated browsers and agents capable of interacting with a command line.

A company can also isolate processing provided by users: file conversion, custom calculations, package validation or run a test. The same architecture can thus be used to protect a SaaS platform that accepts executable content, regardless of the use of a large model.

The checks to be carried out before placing in production

• By default, prohibit network outputs and open only areas that are essential to the task.
• Inject temporary identifiers, limited to a resource and a short duration.
• Limit processor, memory, storage, running time and number of processes.
• Mount file systems read alone whenever possible.
• Keep traces of creation, command, transfer and destruction without recording secrets.
• Test scenarios of escape, saturation, malicious download and defiltration.

What the announcement does not solve alone

The isolation of execution does not decide whether an action is legitimate. It does not replace trade authorisation or human confirmation for a sensitive operation. A properly locked agent could still delete a data via an API if the token provided gives it the right. Security must follow the whole chain: intent, policy, identity, tool, execution environment and audit.

The library is presented as an experimental. Google and Anyscale plan to extend the support later to other runtimes, including Agent Substrate or Kata Containers. The teams concerned must therefore assess it as an evolving brick, with environmental compatibility and load tests.

A healthier architecture for operating agents

Major progress is due less to a new syntax than to the explicit separation of responsibilities. Ray orchestrates the distributed work; gVisor restricts the environment that executes it; Kubernetes and GKE provide policy, infrastructure and cluster supervision. This composition makes it more realistic to perform thousands of short tasks without confusing prototyping speed with unlimited access to the system.

For a business project, therefore, the right question is not "can one have code executed by the AI?", but "what code, in what environment, with what identity, what limits and what proof of what has been done?". Sandbox provides an essential part of this response.

Read the technical announcement Google Cloud and Anyscale · View SDX architecture and security approach →