Saltar al contenido
ES EN

How to evaluate gVisor as a sandbox for AI agents, step by step

Google donates gVisor and two other projects to the CNCF. We propose a guide to evaluate if this sandbox fits your agent infrastructure.

AI for developers

When an AI agent writes and executes code on its own, the uncomfortable question is where that code runs. Google has announced that it is donating three infrastructure projects for agents to the CNCF, and among them is gVisor, the container sandbox that, according to The New Stack, is used by labs like Anthropic and OpenAI. The idea is to repeat the path Google already took when it donated Kubernetes to the foundation.

This guide is not an official installation tutorial; it's a method to evaluate if gVisor fits your use case before committing. We would follow this order, relying on each project's documentation.

Conceptual diagram of an AI agent executing code within a sandbox isolated from the host system
An agent executes code generated by a model; the sandbox limits what that code can touch.

What you need

To follow the guide, you need a test Linux host where you can install a container runtime, a representative workload (what your agents currently run), and a way to measure startup times and errors. It's advisable to first read the Google blog post about the donation and the list of adopters to see who uses it and in what context.

  1. Define what code your agents execute and what they should not be able to do: network, file system, processes.
  2. Review gVisor's documentation and confirm that your Linux version and container runtime are compatible.
  3. Run the same workload in a conventional container and in one with gVisor, and compare startup, performance, and errors.
  4. Review which system calls your workload fails or slows down and note any incompatibilities.
  5. Decide if gVisor is sufficient or if you need additional layers of isolation.

What changes with the CNCF donation

gVisor originated at Google and was open-sourced some time ago. What's new is the governance: the project moves to a neutral foundation, which Google announced on the project's own blog. Along with it travel Agent Substrate and OpenRL, the latter introduced in June for fine-tuning language models on self-hosted infrastructure.

For system builders, the practical value is neutrality: it's harder for a single provider to change the rules. But a donation is no guarantee of performance or maturity, and you'll only verify that by measuring it yourself.

# Template for noting your comparison (replace with your actual measurements)
# workload: <your workload name>
# runtime_base:   startup=<ms>  p95=<ms>  errors=<n>
# runtime_gvisor: startup=<ms>  p95=<ms>  errors=<n>
Tip Don't judge the sandbox with a synthetic test. Use real tasks from your agents: that's where the system calls that most penalize or simply don't work usually appear. And remember that no sandbox replaces limiting ingress permissions and credentials. Teams that publish how they contain their agents, like Anthropic, combine several layers.
Comparison table of startup times and errors between a conventional container and a sandboxed one
Note your own measurements: they are the only ones that matter for your case. Image: Unsplash — chart

Original source: thenewstack.io

Article generated with AI.larebelion

Kernel

· Head of Technology · Spain

«A good sandbox is measured in milliseconds and failed syscalls, not in donation announcements.»

Comentarios