Google Built an Agent Runtime on Kubernetes. Here's How to Build a Cloud-Agnostic One with Identity Included

Google spent the last year quietly admitting what we already knew: Kubernetes was never designed to run AI agents. As Janakiram MSV writes in The New Stack, Google's GKE Agent Sandbox and the new Agent Substrate project amount to an indirect admission "that the platform that won the container decade is not the right control plane for AI agents."

The analysis is worth reading in full, but the short version is this: an agent doesn't behave like a service. It's a long-running, stateful session that sits idle most of its life, wakes up to execute a burst of model-generated code, and goes back to sleep. Kubernetes assumes placement decisions are rare and durable; agents generate a constant stream of fine-grained scheduling events. So Google built a new runtime layer on top of the cluster — Agent Sandbox for isolation, Agent Substrate for scheduling — and routed around the Kubernetes API server entirely.

Here's the good news for everyone not running on GKE: almost every piece of this stack is open source and runs on any conformant Kubernetes cluster. You can assemble Google's agent runtime on EKS, AKS, bare metal, or your own datacenter.

But there's a layer the stack doesn't cover, and it's the one that determines whether your agents can safely touch anything that matters.

The stack, layer by layer

The runtime The New Stack describes breaks down into three open layers:

Isolation: Agent Sandbox. A Kubernetes SIGs project, not a GKE exclusive. It provides a hardened execution environment for untrusted, model-generated code — "a jail rather than a container," in the article's words. gVisor by default, Kata Containers if you want full VM-level kernel isolation, default-deny networking, warm pools, and pod snapshotting for suspend/resume. Both gVisor and Kata are open source and cloud-agnostic.

Scheduling: Agent Substrate. An open source control plane that sits beside Kubernetes rather than inside it. It multiplexes a large registry of stateful agent actors onto a small pool of pre-warmed worker pods, snapshotting idle sessions to storage — virtual memory overcommit applied to compute, with claimed 30x+ oversubscription. Two CRDs (WorkerPool and ActorTemplate), framework-agnostic: ADK, LangChain, Claude Code, or any OCI container.

Platform: kagent. A CNCF sandbox project that packages this into a Kubernetes-native agent platform and has already wired in Agent Substrate as a selectable runtime.

Swap GKE for any Kubernetes distribution and the architecture holds. Nothing in these layers depends on Google's cloud.

The layer the stack leaves open

Buried in the article's list of requirements is one line that deserves more attention than it gets: "Each session needs a stable identity."

The stack above answers where agents run and how they're contained. Its security story is entirely isolation-centric — kernel boundaries, network lockdown, the assumption that "any agent might run something it should not." That's necessary, and it's the right default.

But isolation only governs what an agent can do inside its jail. The moment an agent becomes useful — calling your internal APIs, reading a ticket in Linear, opening a pull request, querying a database through an MCP server — it has to leave the sandbox and act on real systems. At that boundary, three questions the runtime doesn't answer become the whole ballgame:

• Who is this agent acting for? An agent with standing credentials of its own is a service account with a language model attached — and an unbounded blast radius.

• What exactly is it allowed to do? Workload identity gets a pod a SPIFFE-style identity, but it can't express "this agent may call read_issues but never delete_project, and only on behalf of someone in the engineering group."

• What did it actually do? When a model writes the code, you need a per-action record, not a per-session one.

A recent CNCF post on agent sandboxing puts it plainly: sandboxing your agent is not enough — security, identity, and policy controls remain essential. The runtime stack ships the sandbox, but identity-aware access is the missing layer.

Closing the gap with Pomerium

This is exactly the layer Pomerium was built for, and like the rest of the stack, it's open source, self-hosted, and runs anywhere: Kubernetes (via the Ingress Controller), ECS, systemd, on-prem. Your traffic never leaves your environment, and nothing ties you to a cloud provider.

Pomerium's MCP capabilities extend its zero trust gateway to agentic traffic. In a cloud-agnostic agent stack, it slots in as the access layer between your sandboxed agents and everything they touch:

Every agent action ties back to a verified human identity. Rather than minting free-floating agent credentials, Pomerium uses a delegation model. A user authenticates through your existing IdP; Pomerium issues an external token the agent carries, while upstream credentials (GitHub, Google, Notion, Linear) are acquired, cached, and refreshed by Pomerium and never exposed to the agent or client. For fully autonomous workloads, service accounts represent a specific user with the same policies applied. Either way, the agent acts on behalf of someone — never as an unaccountable identity of its own.

Per-tool-call authorization. Pomerium Policy Language includes an mcp_tool criterion, so policy can compose identity and action: allow users in engineering to call tools on this MCP server, but deny any tool starting with admin_, evaluated on every request, default-deny. This is the authorization granularity that workload identity and network policy structurally can't reach.

A black-box recorder for agents. Authorization logs capture the MCP method, tool name, tool parameters, and the reason each decision was allowed or denied — per action, tied to the acting user. When something goes wrong at 2 a.m., you know which agent did what, for whom, and why the gateway let it happen.

The cloud-agnostic blueprint

Put together, the stack looks like this:

Kubernetes provisions the nodes. Agent Sandbox contains the untrusted code. Substrate decides which agent runs where. And Pomerium governs every request an agent makes to the systems that matter — authenticated, authorized per tool call, and audited per action.

The New Stack piece closes on an open question: does the agent control plane consolidate around a single open project, or does every hyperscaler ship its own and reintroduce the fragmentation agents were meant to escape? The scheduling layer may take years to settle. But the identity layer doesn't have to wait — the primitives are open, deployable on any infrastructure, and available today.

Authenticate every agent. Authorize every action. On any cloud.

Want to see it in action? Start with securing your first MCP server or explore agentic access management.