Google is rebuilding its cloud around code it doesn't trust

Google Cloud's August infrastructure roundup looks like a grab-bag: a new Filestore backend, a serverless pricing tweak, an RL scheduler, a compliance controller. Read the releases together and they describe a single workload the cloud wasn't built for. Agents run for days, not milliseconds. They execute code a model wrote thirty seconds ago. They hold state per user instead of per request. Every item on Google's August list bends some piece of the platform toward that shape, and the bending tells you more than any individual launch does.

Untrusted code becomes a workload class

The clearest signal is how much isolation tech shipped at once. Google and Anyscale added an experimental sandboxing library to Ray 2.58 that runs model-generated code inside gVisor, Google's user-space application kernel, instead of directly in a Ray worker process. You call the sandbox through a normal Ray Actor method and a proxy forwards the operation to wherever the gVisor-backed workload actually lives in the cluster. Meanwhile GKE Agent Sandbox, announced at Next '26, went GA, and Google open-sourced Agent Substrate, a project aimed at agent fleets making millions of short-lived tool calls, the regime where the Kubernetes control plane itself becomes the bottleneck.

There's real history here. AWS built Firecracker in 2018 because Lambda needed VM-grade isolation at container speed. Google open-sourced gVisor the same year for the same reason. What changed is who writes the code being isolated. When the untrusted party was a customer, one sandbox per tenant was enough. When it's a model emitting Python mid-conversation, you need thousands of cheap, disposable, fast-booting cells, and startups like E2B, Modal, and Daytona have spent two years selling exactly that. Agent Sandbox landing as an open-source Kubernetes SIG Apps subproject, not just a GKE add-on, reads as Google trying to make the primitive boring before those startups make it a business. If you run agents on any Kubernetes, that's good news. If you sell sandboxes, your pitch just got harder.

The practical takeaway for platform teams: the era of hand-rolling nsjail wrappers or renting a per-execution sandbox API is closing. The Ray integration matters most for RL and code-eval pipelines, where generated code already flows through Ray workers with no isolation at all. It's experimental, gVisor-only for now, and best suited to short-lived, CPU-bound execution without network access. Don't put it in a serving path yet.

Serverless admits the agent isn't a request

The more surprising release is Cloud Run instances, in preview since late August. Cloud Run's whole identity was scale-to-zero request handling. Instances invert that: a singleton runtime with no autoscaling, a stable HTTPS address across restarts, lifetimes up to seven days, priced at $5.70 a month for 1 vCPU and 1 GiB running continuously. That's not a serverless product. That's a tiny stateful server with managed restarts.

Cloudflare shipped this idea as Durable Objects back in 2020, and Fly Machines built a business on it. Google offering it now is a concession that the request/response model fails for agents, which sit mostly idle holding context for one user, then burst when a task arrives. The pricing model follows the workload: shared vCPU with burst budgets, cheap to keep alive, throttled if you hammer it. That's the right trade for a personal coding agent or a long-running research task. It's the wrong trade for anything compute-heavy and sustained, where burst budgets will bite and a GKE pod or plain VM stays the better answer. The seven-day lifetime also means your agent framework still needs real checkpointing; a stable address doesn't make execution durable.

Paying down idle accelerators

On the training side, llm-d, now a CNCF Sandbox project, gained co-operative time-slicing for reinforcement learning. RL post-training alternates between generating rollouts and training on them, so any single job leaves accelerators idle a large fraction of the time. The new scheduler snapshots device state and swaps a second job onto the same hardware during those gaps. Google's own benchmark claims aggregate duty cycles going from roughly 40% to 70% with no effect on convergence.

Treat that number as a vendor benchmark until third parties reproduce it, but the direction is obviously right. RL is becoming the dominant post-training recipe, H100-class capacity is still rationed, and a 30-point utilization swing is the difference between one experiment and two. The catch is the word "co-operative": jobs must participate in checkpointing through the provided Python libraries. This helps homogeneous fleets running many RL jobs, which mostly means labs and larger platform teams, not someone fine-tuning on eight GPUs.

The auditors show up

The sleeper release is k8s-aibom, an unprivileged controller that watches the Kubernetes API, fingerprints AI runtimes (vLLM, Triton, Ollama, LangChain, vector databases) from images, env vars, and args, and emits CycloneDX 1.6 ML-BOM documents. No sidecars, no eBPF, no privileged DaemonSets. With EU AI Act obligations phasing in through 2026 and 2027, "what models and inference stacks are running in this cluster" is turning into a question compliance teams ask with deadlines attached. Pattern-matching container specs will miss anything exotic, and a BOM built from heuristics is evidence, not proof. It's still far better than the spreadsheet most orgs use today, and it costs one Deployment to find out what shadow AI your clusters are running.

What it adds up to

None of these launches is huge alone, and two of the three interesting ones are preview or experimental. The shift is real anyway, because the same shapes keep appearing everywhere at once: sandboxed execution as a managed primitive, singleton long-lived runtimes, schedulers built around RL's burst pattern, inventory for regulators. Google is publishing its version, but Cloudflare, Fly, Anyscale, and the sandbox startups converged on the same architecture independently, which is usually the tell that the workload is driving the design rather than the marketing.

If you're building agent infrastructure now, the near-term moves are concrete: prototype on the open-source Agent Sandbox controller rather than a proprietary sandbox API, so the GKE add-on becomes an optimization instead of a dependency; try Cloud Run instances for per-user agents where idle cost dominates; and deploy k8s-aibom before someone in legal asks for the list you don't have. The platforms have decided agents are a workload class. The remaining question is how much of your custom glue they make obsolete, and on current pace the answer is most of it.