Last week Google said it is donating three projects to the Cloud Native Computing Foundation as sandbox projects: Agent Substrate, gVisor and OpenRL. Agent Substrate is described as an orchestrator for AI agent sessions that sits on top of Kubernetes. gVisor is the sandboxed container runtime Google open-sourced in 2018, and it is the default way Agent Substrate isolates the code an agent runs.
It's easy to read this as a "Google does AI agents" story. My take is a bit different. For anyone running Kubernetes on a European cloud or on their own hardware, the interesting part is that the agent runtime is now moving into neutral, open governance. That changes what I can recommend to customers who will not run their workloads on a US hyperscaler.
Why this matters on a European cluster
Until now, a lot of the agent-sandboxing story came packaged as features of managed hyperscaler services. If you run on an OpenStack-based Swedish cloud, or in your own data centre, the question was always: what do we use instead?
gVisor answers part of that, and the reason is technical. It runs a user-space kernel that intercepts the container's system calls. Its default platform (systrap) does not need hardware virtualisation. That matters because most Kubernetes worker nodes on public OpenStack clouds are themselves virtual machines, and nested virtualisation is often not available. MicroVM approaches like Kata Containers or Cloud Hypervisor usually need it. gVisor does not. You install the runsc runtime on the nodes, add a RuntimeClass, and pods that ask for it are sandboxed.
So the honest version is: you could already do this. What the CNCF move adds is a home for the project that isn't a single vendor's roadmap, and that is what makes it easier to defend in an architecture review.
What a sandbox does not solve
This is where I want to be careful, because "sandboxed" is quickly becoming a word that ends discussions.
A sandbox limits what the code can do to the node. It does not limit what the agent can do to your systems. If the pod has an API token, a database connection string or open egress to the internet, gVisor will faithfully protect the kernel while the agent uses those credentials exactly as intended, or not as intended. The things that actually bound an agent's blast radius are still the boring ones:
- Egress. A default-deny NetworkPolicy, and an explicit list of what the sandbox may talk to.
- Identity. Short-lived, narrowly scoped credentials per session, never a shared service account with broad rights.
- Audit. A record of what the agent did, not just that a pod ran.
A sandbox is the floor under those controls, not a replacement for them.
Snapshots are data, too
One detail in Agent Substrate's design deserves more attention than it gets. Idle agent sessions are suspended and snapshotted to storage, so they can be resumed quickly. A session snapshot can contain the agent's filesystem, environment and memory. In other words: whatever the agent was working on, possibly including personal data, and possibly including secrets that were in its environment.
If you care about where your data lives, the snapshot store is in scope. Which region, which provider, encrypted with whose keys, how long it is kept, and who can read it. In Swedish healthcare that also means asking how Patientdatalagen and GDPR apply to data at rest in a place nobody drew on the architecture diagram.
Trade-offs worth naming
gVisor is not free. Workloads that make many system calls or do heavy file and network I/O can run noticeably slower, and some software assumes kernel features gVisor does not implement. Test your actual agent workloads before you make it the default.
CNCF sandbox status is also an early stage. gVisor itself is mature and has been used in production for years. Agent Substrate is newer, and its headline numbers, such as fast resume times and high oversubscription, are the vendor's own claims so far. I would treat it as something to evaluate, not something to standardise on this quarter.
What I would do now
If I were planning agent workloads on a European Kubernetes platform today, I would:
- Add a gVisor
RuntimeClassto a non-production cluster and run real agent workloads in it, measuring the overhead. - Put default-deny egress and per-session credentials in place before anything else. That is where most of the risk is.
- Decide where session state and snapshots are allowed to live, and write it down, before a framework decides for you.
- Watch the CNCF projects mature, and keep the choice reversible.
The best thing about this news is not that Google built an agent runtime. It is that the parts that matter are becoming portable, open infrastructure that can run on a cluster in Sweden. Whether running agents there is safe still depends on the parts no runtime ships with.
Sources
- Google Open Source Blog: Sandboxing untrusted AI agents at scale (5 November 2026)
- Let's Data Science: Google Donates Agent Substrate and gVisor to the CNCF
- Agent Substrate on GitHub: agent-substrate/substrate
- gVisor project: gvisor.dev