Google reworks GKE networking to handle a million AI agent sandboxes

Google says its container platform can now spin up 300 fully isolated AI agent sandboxes per second at sub-second latency, after the company reworked how GKE Dataplane V2 assigns network identities to pods. The changes, outlined on November 13, 2026, target a hard constraint that has plagued Kubernetes operators running large-scale agent workloads: a cluster-wide ceiling of 65,536 network identities.

The stakes are considerable. AI agent workloads, particularly reinforcement learning systems, may require thousands of isolated sandboxes to start and stop every minute, and Google says some research users are seeking infrastructure for up to one million concurrent sandboxes. The update addresses a bottleneck that sits between autonomous AI workflows and the compute — often GPUs and TPUs — waiting idle while orchestration layers wait for supporting infrastructure to become available.

What was the actual bottleneck?

The problem centred on how GKE Dataplane V2, which uses eBPF-based networking (a Linux kernel technology that filters and routes packets programmatically), maps pod labels to numeric identities for security policy enforcement.

In workloads where each pod receives unique labels — agent identifiers, timestamps or claim references — the platform may need to assign a distinct identity to each sandbox. That process slows pod creation and pushes workloads toward the 65,536 identity limit associated with Cilium-based identity management. Cilium is the open-source networking layer that underpins Dataplane V2.

The pain is specific to high-churn workloads. Thousands of short-lived code execution environments created and removed in quick succession, each carrying per-pod uniqueness in its labels, cause identity counts to grow linearly as orchestration frameworks attach large numbers of unique labels to individual pods.

How does Google's fix work?

Google has split identifying data from metadata that does not need to be part of service selection or core resource grouping. The approach has two parts.

• Move high-cardinality fields to annotations. Google encourages users to shift fields such as sandbox hashes and timestamps from pod labels to annotations, since annotations are not used by GKE Dataplane V2 when calculating network identities. Identical agent types can then share a single identity even if other metadata differs between sandboxes.
• Filter dynamic labels out of identity calculation. Users can configure exclusion rules in Cilium so labels such as sandbox hashes or timestamps are ignored when network identities are created. This prevents linear growth in identity counts.

Google says the second measure also helps environments avoid the 65,536 identity limit associated with Cilium-based identity management.

The framing matters. Google did not alter the underlying security model; the changes preserve existing network security controls while reducing the amount of per-pod uniqueness included in identity calculations. That distinction is relevant for teams building agent systems with high pod churn, because labels often serve several operational purposes at once. Some are needed for grouping and service matching inside Kubernetes, while others are simply metadata added by developer tools, controllers or workload managers. Google's guidance: keep only identity-relevant fields in labels and move the rest elsewhere.

What performance did Google claim?

Google linked the networking changes to a broader effort to increase density and reduce start-up delays for AI agent infrastructure. The headline figures:

• 300 sandboxes per second at sub-second latency for fully isolated agents, once high-cardinality metadata is removed from identity calculations.
• 500 activations per second sustained while running 200,000 agents in benchmark testing cited by Google for Agent Substrate on GKE.
• Suspend and resume latency below 500 milliseconds in the same benchmark testing.
• Agent state restored in less than a second for workloads with large numbers of idle sessions.

Agent Sandbox on GKE serves as the isolation layer for dynamic code-execution environments. Agent Substrate on GKE builds on those foundations, and Google says it also bypasses some Kubernetes scheduling limits for users seeking higher scale and density.

Who is running this in production?

Google said one customer using Agent Substrate has orchestrated hundreds of thousands of secure environments across clusters and handled spikes of more than 30,000 sandboxes on a single cluster. The company did not name the customer in material released alongside the update.

Why does this matter beyond Google?

The update reflects a broader infrastructure challenge in AI operations. Customers are moving from request-response systems to autonomous workflows that require persistent or rapidly recreated execution environments. In those settings, delays in sandbox creation leave GPUs and TPUs idle while orchestration layers wait for infrastructure.

The economics follow directly. According to Google, the changes would cut provisioning latency, raise compute density and reduce wasted accelerator time in large clusters running AI agents. The architectural changes are intended to make large-scale agent operations more economically viable by limiting infrastructure bottlenecks tied to network identity management.

For platform teams, the practical takeaway is a labelling discipline question: identity-relevant fields stay in labels, everything else moves to annotations or exclusion rules. For vendors building agent orchestration on Kubernetes, Google has signalled where the next round of scaling pressure will land — not in model inference, but in the identity and scheduling plumbing underneath it.