Google AX Isolates AI Agents in Kubernetes

AX separates the agent from the cluster

What stands out to me about AX is not Kubernetes itself, but the attempt to turn execution of potentially untrusted agent code into a separate infrastructure concern. In Google’s official repository, the project is described as a declarative runtime that isolates tasks, attaches workspaces, restricts outbound networking, and scales agent workloads on a cluster.

As of September 2026, AX, short for Agent Executor, has been released under the Apache 2.0 license. Its main primitives clearly express the execution model: Task runs an agent task, Workspace supplies file context or a repository, Gateway defines external access, and Model configures the model provider and credentials.

This is more than a Kubernetes Job running a container. AX is designed for long-lived, stateful agent processes that need a managed working context and a clear network boundary. Those are exactly the details that usually become difficult to control once an agent can write files, execute code, and call external systems.

AX is not self-contained, however. Its repository documentation lists a Kubernetes cluster, the ko image builder, a container registry accessible to the cluster, and the Agent Substrate Control API among the requirements. Much of the actual execution resides in Agent Substrate, while AX provides declarative management and orchestration.

Google describes AX as a high-performance orchestrator designed for billions of autonomous agent workloads per cluster. That is an ambitious claim, but the public materials do not provide an official reproducible benchmark suite. For now, it is an architectural goal rather than a capacity figure I would rely on.

Isolation becomes part of the agent model

AX changes something useful: agent security is defined not by a collection of conventions inside an application, but by dedicated infrastructure objects. The network, workspace, model, and executable task receive explicit boundaries that can be described and controlled through a Kubernetes-like process.

Platforms running different agents with untrusted code or different access rights at the same time stand to benefit most from this approach. For a small deployment, the entry cost may be substantial: beyond Kubernetes, teams must operate a registry, image builds, and a separate Agent Substrate layer.

My first checks would focus not on the claimed scale but on the strength of the boundaries: bypassing the network Gateway, handling model credentials, recovery of long-running tasks, and behavior when the control layer fails. AX has a sound idea behind it, but its value will depend less on the number of agents launched than on how predictably one broken agent remains a problem only inside its own sandbox.

We previously covered how to deploy a self-hosted autonomous AI agent with secure DevOps controls and continuous operation. Google’s AX sandbox extends that deployment discussion by adding Kubernetes isolation for agent workloads.