Cloud Blog

What’s new in AI infrastructure and orchestration in October

Fri, 30 Oct 2026 16:00:00 +0000

The Google Cloud AI Infrastructure team had another busy month in October, filled with new product launches and updates to power today’s AI and agentic workloads scalably and efficiently. We were also honored to share our progress with customers, partners, and the broader community at leading industry events, including NVIDIA GTC, PyTorch Conference, and AGNTCon + MCPCon. Let’s dive in!

Product, technology, and tools updates

New compute service: Agent Compute Engine is a purpose-built compute service providing high-performance, hardware-isolated microVM sandboxes alongside expanded agent governance capabilities like Agent Gateway and Agent Registry, all in the service of securing and scaling autonomous AI agents. Its primary benefits include rapid sub-second activation, extreme workload density through copy-on-write memory sharing, enterprise-grade security and identity management, and cross-cloud observability.
AI Hypercomputer updates: At NVIDIA GTC Berlin 2026 we announced updates to our agentic infrastructure, including to A5X instances powered by the NVIDIA Vera Rubin NVL72 platform, Virgo Network scale-out fabric, and Managed Lustre storage. These co-engineered advancements provide enterprises with accelerated performance, enhanced sovereign AI controls, while advanced Confidential Computing capabilities help you train and deploy complex multi-step models securely and efficiently.
GKE product update: CPU startup boost for GKE, in preview, uses Kubernetes In-place Pod Resize to dynamically elevate container CPU resources during initialization and scale them back down to steady-state levels without having to restart the containers. This feature removes startup throttling and accelerates cold starts by up to 2x for demanding workloads, helping to lower cloud infrastructure costs.
GKE product update: The preview of the Wiz Runtime Sensor add-on for Google Kubernetes Engine (GKE) brings low-touch deployment, automated lifecycle management, enterprise credential security, and fleet-wide governance to Wiz's eBPF runtime threat detection for both Standard and Autopilot GKE clusters.
Modernization tools: Together at last. Google Cloud Modernize brings Google Cloud’s migration and modernization tools, including Migration Center, Google Cloud VMware Engine, Google Cloud Mainframe Modernization and our new EKS-to-GKE Migration Agent, into a single portfolio. Enterprise teams now have purpose-built agentic capabilities across infrastructure assessment, platform modernization, and application modernization.
Cloud Run product update: Temporal Serverless Workers on Cloud Run automatically scale worker pools based on Temporal task queue demands and scale down to zero when idle. This integration eliminates cluster management, lowers costs, using Temporal Worker Versioning to safely handle stateful, long-running workflows and AI agent workloads.
New open-source product: llm-d 1.0 is an open-source, Kubernetes-native serving stack that turns a cluster of model servers into a coordinated serving pool, unifying distributed LLM inference across mixed Google Cloud TPU and GPU fleets. Co-founded by Google and partners, it provides production-ready benefits such as cache-aware routing, tiered KV cache offloading, and priority-based flow control to dramatically improve context reuse, reduce time-to-first-token latency, and efficiently scale multi-tenant agent workloads.
New open-source product: Working with Meta, we open-sourced TorchTPU, a native PyTorch stack that integrates Google TPUs directly into the PyTorch ecosystem alongside GPUs and CPUs. Now developers can train, serve, and deploy models natively on TPUs using familiar frameworks like Hugging Face, vLLM, and TorchTitan.
Google Distributed Cloud updates: Organizations that operate under strict sovereignty mandates would love to use AI to help them process data, but can’t send it to the cloud. The latest version of Google Distributed Cloud (GDC) air-gapped brings frontier AI models and multimodal enterprise search with Gemini into these isolated environments. In addition, GDC air-gapped supports NVIDIA HGX B300 systems based on the NVIDIA Blackwell Ultra architecture, and features enhanced networking and security capabilities.
Edge inference product: Google open-sourced ML Drift, a cross-platform on-device GPU compute engine built for LiteRT that abstracts hardware complexities across OpenGL ES, OpenCL, Metal, and WebGPU. The framework delivers peak performance, enhanced 5D tensor support, and memory efficiency for both classical machine learning workloads and advanced generative AI models at the edge.
Open-weight model support: Reflection's Beam is an open-weight, 501-parameter model released under an Apache 2.0 license designed specifically for frontier software engineering and long-horizon agentic tasks. We announced day 0 support and ready-to-run deployment recipes for service Beam on AI Hypercomputer and NVIDIA AI Infrastructure.

Practitioner guides and how-tos

AI network reference architectures: In Networking for AI inference model serving - GKE only and for all other backends, learn about reference architectures for AI inference model serving that provide centralized governance and private IP routing using Private Service Connect, Apigee API Management, and Model Armor. These architectures simplify multi-model scaling and prompt security across GKE, Cloud Run, and hybrid clouds.
How-to guide: A Tale of TPU Observability on GKE: Part 2 - Dynamic Slicing Enhancements breaks down GKE's new Dynamic Slicing observability tools and metrics for next-generation v7 TPUs through an engaging, story-driven observability guide featuring Alex, a lead AI platform engineer. Explore the step-by-step diagnostic workflows with real-world examples and handy command-line snippets. Check out Part 1 here.

Customer and partner updates

AI21 achieves an 83% reduction in time-to-start for AI workloads with AI Hypercomputer: Frontier lab AI21 needed a new stack on which to train its Jamba family, and chose AI Hypercomputer configured with GKE on A3 and A3 Ultra instances. By doing so, AI21 says it cut high-priority job wait times from 72 hours to 12, and manual scheduling interventions from 20 per week to zero.
Visko streams real-time world models on Google Cloud TPUs: Visko, an AI startup developing interactive world models, deployed an end-to-end live inference pipeline that combines video generation, super-resolution upscaling, and synchronized audio onto a single Cloud TPU slice. In this blog, the team discusses how it engineered the pipeline, the architectural optimizations it made, and practical lessons for other startups building ultra-low-latency generative AI.
ZenteiQ scales physical AI inference 4x with GKE and llm-d: In order to pre-train models that understand physical laws, governing equations, and numerical solvers, Indian AI startup ZenteiQ designed and built a large-scale batch synthetic data-generation pipeline that runs across multiple model families and feeds verified datasets into training runs. GKE and GKE Inference Gateway gave ZenteiQ the inference-routing layer within its pipeline to scale aggregate inference throughput 4.07x and grow daily output from 1.47 billion to 5.97 billion generated tokens for every 1,000 accelerators.
Palo Alto Networks modernizes cloud-delivered security service: Palo Alto has worked with Google Cloud since 2018 to deliver its Prisma Access security service, and it was time to update it. In order not to compromise its security guarantees, Palo Alto separated the platform into two independently scalable layers: an ingress layer that handles traffic routing and forwarding running on GKE, with Axion C4A instances; and a security layer that handles threat inspection, running on dedicated single-tenant VMs fronted by an Internal Load Balancer. Each layer can now scale, update, and operate independently.
Oracle is the first hyperscaler to provide TPUs outside Google Cloud: By deploying Google TPUs, Oracle is broadening the range of AI chips available through its Oracle Cloud Infrastructure (OCI), and giving customers more options for running AI workloads. Google TPUs on OCI will be available in 2027.

Research, reports and deep-dives

New resource: As enterprise organizations shift from isolated AI experiments to production-scale systems, different departments — from engineering and finance to executive leadership — often speak different technical dialects; The Encyclopedia of AI Infrastructure bridges that communication gap by demystifying complex infrastructure jargon.
Analyst report: We are thrilled to announce that Google was named a Leader in the inaugural 2026 IDC MarketScape for Agentic AI Platforms.
Deep dive: A companion technical guide describing the architecture of Agent Compute Engine and how Google’s Gemini team needed both the isolation of a VM and the speed and density of a container to deliver personal agents for every Gemini user.

September 2026

Product, technology, and tools updates

Google Kubernetes Engine updates: The GKE team is all about improving the scalability of the platform, and in September, those improvements came in many shapes and sizes:

New feature: Need an execution runtime with higher density for your agentic workloads? We engineered the new open-source GKE Agent Substrate to run millions of sandboxes with 10x higher density than standard container runtimes. Agent Substrate also delivers sub-500ms resume operations at over 500 suspend/resume activations per second with a native zero-trust kernel and network isolation.
Product update: GKE now has scale-to-zero capabilities built-in. No need to configure complex components to scale your workloads down, thanks to the HPA with the Autoscaling Metric and support for KEP-2021, which do the job for you, out of the box. Read the blog to learn more.
Product update: Further, the GKE HPA (with the above-mentioned Autoscaling Metric) now lets you scale up and down based on custom PromQL metrics, in addition to standard metrics, allowing you to trigger workloads according to conditions that are meaningful and unique to your business. Read more here.
New feature: Yet another scalability feature is GKE Pod snapshots, which lets you save the running state of your workload, including CPU and GPU memory, and restore it on demand. According to internal tests, GKE Pod snapshots can reduce AI inference start-up by as much as 89%. Learn more here.
New migration tool: Finally, if you’ve always wanted to migrate your container workloads from AWS EKS to GKE but feared a daunting, high-friction engineering endeavor, we’ve just launched GKE agentic migration, a purpose-built agent plugin that replaces brittle, ad-hoc prompting with an AI-assisted migration pipeline protected by deterministic guardrails. Designed as a compilation of agent skills and a local Model Context Protocol (MCP) server, it uses AI to translate complex AWS EKS IaC and Kubernetes manifests directly into GKE landing zones. Get started with the onboarding guide.
Feature updates: Reinforcement learning (RL) and evaluation workloads are a beast: In a standard agentic RL loop, an LLM policy generates actions like code snippets on GPUs and executes them inside isolated CPU sandboxes to observe a reward signal. However, when scaling up this loop to support tens of thousands of parallel rollouts, infrastructure bottlenecks emerge, for instance idle accelerators, image cardinality, and a saturated control plane. To help, we developed GKE Agent Sandbox optimized for RL, plus an Agent Sandbox RL orchestration SDK and native integrations for popular RL gyms and harnesses. All are now generally available, and you can learn more here.

Storage updates: AI trains and creates lots of data, and that data has to live somewhere — in block storage systems, file systems, object stores and databases. We announced enhancements to our storage portfolio to help this critical layer roll with the agentic punches:

Product update: Filestore agent volumes offer high-performance, elastic, persistent file storage for agentic workloads. Thanks to its tight integration with GKE Agent Substrate and GKE Agent Sandbox, Filestore agent volumes automatically allocates and attaches a dedicated, isolated file workspace to GKE agent sandboxes in milliseconds. Request access to the preview here.
New product: If you run generative AI and RAG data layers — think Milvus, Pinecone, Qdrant, Vespa, Redis, and in-memory context caching — you may want to take a look at the M4N family of VMs, now GA, which offers the highest per-core IOPS and throughput of leading hyperscalers. Paired with Google Cloud's custom Titanium offload architecture and paired with Hyperdisk Extreme, M4N instances deliver up to 25,000 MiB/s (25 GiB/s) of aggregate host storage performance and up to 1 million IOPS.
New product: Another new Compute Engine product, Z4D, is GA, and a strong storage solution for AI/ML training and inference workloads. When configured as a bare metal instance, Z4D provides both the high local SSD (LSSD) capacity and low latency required by agentic microVMs, so you can run thousands of isolated sandboxes per host with native performance and efficiency. Learn about Z4D machines here.
Product update: Today’s AI training and inference pipelines create data faster than most storage management systems can keep up, creating challenges for teams trying to understand their storage estates. A new version of Storage Intelligence advisor makes it easier to answer the question: "What’s in my buckets?" and quickly identify unexpected changes. Then, enhanced batch operations let you automate bulk changes across your buckets — say, move storage classes, mass-delete stale or temporary data, or apply metadata, tagging, retention, or encryption changes. Learn about the latest in Storage Intelligence advisor here.
New product: Last but not least, a new version of AlloyDB for PostgreSQL brings together pioneering Google infrastructure — Colossus distributed file system, and Jupiter network — to power a new, no-compromises database architecture for the agentic era.

Practitioner guides and how-tos

How-to: Wish you could make GPUs and TPUs scattered around the globe behave as a single pool behind a single entry point? In this blog, we show you how to do just that. At the edge, the multi-cluster GKE Inference Gateway focuses on global, multi-region traffic distribution and high availability. Beneath that, the LLM-d router handles complex, memory-aware scheduling algorithms to keep utilization high. This architecture is deliberately runtime-, model-, and accelerator-agnostic, and in tests, routing traffic through the multi-cluster GKE Inference Gateway added less than 1% overhead.
Guide: Using or planning to use GKE on TPUs for AI model training or inference? Training massive Large Language Models (LLMs) or running high-throughput inference serving represents a significant investment in specialized AI hardware, such as Cloud TPUs and GPUs. To get the most out of every dollar spent, you need to understand workload lifecycle metrics in GKE. This detailed guide explains how to turn opaque cluster behaviors into actionable telemetry.

Customer and partner updates

GKE customer: Learn why gaming startup SeaVerse relies on GKE Agent Sandbox for its multi-tenant workloads, and how the platform helped it decrease its infrastructure costs by 60%.

Research, reports and deep-dives

In case you missed it, we’re also thrilled to share that Google has been named a leader, including achieving the highest score on either product or strategy, in three key analyst reports from Gartner and Forrester.

Google is a leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026: Highest overall score of any cloud provider!
Google named a Leader in 2026 Gartner® Magic Quadrant™ for Strategic Cloud Platform Services: Positioned furthest for “Completeness of Vision” of all vendors evaluated.
Google is a Leader in the 2026 Gartner Magic Quadrant for Container Management: Positioned highest in “Ability to Execute” of all vendors evaluated.
Google Cloud achieved a Gold rating in the latest SemiAnalysis ClusterMax 3.0 report, which evaluates the reliability, performance, support, pricing, and security of GPU providers globally. See the full report for more.

August 2026

Product, technology, and tools updates

Product update: Filestore, Google Cloud’s first-party, secure, scalable NFS file service, has emerged as a popular storage platform for AI and agentic workflows, and now, it’s even better suited to the task, with a new backend storage layer built directly on Colossus, Google’s foundational distributed storage system. This new backend lets you provision IOPS independently from storage capacity, and is deeply integrated with GKE. In AI environments, this can help you service so-called agentic swarms — large groups of agents that need to read and write to a common dataset — without a drop off in performance. For more, check out the blog post.
New feature: gVisor sandboxes are now available in distributed Ray clusters on GKE. In partnership with Anyscale, we introduced an experimental library for Ray that brings gVisor, Google’s open-source application kernel, directly into distributed Ray clusters. gVisor provides lightweight environments with stronger isolation than ordinary containers, plus fast startup times and low memory overhead. To try out these sandboxing capabilities on GKE, head over to the Ray sandboxing User Guide.
Product update: Looking for high-performance, easy-to-use infrastructure on which to run a personal AI agent, but don’t want to spend a lot of money? New Cloud Run instances are dedicated, singleton compute runtimes on Cloud Run that won’t shut down when the agent is idle. Better yet, the cost to run a Cloud Run instance with 1 vCPU and 1 GiB of memory continuously for 30 days is just $5.70.

Practitioner guides, documentation and how-tos

How-to guide: Big news in Model Context Protocol (MCP) land: As of the 2026-07-28 specification, the protocol core is “completely stateless. The handshake is gone. The initialize / initialized handshake (SEP-2575) and the logical Mcp-Session-Id header (SEP-2567) have been removed entirely. Instead, every request is now self-describing and independent.” Whoa. Learn more about the changes that the latest MCP specification brings, and more importantly, how to implement them, in this Google Developers blog.
Guide: Real-time AI systems make a mess of traditional network load balancing techniques. “Instead of handling isolated requests, the backend has to manage a continuous, live bidirectional stream. You’re dealing with a constant stream of audio chunks, transcripts, model outputs, and synthesized speech flowing back and forth simultaneously.” Things only get worse when the user gets involved. “The server has to immediately halt its current speech generation, pivot to update the context, maybe trigger a new tool, and start drafting a different response; this must be done without dropping the connection.” For a new approach to managing load in the AI era, read Scaling real-time AI agents with session-aware load balancing.
How-to: Learn how to build an elastic, scalable LLM inference platform on GKE, even with a mix of different GPU accelerators. The proposed architecture combines Capacity Advisor and Compute Advisor, plus high-performance storage like RunAI:model streamer or GCPFuse with parallel downloads. Get all the details here.
Documentation: The thing about hosts with GPUs or TPUs is that you can’t use live migration to update them, setting up a maintenance challenge. In this new docs page, learn how to update accelerator-equipped hosts according to your tolerance for downtime for your training and inference workloads.
Documentation: Advanced Compute Images, or ACIs, are standardized image stacks for AI/ML and HPC infrastructure, so you don’t need to manually build your own custom images. In this new docs page, learn how to create an ACI image using the Google Cloud CLI, console, or SchedMD's Slurm workload manager.
Guide: AI workloads are notoriously difficult to architect, resource-intensive, and bursty, which can also lead to scaling bottlenecks and large pools of underutilized — or misutilized — compute resources. A new blog outlines the three main ways to achieve dynamic capacity management in Google Cloud: 1) scheduling capacity for planned downtime; 2) maintaining automated fallback capacity for unplanned downtime; and 3) relying on GKE’s core orchestration capabilities to automate resource allocation.

Customer and partner updates

Business orchestration software provider UiPath was dealing with spiky workloads, and wanted more predictable costs. To get there, it re-architected its infrastructure, moving from isolated clusters to a shared Google Cloud GPU fleet that included both A3 VM instances (NVIDIA H100 GPUs) for training with G4 VM instances (NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs) for inference. You can read more about their architecture here.
Mirendil, an frontier AI lab focused on accelerating AI development, announced that it is using AI Hypercomputer with both TPUs and NVIDIA GPUs to support its model pre-training and post-training applications.
Replenit, a retail CRM provider, built its AI decision engine in Google Cloud, using BigQuery, Gemini Enterprise Agent Platform, and open-source Gemma models that it runs on Cloud TPUs. This latter combination provided Replenit with 90% lower pipeline costs than their previous cloud provider, the company reports. Read the full case study for more.
Malachyte architected its AI-powered e-commerce recommendation platform on top of Bigtable, Managed Service for Apache Kafka, Pub/Sub, Compute Engine, and last but not least, GKE. See how it all comes together in this blog.

July 2026

Product, technology, and tools updates

Product update: Google Cloud Managed Lustre is now GA, and available in four distinct performance tiers that deliver throughput ranging from 125 MB/s, 250 MB/s, 500 MB/s, to 1000 MB/s per TiB of capacity — with the ability to scale up to 8 PB of storage capacity. The Managed Lustre solution is powered by DDN’s EXAScaler, combining DDN's decades of leadership in high-performance storage with Google Cloud's expertise in cloud infrastructure.
Product update: C4N network and storage optimized VMs are now GA. C4N is our first network- and block-storage-optimized VM series built to eliminate data-transfer bottlenecks. Powered by 5th Gen Intel Xeon Scalable processors and built on Google's Titanium offloading hardware, it achieves 400 Gbps network bandwidth, 95 million packets per second (MPPS), and up to 25 GiB/s of block storage throughput when paired with Hyperdisk Extreme.
New feature: GKE Dataplane V2 up to 15K Nodes with Network Policies (GA). This capability enables standard GKE clusters to scale up to 15,000 nodes while maintaining full active Network Policy enforcement, supporting the massive infrastructure needs of large enterprise and AI/ML customers.
New feature: Co-operative time-slicing in llm-d. If you’re running reinforcement learning (RL) workloads, you can now interleave independent RL jobs onto shared physical hardware, increasing aggregate accelerator duty cycles from a ~40% baseline up to 70% without impacting model convergence or accuracy.
New AI security tool: Looking to secure your AI supply chain on GKE, deploy AI workloads safely, and cut down on shadow AI? We open-sourced k8s-aibom, a lightweight, unprivileged Kubernetes controller that continuously monitors container clusters to automatically detect running AI runtimes (like vLLM and Triton) and generate standard CycloneDX Machine Learning Bill of Materials (ML-BOMs). Check out the k8s-aibom project and get involved.

Practitioner guides and how-tos

How-to guide: On July 27, Google announced Day 0 support for Moonshot AI’s Kimi K3 2.8-trillion-parameter open-weight model, the day weights were released. Whichever your preferred deployment path — via Model Garden, custom orchestration, or GKE with llm-d recipes — this guide offers detailed step-by-step instructions to help you evaluate and pilot Kimi K3 in Google Cloud.
How-to guide: Google Kubernetes Engine (GKE) managed DRANET supports both GPUs and TPUs. There are several configurations to use this implementation, including standard cluster (where you have full control) and autopilot cluster (where Google does the heavy configs for you). Take a deeper dive in the hands-on lab, GKE Autopilot clusters with TPUs, GKE managed DRANET and Gemma 4.
How-to guide: Learn to run Ray on TPUs, not GPUs. In Part 1 of this two-part series, we discuss TPU slices (hint: Ray thinks of them as just another accelerator on which to schedule), then walk through Ray’s various AI libraries (Part 2).
How-to guide: Evaluate TPUs for sample workloads using a new microbenchmark suite that helps you accurately assess whether a device is achieving its theoretical performance specifications, and to identify specific performance gaps or architecture-specific bottlenecks. Dive in here.
How-to guide: Scale your agents without killing your budget. Learn how GKE orchestration can help you safely pack more agents onto a fixed compute footprint with GKE Agent Sandbox and Pod snapshots. Whether your goal is performance or cost optimization, we teach you how to turn the right dials for optimal agent efficiency.
Technical blueprint: Inside the optimization of Mistral 3 large inference on Ironwood. This blog outlines how one Google team optimized Mistral 3 large MoE model inference on Google’s Ironwood (TPU v7x), achieving a 1.5x performance gain. They did so with hybrid sharding, replacing linear VPU summations with tree reductions, optimizing GMM/MLA kernels, and adopting asynchronous scheduling. As a result, they boosted throughput by up to 48% while maintaining benchmark accuracy neutrality. Read the full blog here.

Research, reports and deep-dives

Report: Google was named a Leader in the inaugural GartnerⓇ Magic Quadrant™ for AI Infrastructure, positioned highest for ‘Ability to Execute’ and furthest for ‘Completeness of Vision’. Gartner called out Google’s proprietary scalable compute, integrated AI Hypercomputer architecture, and the scale of our AI compute capacity as key strengths. Download a copy here.
Report: We recently surveyed more than 1,400 senior IT leaders for our State of AI Infrastructure report, and a resounding pattern emerged: The gap between AI ambition and infrastructure reality is widening. In fact, 83% of organizations say they require infrastructure upgrades to support production-grade agentic AI. Read the accompanying blog to understand how adapting your infrastructure to meet the demands that agentic applications place on your systems will help you move from pilot to production.

June 2026

Product, technology and tool updates

Product update: Protecting sensitive data used with AI is a critical part of advanced and secure cloud infrastructure. Confidential Computing cryptographically protects data in use in hardware-based Trusted Execution Environments (TEEs) with verifiable data integrity, and is now available on the accelerator-optimized G4 machine series, featuring NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. Get started with Confidential G4 VMs and Confidential G4 GKE Nodes.
Developer resource: The new TPU Developer Hub is the place to go for model builders, optimizers, and developers to learn to unlock the full performance of Google Cloud TPUs. Read more in this blog.
New product: Scale your AI workloads with the new OpenTelemetry-Based TPU AI Telemetry Collector Agent. For the first time, you can route high-fidelity TPU hardware telemetry to Google Cloud Monitoring, Google Managed Prometheus, or your own self-hosted Grafana stack.

Practitioner guides and how-tos

How-to guide: Learn how to build high availability into an AI inference workload running on GKE Inference Gateway with TPUs, Cloud Storage FUSE and Dynamic Resource Allocation (DRA). This blog provides an overview, or you can get all the technical details in the hands-on codelab.
How-to guide: Did you know you can connect your AI agents to unstructured data in Cloud Storage via Model Context Protocol (MCP)? In this blog, learn about why would want to do that from three customer examples, then how to do it, choosing either a fully managed service, or a self-managed local server for more customization and control.

Research, reports and deep-dives

Report: According to an independent benchmark report, GKE Inference Gateway outperforms the next leading managed Kubernetes service with 15.7% higher throughput, 92.8% shorter wait times, and 62.6% lower inter-token latency. This performance can be attributed to its use of prefix caching, which optimizes LLM performance by storing the KV cache (activation states) of long, repetitive prompt prefixes. Learn more in the blog.
Architecture deep dive: A closer look at the cold start problem, this time for TPUs and GKE, and how the Run:ai Model Streamer can help change the dynamic.

Customer and partner updates

Customer win: Leveraging GKE, BigQuery, Cloud SQL, and Gemini Enterprise Agent Platform, Pager Health is eliminating operational fragmentation to deliver a simplified, personalized U.S. healthcare experience that transforms lives.
Customer win: Trustpilot, the customer review platform, built a high-volume streaming pipeline using fine-tuned Gemma models with Dataflow and Gemini Enterprise Agent Platform running on cost-optimized A2 VMs using A100 GPUs, as well as optimized version of vLLM maintained by Gemini Enterprise Agent Platform.

May 2026

Product, technology and tool updates

Product update: GKE Agent Sandbox is now generally available.
New open-source project: Agent Substrate is a new open-source project aimed at continuing to push the limits of agentic infrastructure density
New feature: Google AI Edge Portal, a solution for testing and benchmarking on-device machine learning (ML) at scale, now supports benchmarking and debugging on-device LLMs. Read more here.
Product deep dive: We went into depth about Cloud Storage Rapid, a new family of high-performance storage offerings for AI workloads. At launch, offerings include Rapid Bucket (formerly Rapid Storage), a high-performance zonal object storage offering, and Rapid Cache (formerly Anywhere Cache), which accelerates reads on-demand and colocates compute and data for workloads in existing buckets.

Research, reports and deep dives

Architecture deep dive: Google Global Infrastructure VP Bikash Koley and Engineering Fellow Arjun Singh provide a high-level overview of the challenges that AI workloads pose to network infrastructure, and discuss the deep enhancements we’ve made to our data center fabrics, WAN, and global networks to better support them.
Architecture deep dive: We unveiled a new cluster-level reliability model for developing frontier AI models on TPUs, ditching instance-level reliability

Customer and partner updates

Customer win: Visual media provider Imgix serves more than 8 billion images and videos from AI Hypercomputer equipped with G4 VMs powered by NVIDIA RTX PRO 6000 Blackwell GPUs.

When the Kubernetes API went silent: A three-layer networking mystery

Fri, 30 Oct 2026 16:00:00 +0000

Every support engineer has a case that stays with them. The one that comes up at team lunches. The one where, even after it's resolved, you find yourself staring at a packet capture at midnight just to make sure you really understand what happened. This is that case.

It started in January 2026 with a support ticket that read deceptively simply: pods are intermittently failing to reach the Kubernetes API server. The error was a familiar-looking timeout. The customer had already ruled out their own operators. What none of us knew yet was that we were looking at three separate bugs — in three different layers of the stack — all conspiring to produce the same symptom at the same time.

By the time it was over, around 800 developers had been blocked from deploying to production for weeks on end, and GKE clusters across europe-west had ground to a halt. In a race to fix the problem, we involved engineers across Google Kubernetes Engine (GKE), Private Service Connect, networking, hostnet, kernel, and the Linux upstream community, who together tracked down not one but three distinct root causes. And the final fix landed not as a config change or a feature flag, but as a patch to the Linux kernel itself.

This is the story of how we got there.

Part one: The alarm bell that wouldn't stop

The customer ran a large multi-cluster GKE environment in Google Cloud's europe-west region. Their clusters used Private Service Connect — Google Cloud's mechanism for exposing the GKE control plane privately — and had a rich ecosystem of system-level workloads: Twistlock security scanners, External Secrets Operator for secrets management, Cilium for network policy, as well as several internal Kubernetes operators.

The first errors appeared in one of its user acceptance testing (UAT) clusters in europe-west, and a few days later in a second cluster in the same region. They looked like this:

Application logs — pods across multiple namespaces

code_block: <ListValue: [StructValue([('code', "TimeoutError: Connect call failed ('1.2.3.4', 443)\r\ndial tcp 1.2.3.4:443: i/o timeout\r\n\r\n# 1.2.3.4 is the cluster's internal VIP for the kube-apiserver,\r\n# routed through Private Service Connect"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eea5ad0>)])]>

Initially the errors were intermittent — spikes in the logs, not a hard outage. The customer suspected their own code. Their team had recently deployed a custom operator built with the kopf framework, and it was the first thing they looked at. But the logs showed the errors had started eight days before the operator was ever deployed. When they shut it down completely, the timeouts kept coming.

The issue persists even after completely scaling down the External Secrets Operator. The errors are appearing from customer workloads, and system-level pods we haven't touched.

The growing list of suspects

When a case like this arrives, the first instinct is to ask: what changed? The customer's timeline gave us several candidates, and we worked through them methodically.

The custom operator (kopf): Ruled out immediately — errors predated deployment by a week and continued after shutdown.
External Secrets Operator: Removed entirely on customer request. Timeouts continued in customer workloads that relied on Kubernetes control plane (KCP) connectivity, and cluster-internal system pods.
Security agents: Uninstalled. Same result. We were now watching system-level Kubernetes components fail to reach their own control plane.
conntrack table exhaustion: One theory was that too many half-open connections were filling the OS connection tracking table on the control plane nodes. We checked. The conntrack table was at roughly 50% capacity — of a default maximum of 1.3M entries. Not even close to exhaustion.
Control plane overload: We scaled up the KCP VM size. kube-apiserver latencies looked healthy. No improvement on the timeout side.

What made this case genuinely strange was the scope. We confirmed the timeouts were happening across five different clusters, affecting DaemonSets, Deployments, and system pods alike. External clients — developer laptops, GitHub Actions runners — were also hitting the same wall. This was not a broken workload. This was something wrong with the path between everything and the API server.

The timeline so far

Day 1: First I/O timeout errors appear (One of the UAT clusters in europe-west3. Intermittent, easy to dismiss.)
Day 10: Errors become persistent (Frequency increases significantly. The issue is no longer dismissible.)
Day 15: Case escalated — P0 bug filed (Multiple clusters confirmed affected. ~800 developers blocked. Production releases are frozen. Formal escalation begins.)
Day 20: All obvious suspects ruled out (Custom operator, security agents, conntrack exhaustion, control plane resizing — all cleared.)
Day 22: Packet captures collected (Captures taken simultaneously at the control-plane node NIC and from inside the kube-api container. The investigation enters its most critical phase.)

With the obvious suspects cleared, and the scope undeniably wide, we did what you do when the application layer has nothing left to say: We went to the packets.

Part two: Tracing the ghost in the wire

To understand what the packet captures revealed, you first need to understand the architecture that a GKE pod traverses when it makes an API call. In a Private Service Connect-based GKE cluster, the path is deceptively long for something that looks like a local connection.

(Note for formatting: Consider including the Pod → kube-apiserver flow diagram here: Pod -> Worker Node -> PSC NAT+Proxy -> ILB -> KCP VM NIC -> kube-apiserver)

The key component here is Private Service Connect. When a pod dials 1.2.3.4:443, it is not actually going directly to the control plane; that IP is a virtual endpoint. The connection is intercepted by Google's networking fabric, NAT'd through a Private Service Connect endpoint, passed through an internal passthrough Network Load Balancer, and ultimately delivered to the KCP VM, where Envoy acts as a local proxy in front of the actual kube-apiserver process.

Private Service Connect adds a proxy protocol header to each new connection, so the kube-apiserver can see the real client IP. This will turn out to be important later.

What the packets revealed

When we captured simultaneously at the KCP VM's NIC (the PIGv interface, Google's programmable virtual NIC) and from inside the kube-apiserver container, we saw something striking.

SYN packets from the pods were arriving at the KCP VM's NIC. They were getting that far. But instead of receiving a SYN-ACK in response — the expected second step of a TCP handshake — the client was getting back an out-of-place ACK. Not an RST. Not silence. An ACK that logically belonged to a different, earlier connection.

Wireshark, the network protocol analyzer, was flagging these streams with a label that initially seemed innocuous: "TCP Port numbers reused."

Wireshark — packet stream showing the failed handshake

code_block: <ListValue: [StructValue([('code', 'Time Source Port → Destination Port Info\r\n09:13:41 10.0.13.77 53426 → 10.117.0.2 443 [SYN] Seq=0 Win=42600\r\n09:13:41 10.117.0.2 443 → 10.0.13.77 53426 [SYN, ACK] Seq=0 Ack=1 Win=64768\r\n ... (data exchange, connection completes)\r\n09:13:42 10.117.0.2 443 → 10.0.13.77 53426 [TCP Retransmission]\r\n09:13:42 10.117.0.2 443 → 10.0.13.77 53426 [TCP Retransmission]\r\n ... (many retransmissions of the same ACK)\r\n\r\n# 2 minutes later, same port 53426 is reused for a new connection\r\n09:13:44 10.0.13.77 53426 → 10.117.0.2 443 [SYN] Seq=1498 ← NEW connection\r\n (expected: SYN-ACK)\r\n (received: ACK Seq=1498 Ack=1025 — belongs to PREVIOUS stream)\r\n09:13:44 10.0.13.77 53426 → 10.117.0.2 443 [SYN] Retransmit...\r\n09:13:44 10.0.13.77 53426 → 10.117.0.2 443 [SYN] Retransmit...\r\n → eventually: i/o timeout'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eea52d0>)])]>

The pattern was clear. Something was causing the KCP VM to respond to a fresh SYN with an ACK that belonged to a different connection that had ended minutes ago. The old connection had used the same source port (53426 in the example above), and the KCP VM had never fully let go of it.

"The KCP server sends FIN,ACK; client responds with FIN,ACK and then ACK. But KCP receives ACK before FIN,ACK. KCP server never ACKs the FIN,ACK — continuous retransmission of ACK. RST does not clear state."

The "Invalid ACK" spike

While one thread of the investigation was analyzing packet captures, a.k.a., pcaps, another team was digging into internal metrics for the Private Service Connect infrastructure — specifically the user space packet switch (USPS), Google's software switching layer that handles NAT and proxy protocol header injection for Private Service Connect connections.

They found something alarming in the metrics for Andromeda, Google's networking fabric. A counter called "Proxy protocol drop: invalid ACK packet" had been flat for months — and then, in February 2026, it spiked sharply upward to several drops per second across the affected europe-west regions.

That date matched a USPS version rollout. This version included a change which was a fix for a different bug but something about it had changed the behavior of how Private Service Connect handled a specific class of packet.

Challenge ACKs: The RFC 5961 mechanism

To understand the next piece of the puzzle, we need to talk about a TCP security mechanism called the challenge ACK, defined in RFC 5961.

Imagine a TCP connection has closed — gone through the FIN/ACK dance and terminated. The server-side (here, the KCP VM) may still briefly remember the connection's sequence numbers in its TCP state machine. Now imagine that shortly afterward, a new client connection arrives on the same source port and destination port (the same 5-tuple). From the kernel's perspective, this could be a stale packet from the old connection, or it could be an attacker trying to inject data into what the kernel thinks is still an open session.

RFC 5961 says: when you receive a SYN that matches an existing or recently-closed connection's remembered state, don't accept it blindly. Send a challenge ACK — an acknowledgment that carries the last known sequence number of the old connection. If the new client is legitimate, it will see this unexpected ACK, recognize the connection is stale, and send a RST to clear the state. The server then accepts the next SYN normally.

The challenge ACK flow — how it's supposed to work

code_block: <ListValue: [StructValue([('code', '# Step 1: New client sends SYN on a reused port\r\nClient → Server: SYN (seq=X, same 5-tuple as an old connection)\r\n\r\n# Step 2: Server is in FIN_WAIT_2, sends challenge ACK\r\nServer → Client: ACK (ack=old_seq — "is this really you?")\r\n\r\n# Step 3: Client recognizes the stale state, resets it\r\nClient → Server: RST\r\n\r\n# Step 4: State is cleared. Server accepts the next SYN normally.\r\nClient → Server: SYN (new connection)\r\nServer → Client: SYN-ACK ← handshake succeeds'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eea5910>)])]>

This mechanism works perfectly — when the challenge ACK is allowed through. But that was exactly what the new USPS change was blocking.

The culprit: A well-intentioned fix

The change in USPS had been designed to fix a legitimate security issue in Private Service Connect's proxy protocol handling. Part of its effect was to drop packets it classified as "invalid ACKs" during the connection handshake phase — specifically, ACKs that arrived before the initial SYN-ACK had been sent, which in normal circumstances would be anomalous.

Unfortunately, challenge ACKs look exactly like this: They arrive from the server before the new handshake has completed, in response to a SYN. From the USPS's new perspective, they looked like invalid packets. They were dropped silently.

Why this broke GKE specifically: Private Service Connect uses NAT to share a single public endpoint across many client pods. This means many different pods — running on different nodes, from different namespaces — can all end up using the same source port after NAT, creating a high rate of 5-tuple collisions. The challenge ACK mechanism was being triggered far more often than it would be in a normal direct-connection scenario. The USPS fix hadn't introduced challenge ACKs — they had always been there. It had introduced the dropping of them, which broke a flow that GKE's TCP stack had silently depended on to clear stale state.

Mitigation: Rolling back the change

In February, we rolled back the USPS change, restoring the old behavior where challenge ACKs were passed through instead of dropped. The rate of "Proxy protocol drop: invalid ACK packet" dropped back toward baseline almost immediately.

By early March , 2026, the customer confirmed that all affected clusters had recovered. No more timeout errors.

But the rollback wasn't a fix. It was a band-aid. It restored the behavior the system had accidentally depended on. The deeper question — why was the KCP VM in FIN_WAIT_2 for over two minutes in the first place? — was still completely unanswered.

That question led to Part 3. And it's where things got genuinely strange.

Part three: Three bugs, one crime scene

The mitigation bought us time, but it left a question hanging in the air: Why did the KCP VM keep connections in FIN_WAIT_2 for so long? A well-behaved TCP stack processes a FIN, acknowledges it, and closes the connection. The KCP VM was failing to do this, leaving half-open connections that persisted for more than two minutes — long enough for the port to be reused by Private Service Connect's NAT layer, long enough to cause the challenge ACK scenario we'd uncovered.

To answer this, we needed to understand not just one bug, but three distinct failure modes that had intersected at the worst possible moment.

Bug #1: Packet reordering at the PIGv

The first piece was discovered through careful analysis of simultaneous captures at two points: the KCP VM's host NIC (inside the physical host running the VM) versus the PIGv — the virtual NIC as seen by the VM.

At the host NIC level, packets arrived in perfect order. But by the time they crossed through USPS and appeared at the PIGv, they had been subtly reordered.

This happens because of how Private Service Connect's miss-thread processing works. When Private Service Connect intercepts a new flow it hasn't seen before (a "miss"), it processes that packet through a slower path that adds the proxy protocol header and sets up NAT state. Subsequent packets in the same flow take a fast path. The consequence: a FIN or RST packet belonging to a flow in mid-close might arrive slightly out of order relative to the ACKs that followed it.

What the KCP VM actually received (reordered sequence)

code_block: <ListValue: [StructValue([('code', "# What should have happened:\r\nClient → Server: FIN, ACK (client initiates close)\r\nServer → Client: ACK (server acknowledges client FIN)\r\nServer → Client: FIN, ACK (server initiates its own close)\r\nClient → Server: ACK (client acknowledges server FIN)\r\n → Connection fully closed. Both sides free.\r\n\r\n# What the KCP VM actually received (reordered by PIGv/USPS):\r\nClient → Server: ACK (arrives first — out of order)\r\nClient → Server: FIN, ACK (arrives second, but kernel sees ACK first)\r\nServer → Client: FIN, ACK (server sends close, enters FIN_WAIT_1)\r\nClient → Server: FIN, ACK (old, now-reordered FIN from client)\r\n → Server should ACK this. But it doesn't..."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ebd8750>)])]>

The reordering put the client's FIN after the server had already sent its own FIN. The server entered FIN_WAIT_1, then FIN_WAIT_2 after seeing the client's ACK of the server's FIN. But then the client's own FIN arrived — and the server's kernel ignored it.

Bug #2: Envoy's half-close and the frozen timer

Why couldn't the operating system clean up on its own? There is a Linux kernel parameter called tcp_fin_timeout that governs exactly this: how long a socket in FIN_WAIT_2 waits before being forcibly closed. On the KCP VM, this was set to 60 seconds.

But tcp_fin_timeout only applies to orphaned sockets — sockets that no process is currently holding open. Envoy, the proxy that sits in front of kube-apiserver on the KCP VM, was performing a half-close: it called shutdown(SHUT_WR), which closes the write side of the connection but keeps the socket open so it can still receive data. This is perfectly valid TCP behavior and is how graceful half-duplex termination is supposed to work.

The side effect: As long as Envoy held the socket with SHUT_WR, the kernel did not consider it orphaned. tcp_fin_timeout never started. The socket sat in FIN_WAIT_2 indefinitely, waiting for a client FIN it would never be able to process correctly.

Kernel socket state — captured via netstat just before a new connection

code_block: <ListValue: [StructValue([('code', 'Proto Local Address Foreign Address State\r\ntcp 10.128.0.5:443 10.0.13.77:53426 FIN_WAIT_2\r\n# This socket has been in FIN_WAIT_2 for > 120 seconds.\r\n# tcp_fin_timeout=60 has not fired because the socket is not orphaned.\r\n# Envoy holds it open with SHUT_WR.\r\n\r\n# 2 minutes later, Private Service Connect NAT reuses port 53426 for a new pod connection.\r\n# The kernel sees the new SYN on this 5-tuple and sends a challenge ACK.\r\n# USPS drops the challenge ACK. → i/o timeout.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ebda790>)])]>

Bug #3: The Linux kernel's silent failure

But there was still a missing piece. Even with the reordered FIN, a healthy kernel should still process a received FIN in FIN_WAIT_2 and move to TIME_WAIT. The socket should eventually close. Why wasn't it?

This led us deep into the Linux TCP state-machine implementation. When the reordered client FIN arrived at the KCP VM, the kernel's tcp_ack() function was called to process it. And here, in kernel version 6.1 (which underpinned the Container-Optimized OS (COS) running on the KCP VMs), there was a bug.

RFC 5961 added stricter validation for acceptable ACK numbers — specifically, an ACK could be considered valid even if it was slightly "old" (within a sequence number window), to handle network reordering. But in kernel 6.1, there was a code path where tcp_ack() returned zero — indicating "this packet was not fully processed" — when it encountered an ACK that was old but within the RFC 5961 acceptable window. The caller of tcp_ack() in the FIN processing path checked this return value, saw zero, and did… nothing. The FIN was received and silently discarded.

The Linux kernel commit that fixed it (upstream)

code_block: <ListValue: [StructValue([('code', 'commit 795a7dfbc3d9\r\nAuthor: Eric Dumazet <edumazet@google.com>\r\nnet: tcp: accept old ack during closing\r\n\r\ntcp_ack() returns 0 when ack is old but acceptable wrt rfc5961.\r\nIn FIN_WAIT_2, this caused tcp_fin() to never be called for a\r\nvalid received FIN, leaving the connection stuck indefinitely.\r\n\r\nFixed: properly handle old-but-acceptable ACKs during connection close.\r\nIntroduced in 6.1, fixed in 6.9.7. LTS backports: 6.6.y and 6.1.y.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ebda1d0>)])]>

The bug had existed since kernel 6.1 and was already fixed in kernel 6.9.7 — but GKE's KCP VMs were running COS builds based on 6.1 and 6.6. The fix needed to be backported and shipped as a COS image update.

How the three bugs combined

Individually, none of these three issues would have caused an outage of this magnitude. It took all three acting together to create the failure:

Bug #1 alone: Packet reordering is mildly disruptive, but the kernel would normally still eventually process the FIN and clean up, just slower than ideal.
Bug #2 alone: Envoy's half-close is perfectly correct behavior. It only becomes a problem if the FIN is never properly processed.
Bug #3 alone: The kernel's failure to process old-but-acceptable ACKs would cause some connections to linger, but the impact would be limited without the port-reuse pressure from Private Service Connect NAT.
All three together: Reordering causes the FIN to arrive out of sequence; the kernel bug prevents it from being processed; Envoy's SHUT_WR prevents the timeout from firing; the socket stays in FIN_WAIT_2 indefinitely. Private Service Connect NAT reuses the port. challenge ACK is sent. The USPS fix drops it. Connection fails.

The resolution: A three-pronged fix

Resolving this required action at three different levels, coordinated across multiple teams over several weeks:

Immediate mitigation (Feb, 2026): Rollback of change in USPS. Restored the previous behavior where challenge ACKs were forwarded rather than dropped. Customer clusters recovered by early March.
Correctness fix: A replacement change to handle the challenge ACK scenario properly in the Private Service Connect proxy protocol layer, rather than simply restoring the old drop behavior. A PacketDrill test was added to the test suite to prevent regression.
Root cause fix — Linux kernel patch: Upstream patch ("net: tcp: accept old ack during closing"), authored by Eric Dumazet. Merged into Linux 6.9.7. Backported to 6.6.y and 6.1.y LTS branches. — shipping in GKE 1.33.5 and later. The bug is fully resolved at the OS level for all GKE versions running these COS images.

What made this case different

Most networking cases resolve at one layer. You find the misconfigured firewall rule, the exhausted connection pool, the miscalculated MTU. You fix it and move on. This one was different because the symptom — i/o timeout on a connection that never completed — was the same whether you were looking at the Private Service Connect layer, the kernel's TCP state machine, or Envoy's connection management. Every layer had a plausible explanation, and every explanation was incomplete.

What finally cracked it was the discipline of simultaneous packet capture at multiple points in the path. Without captures at the host NIC, the PIGv, and inside the container at the same time, we would never have seen the reordering. Without correlating those pcaps to the USPS metric spike on February 18, we would never have found the dropped challenge ACKs. And without reproducing the issue in a lab environment, we would never have found the kernel bug that made the FIN_WAIT_2 state permanent.

The other thing that made this work was the team. Over the course of two weeks, engineers from seven or eight different specialties contributed: GKE networking, Private Service Connect infrastructure, Hostnet, Andromeda, KCP, and ultimately the kernel community. No single person could have held all of this in their head. The case notes, the shared bug tracker, the meticulously collected pcaps — they were the connective tissue that let a distributed team work as one.

In the end, the customer got back to production. The kernel got a better bug fix. And the rest of us got a very good story about why packet reordering, half-closed sockets, and a well-intentioned security patch should never be allowed in the same room at the same time.

_{This blog is based on real case data from an anonymized customer support engagement and internal bugs. The Linux kernel fix referenced is commit 795a7dfbc3d9, authored by Eric Dumazet. Special thanks to the engineers across GKE, Private Service Connect, Hostnet, Andromeda, COS, and the Linux networking community whose work made this resolution possible.}

Innovate on your own business terms: Google Cloud spend caps now generally available

Fri, 30 Oct 2026 16:00:00 +0000

Today, we’re announcing that spend caps on Google Cloud Budgets are generally available.

With this release, we’re delivering ways to protect your workloads from runaway costs without risking resource deletion. More importantly, we’re introducing three major updates, directly inspired by your feedback since the initial preview, to bring programmability, real-time visibility, and automated guardrails to your cost-control playbook.

How the new spend caps can help your business

We have significantly enhanced the usability and power of spend caps in three ways:

1. Automation through spend caps API: Managing guardrails manually across hundreds of projects is a major operational challenge. To address this, we have launched the spend caps API, which can be accessed from the existing Cloud Billing Budgets API. You can now programmatically enforce your financial boundaries for eligible services within each project, without additional overhead. You can automatically lift, update, or delete caps on the fly and instantly apply a spend cap whenever a developer spins up a new sandbox project.

2. Real-time visibility with live cost reports: Spend caps for AI services trigger within minutes of usage using estimated, live costs. When a cap triggers, you need to know exactly why and when the limit was breached. You can now view these faster, estimated costs directly inside your Cost Reports. Instead of waiting hours for standard billing pipelines to settle net costs, you get the exact financial snapshots that triggered the enforcement, giving you the immediate context needed to run a precise root-cause analysis.

3. Automated guardrails for your monthly resets: Before, once a spend cap was triggered, the usage block remained locked until you manually lifted it in the UI. Today, we are introducing automated monthly resets. You no longer need to worry about manually lifting caps every month. Enforced spend caps will automatically reset, and blocked services will seamlessly resume at the beginning of the next month. However, if your governance policies require a strict manual audit before resuming operations, the manual override option continues to exist exactly as before.

Best practices for deploying spend caps

As you roll out spend caps across your organization, keep these operational tips in mind:

Target non-production environments first: Start by applying strict, low-dollar spend caps to your developer sandboxes, testing clusters, and experimental AI agent playgrounds.
Configure alerts wisely: Default alerts are automatically sent to billing administrators and project owners at 50%, 80%, and 100% of the cap. Make sure the right folks are set up in these roles. This ensures your team is never caught off guard when a budget is nearing depletion. Spend caps permissions can also be added to custom roles, if needed.
Understand fixed vs on-demand costs: Spend caps halt pay-as-you-go and CUD-covered requests once the budget threshold is hit. However, Provisioned Throughput is never halted; requests using reserved capacity will continue to run, and serve traffic normally.

Refresher on GCP’s dual-pronged defense playbook

Spend Caps work seamlessly alongside our native Early Anomalies Detection to provide a closed-loop defense for your cloud spend. Read our previous blog for a detailed explanation on how to use these tools to effortlessly set up a GCP defense playbook.

Playbook step	Feature	Focus	Core action	Key benefit
Step 1	Early anomalies	Predictive monitoring	Analyzes early cost signals daily to alert you of directional spend variances	Spot anomalous cost spikes early and pinpoint the exact SKU driving the trend
Step 2	Spend caps	Financial enforcement	Programmatically pauses usage for a specific project/service once a budget is breached	Absolute protection against runaway spend without deleting resources

Get started today

Spend caps are now ready to support your workloads at scale. Read our documentation for more details and navigate to the Budgets and Alerts page in your Google Cloud Billing Console, to set your first spend cap.

To integrate programmatic guardrails into your deployment workflows, check out our newly published spend caps API documentation.

What’s new with Google Cloud

Fri, 30 Oct 2026 16:00:00 +0000

Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more.

Tip: Not sure where to find what you’re looking for on the Google Cloud blog? Start here: Google Cloud blog 101: Full list of topics, links, and resources.

aside_block: <ListValue: []>

Oct 26 - Oct 30

Simplify PostgreSQL Monitoring with the New AlloyDB Omni Web UI
The newly released AlloyDB Omni Web UI delivers a centralized, graphical dashboard that simplifies the management of self-managed PostgreSQL workloads across hybrid, multi-cloud, and air-gapped environments. This browser-based console provides database administrators with deep, real-time insights into cluster health, hardware utilization, and active database connections. It also features built-in query diagnostics and performance tracking for AlloyDB’s columnar engine, enabling quick troubleshooting of bottlenecks without manual terminal commands. To learn more about setting up this monitoring interface, read the full AlloyDB Omni Web UI Blog Post.
Leveraging "Antigravity" to architect high performance semantic model routers in Apigee
Semantic model routing replaces rigid static paths with a lightweight helper model to dynamically classify and dispatch intent-driven LLM traffic. Join Saravanakumar Rajagopal on Thursday, November 12, 2026, at 5:00 PM CET for a Community TechTalk exploring how to leverage Antigravity and skills to architect these intelligent multi-provider routing patterns natively inside Apigee. Discover how to optimize your AI infrastructure and enhance flexibility at scale.

Register for the November 12 Community TechTalk

Oct 19 - Oct 23

From prompt to production: End-to-end AI workflows in Apigee
Deploying an enterprise AI gateway does not require deep API or machine learning expertise. Using declarative workflows in Apigee, teams can spin up a fully governed LLM gateway in minutes using a few environment variables. Join Luis Cuellar on Thursday, October 29, 2026 for a Community TechTalk exploring end-to-end AI workflows. Discover how to layer essential defenses—including Model Armor for prompt protection, Cloud Data Loss Prevention (Cloud DLP) for sensitive data redaction, rate limiting, and response caching—before routing autonomous agent interactions through your gateway filters.

Register for the October 29 Community TechTalk
Zero Standing Privileges with PAM: On-Demand Temporary Access for Humans and AI Agents
AI agents now hand work off to other agents, risking stacked privileges and overpermissioning. Because agents plan their actions on the fly, permanent admin access means one hallucination can cascade into production. Join us on Wednesday, November 18, 2026, at 8:30 AM PST to see how Google Cloud Privileged Access Manager (PAM) brings Zero Standing Privileges to AI delegation, putting humans in command with cloud-native control that doesn't slow developers down.

Register for the November 18 webinar
Streaming comes to API Gateway: real-time and AI-ready APIs
Native streaming support is now in Public Preview for API Gateway, enabling you to run real-time and AI workloads behind your existing gateway. You can now route Server-Sent Events (SSE), WebSockets, gRPC, and chunked transfer encoding without modifying your API spec or managing a split estate. This update also strengthens integration with the Gemini platform, allowing you to stream responses from Gemini, Claude, and OpenAI gpt-oss models seamlessly while maintaining consistent authentication, rate limiting, and observability.

Read the blog to get started

Oct 12 - Oct 16

AI tokenomics in action: Enforcing tiered token budgets with Apigee
Scaling artificial intelligence across an enterprise requires clear token governance to keep LLM spend predictable across departments. Join Tarun Abraham on Thursday, November 5, 2026 for a Community TechTalk on AI tokenomics. Discover how to use Apigee to enforce isolated, tiered token budgets and model access for each team—such as assigning Engineering a dedicated budget for Gemini Pro while covering mixed usage for Marketing—without changing application code. Attendees will also gain access to a sample codebase featuring a reusable Shared Flow.

Register for the November 5 Community TechTalk

Sept 28 - Oct 2

Claude Sonnet 5.5 is now available on Google Cloud. Built for focused coding and knowledge work, it delivers stronger performance for feature development, and creating presentation-ready documents, while offering more intelligence with a lower cost per task for most work at faster speed.

Deploy Sonnet 5.5 directly from Model Garden with Google Cloud’s enterprise security, scale, and governance built in. Try it now.
Mastering Storage Management with Storage Intelligence
In our new blog, explore practical strategies to modernize storage operations using Storage Intelligence Advisor and enhanced Batch Operations. See how customers like Shipt and Palo Alto Networks are using these features to manage their estates at scale. Today, Storage Intelligence is used by 25 of the top 50 GCS customers. 2 in 3 customers have Storage Intelligence enabled for over 90% of their storage footprint.

Explore best practices on our blog
Cut Gen AI costs by 70% with Apigee X dynamic routing
Generative AI deployments face a harsh cost-performance trade-off: static model selection either wastes budget or compromises quality. Discover how to build an Intelligent AI Gateway using Apigee X to dynamically evaluate prompt complexity in real-time. This new blueprint automatically routes simple queries to lightweight models (like Gemini 3.5 Flash Lite) and complex reasoning tasks to advanced models (like Gemini 3.7 Flash), achieving over 70% cost savings without sacrificing output quality.

Read the guide to optimize your Gen AI architecture
AI Agent Clinic launches new hands-on session on production agent evaluations
A new episode of the AI Agent Clinic is now available showing organizations how to move past manual "vibe checks" to build robust, production-grade agent evaluations. In this hands-on session, Google Cloud engineer Dani Zamora and Matthew Feroz (Merge) take DocsHound, an open-source LangGraph agent, and build an end-to-end eval pipeline in under an hour. Learn how to standardize multi-turn traces across any framework using OpenTelemetry and OpenInference, pair LLM judges with deterministic checkers, and catch silent quality regressions before shipping.

Watch here
Drive AI impact: Join Google's Agentic Data Cloud event on Nov 4
Every enterprise plans to adopt agentic AI within two years, but data bottlenecks hold them back—AI accesses just 45% of enterprise data today (MIT, 2026). Google's Agentic Data Cloud provides the trustworthy foundation and real-time context AI needs. Join our product leaders November 4th to explore the latest innovations across databases, analytics, business intelligence, and storage, and get direct answers in our executive Q&A with Google Data Cloud VP & GM Andi Gutmans.

Register today!

Sept 21 - Sept 25

Master MCP tool authorization and agent governance with Apigee
While the Model Context Protocol (MCP) solves interoperability for autonomous AI agents, chained actions like CRM edits or database queries quickly expose systems to unauthorized execution. Join our technical deep dive on Thursday, October 1, 2026, at 5:00 PM CEST featuring Christophe from Google Cloud. Learn how positioning Apigee between MCP clients and enterprise backends enables fine-grained authorization (FGA), complete audit trails, and policy evaluation via emerging standards like OpenID AuthZEN.

Language and accessibility note: This session will be hosted in French, but non-French speakers can follow along seamlessly by turning on Google Meet live translated captions to read in English, Spanish, German, Portuguese, or Italian.

Register for the October 1 Community TechTalk
Apigee Trace Viewer Tutorial: Capturing & Analyzing Proxy Traces
Streamlining API proxy debugging just got easier with a new tutorial by Apigee Customer Engineer Tyler Ayers. The guide covers end-to-end instructions for capturing debug traces in both Google Cloud Apigee X (or Hybrid) and the local Apigee Emulator, extracting trace JSON data via the web UI or automated REST APIs, and analyzing execution flows, variable mutations, and latency bottlenecks using the open source Apigee Trace Viewer.

Read the Apigee Trace Viewer guide today.
Automate Apigee proxy testing locally
Catching errors early saves time and money. A new tutorial by Apigee customer engineer Tyler Ayers shows how to use the Apigee Local Emulator for automated testing. Learn to run tests locally, integrate them into CI/CD pipelines, and deploy on Google Cloud Run for shared sandboxes. This approach provides instant feedback and zero cloud costs, helping teams speed up deployment cycles.

Read the tutorial
Scale your enterprise multi-agent systems with Apigee
Deploying multi-agent architectures in production introduces critical hurdles around security, operational control, and runtime expenses. Discover how Apigee API Hub provides a central discovery surface to eliminate agent sprawl across tools, Model Context Protocol (MCP) servers, and enterprise APIs. Learn how to turn existing backend services into secure MCP tools using Agent Gateway guardrails, while applying semantic caching and intelligent model routing to keep compounding token costs predictable.

Join Google Cloud in Chicago in Oct.15 for The AI Evolution. Reserve your seat for Chicago

Automate Apigee proxy testing with the Apigee Local Emulator
Waiting on remote deployments to validate API proxy logic slows down release cycles and increases infrastructure overhead. Join Nigel Walters on Thursday, October 8, 2026, at 5:00 PM CEST for a Community TechTalk on shift-left testing for Apigee. Discover how to use the Apigee Local Emulator and apigee-emulator-service to run sub-second assertion suites on local machines, automate CI/CD checks in GitHub Actions, and deploy ephemeral preview sandboxes on Google Cloud Run.

Register for the October 8 Community TechTalk
Now in Public Preview: AI-assisted EKS-to-GKE migrations with deterministic guardrails
Migrating complex Kubernetes estates from AWS EKS to GKE is traditionally high-friction and error-prone. Now in Public Preview, GKE Agentic Migration is an open-source agent plugin that replaces ad-hoc LLM prompting with an AI-assisted migration workflow protected by deterministic guardrails.

Running locally in your development harness, it indexes source IaC, maps cloud-specific primitives (such as Karpenter to Custom Compute Classes), and validates configurations offline—delivering reviewable pull requests and data-migration runbooks with zero live cluster mutations.

Learn more in the announcement blog and try the plugin on GitHub.
Claude Opus 5.5 is now available on Google Cloud. Built for everyday complex tasks, it delivers stronger agentic coding, research, and analysis while handling long-running work at a lower cost per token. Google Cloud continues to provide enterprise customers with broad model choice to build, deploy, and scale their AI agents securely.

Try it here.
Import Delta Lake tables with Dataflow Job Builder!
Migrating to borderless Lakehouse just got a lot easier. You can now import Delta Lake tables stored in Cloud Storage using Dataflow Job Builder, a no-code/low-code interface for authoring Dataflow pipelines. Because Dataflow is a fully managed service, you are spared the overhead of provisioning and managing virtual machines. For step-by-step guidance, check out the documentation here.

Sept 14 - Sept 18

Storage Intelligence Advisor for Google Cloud Storage is now GA
Google Cloud Storage customers can now manage cloud storage more effectively with Storage Intelligence Advisor, delivering curated metrics, automated anomaly detection, and actionable recommendations right out of the box, with zero setup required.

Advisor baselines activity across your projects and automatically detects four key anomalies: surges in operations, unexpected rises in cross-region egress, and spikes in errors. Each finding includes deep drill-down visibility into the resources driving the change, alongside prescriptive steps to remediate issues before they impact performance or cost.

Learn more to get started with Storage Intelligence Advisor.
Build private WebSockets from Apigee X to Cloud Run
Real-time AI agents and streaming architectures often require persistent, bidirectional connections. A new implementation guide by Apigee Customer Engineer Joel Gauci demonstrates how to establish private southbound connectivity between Apigee X and Cloud Run. Using Private Service Connect (PSC) and a Regional Internal Application Load Balancer, teams can enforce API governance and security policies at the edge while keeping backend services completely isolated from the public internet.

Explore the step-by-step guide and open-source code
Connecting Gemini Enterprise Agent Runtime to Apigee with Private Service Connect
Deploying autonomous AI agents often presents security, compliance, and cost challenges. A new reference guide details how to build an end-to-end, private architecture between Gemini Enterprise Agent Runtime and Apigee. This design helps protect internal backends and manage token quotas.

Read the full community guide and deploy the code
Discover what’s new and next in Apigee
As enterprise architectures adapt to generative AI and autonomous workflows, Apigee is expanding its proven platform capabilities to support modern AI gateway use cases alongside traditional API management. Join our session on Thursday, September 24, featuring Apigee Product Manager Geir Sjurseth. Get an inside look at recent product releases, explore architectural patterns for securing models and agents, and bring your questions for the live Q&A.

Register for the September 24 Apigee product update
Managed Service for Apache Kafka supports clusters with public Internet access!
With Managed Kafka public clusters, you can now produce and consume messages from clients outside your VPC—including your local machine, for faster, frictionless testing. Public clusters unlock use cases like IoT devices, retail storefronts, and telco network towers. Enable public access on new or existing clusters via the Google Cloud console, gcloud CLI, or REST API. Spin up your first public cluster, or reach out to kafka-hotline@google.com with questions.
Stream data directly into Bigtable using Bigtable subscriptions, now in Preview!
You can write Pub/Sub messages to a Bigtable table with zero ETL with Bigtable subscriptions. No pipelines, no code, delivered by the serverless, zero-ops experience you already know with Pub/Sub. Power your AI workloads, from model telemetry to real-time context engineering, without the overhead of managing complicated ETL pipelines. Built to be dependable, with native support for dead-letter topics. Try the feature today!

Sept 7 - Sept 10

Why Your Voice Agent Needs Session Auditing
Moving voice agents to production demands robust quality monitoring. This guide dives deep into the inner workings of the Agent Development Kit (ADK) responsible for audio session auditing. Learn how the ADK's save_live_blob feature intercepts, buffers, and stores raw audio chunks during active Gemini Live sessions. We explore building an automated post-processing pipeline to seamlessly stitch these fragments into cohesive, playable audio files. Discover how to leverage these vital audio audit trails to monitor real-world interactions, diagnose failures, and ensure enterprise-grade reliability. Read the full guide here.
AlloyDB Omni Red Hat RPM Orchestrator now Generally Available
AlloyDB Omni Red Hat RPM orchestrator is now Generally Available. The AlloyDB Omni Red Hat RPM orchestrator offers a new way to manage PostgreSQL-compatible workloads on bare metal or VM platforms, combining the high performance of AlloyDB, access to generative AI features and Gemini models to build AI agents and applications, and full automation. The orchestrator simplifies cluster provisioning and lifecycle management by allowing you to define reference architecture specifications, customizable by adjusting instance parameters, node configurations, and networking options — discover all details in full blog post.

Aug 31 - Sept 4

Automate VM guest software lifecycle with VM Extension Manager, now GA
Google Cloud VM Extension Manager is now generally available, eliminating the need for custom startup scripts to manage guest OS extensions across Compute Engine fleets. Define declarative, project-wide policies that enforce desired software states across all regions and zones. Benefit from continuous drift detection with automatic self-healing, multi-zone phased rollouts with automated rollbacks on failure, and centralized fleet health visibility integrated with Cloud Monitoring.

Explore VM Extension Manager documentation
Assess Apigee migrations without a target environment
Planning a migration to Apigee X or Hybrid? You can now assess your legacy Apigee Edge SaaS or OPDK environment earlier in your planning cycle. Using the updated --skip-target-validation flag in the Apigee Migration Assessment Tool, teams can generate a full inventory and establish scope baselines before target infrastructure or IAM credentials are provisioned.

Read the guide to learn more.
Claude Fable 5.1 is now available on Agent Platform. It brings performance improvements over Fable 5 across reasoning, full-lifecycle coding, multi-tool workflows, and knowledge work.

Anthropic also announced Enterprise Frontier Safeguards, a solution that gives customers the option to safely deploy Anthropic’s most capable models while storing their data in cloud infrastructure they control.

We continue to offer enterprise customers options across frontier models to build, deploy, and scale securely on Google Cloud.

Aug 24 - Aug 28

Grok 4.6 is now available in Preview on Gemini Enterprise. xAI's most capable model, built for coding, agentic tasks, and knowledge work, Grok 4.6 joins Grok 4.3 and Grok 4.20 in Model Garden and becomes the flagship of the Grok family. It supports reasoning, function calling, and structured output for multi-step agentic workflows, and accepts text and image input.

Get started today
Empowering autonomous agents with advanced security governance
AI agents offer incredible productivity gains, but granting them access to read emails, query databases, and trigger APIs introduces critical new security risks. In fact, 79% of tech leaders cite security and governance as their biggest challenge to scaling AI. Traditional tools are no longer enough to handle automated threats like prompt injection and dynamic permissions. Discover how forward-thinking enterprises are using secure-by-default design, agent identity governance, and human-in-the-loop controls to deploy agents with confidence.

Read more
Stateful processing is available in BigQuery continuous queries in Preview
Stateful operations significantly expand what’s possible with BigQuery continuous queries. This feature allows users to leverage functions like JOINs, aggregations, and windowing functions directly in their streaming queries. Now you can calculate metrics over time (for example, a 30-minute average) to power your downstream applications and AI agents with much richer, real-time signals.
Try out our feature here and share your feedback with bq-continuous-queries-feedback@google.com!
Synthetic data generator tool is available for Managed Service for Kafka
You’ve launched your first Kafka cluster. Now what? The next thing to do is to produce some data to the cluster, but that involves modifying a client application somewhere or spinning up a virtual machine. The synthetic data generator tool, now generally available, can start sending mock data to your cluster in 3 clicks, and will get data streaming into your cluster in less than two minutes. The perfect utility for those moments you just want to test your cluster and new features. Try our quickstart today!
Dataflow pipeline updates are faster & more flexible
Dataflow pipeline updates can now stop-and-replace pipelines, a major addition to the existing in-place-update feature. The new parallel pipeline option accelerates the migration between the old & new pipeline, resulting in reduced disruption to your business. You can also set a timeout on drains that prevents runaway costs for your pipeliness in the event of stuck processing. This feature is generally available. Try it here!

Aug 17 - Aug 21

Webinar: Agent Identity as the backbone for secure AI innovation
An AI agent with a stolen API key looks identical to a legitimate one. As autonomous agents scale across enterprise systems, static credentials and legacy IAM policies can no longer keep up with machine-speed execution. Join Shaun Liu, Product Manager at Google Cloud, on August 27 at 1 PM ET to explore Google Cloud’s vision for unifying agent, human, and nonhuman identity into a workload-centric platform using verifiable cryptographic identities (SPIFFE, ID-JAG, OAuth).

Register for the webinar now

Aug 10 - Aug 14

Diagnosing Apigee Hybrid Cassandra Read Latency for Peak Performance
Diagnose real-time Cassandra read latency and resolve API key verification bottlenecks in Apigee Hybrid with this step-by-step troubleshooting guide. Learn how to deploy a debugging client and query performance tables to maintain sub-millisecond response times.

Read the Apigee Hybrid Cassandra Troubleshooting Guide
Keep moving with agents! The All Things Agentic Hackathon is officially live.
We're challenging builders to build next-generation agents that take on the busy work and handle the heavy lifting in the background using Gemini 3.5 and Google Cloud. Compete for your share of $190,000 in prizes, cash, and Google Cloud credits! Submissions are open from August 3, 2026, to August 31, 2026.

Learn more and register. Sign up for GEAR to get exclusive updates and your badge. #AllThingsAgenticHackathon
Accelerate PostgreSQL migrations using Gemini in Database Migration Service
Enterprise database migrations often stall during the "last mile" of translating legacy stored procedures, triggers, and custom functions from Oracle or SQL Server. Database Migration Service (DMS) now provides AI-assisted code conversion powered by Gemini in Databases. By combining deterministic compiler rules for 1:1 syntax with Gemini contextual synthesis for complex procedural blocks, DMS converts legacy code into native PostgreSQL and AlloyDB with full schema awareness and side-by-side validation.

Read the full blog post to learn how to streamline your database code conversion.
Compute Flex CUDs now available for G2 and G4 GPU VMs
Compute Flexible Committed Use Discounts (Flex CUDs) are now available for G2 (NVIDIA L4) and G4 (NVIDIA RTX Pro 6000) VMs. You can now lock in predictable savings while retaining the flexibility to adapt across VM families, migrate between regions, and combine general-purpose compute, GKE, Cloud Run, and G2 & G4 GPU VMs under a single spend commitment. Flex CUDs for G-series VMs let you lock in savings today while preserving the agility to upgrade to latest hardware without disruption!

Explore VM instance pricing or learn more about Flex CUDs.
Rapid Bucket accelerates the training and checkpoint performance in PyTorch Ecosystem via GCSFS
With the release of GCSFS 2026.8.0, organisations can now unlock maximum ROI from their AI/ML infrastructure by eliminating data starvation on GPUs in PyTorch ecosystem when they are using Frameworks like Dask, Pandas, PyTorch , PyTorch Lightning, Hugging Face Datasets, Ray dataetc. By making adaptive concurrent prefetching the default, GCSFS dynamically predicts and background-fetches sequential read patterns—boosting single-file throughput by 5x, and scaling up to 21 GiB/s , saturating the NIC when paired with Rapid Bucket. Saturating the NIC translates to significantly improved accelerator goodput and reduced training wait times with zero integration friction. Training and checkpoint restore workflows benefit from intelligent memory management that automatically drains the buffer during random reads to completely avoid bandwidth or memory penalties.

Aug 3 - Aug 7

Navigate data sovereignty and AI innovation with hybrid cloud
For enterprises facing strict compliance rules, keeping sensitive data on-premises often means missing out on cutting-edge AI. Data from the 2026 State of AI Infrastructure report reveals that 52% of IT leaders are adopting hybrid cloud strategies to bridge this gap. Our latest blog post explores how Google Distributed Cloud (GDC) helps organizations deploy connected or air-gapped models to run advanced AI entirely within secure environments—mitigating geopolitical risks without sacrificing innovation. Read more.
SAP and Google Cloud Launch BDC Connect for BigQuery
For years, enterprises have struggled with the cost, risk, and complexity of moving mission-critical SAP data into advanced analytics platforms. The general availability of SAP Business Data Cloud (BDC) Connect for BigQuery marks a turning point. By introducing revolutionary zero-copy, bi-directional data sharing, this new capability seamlessly bridges SAP systems with Google Cloud's powerful data and AI ecosystem. Instead of wrestling with manual data duplication and lost business context, organizations can now eliminate silos, dramatically lower their analytics costs, and rapidly deploy trustworthy, agentic AI solutions grounded in real-time operational reality. Read the full announcement to learn how to transform your data strategy.
Google Cloud Cortex Framework version 7 is now generally available!
This release helps you modernize your data architecture for AI agent readiness, enabling you to quickly deploy, customize, and extend robust data products while simplifying orchestration and reducing infrastructure overhead. It provides data product accelerators for SAP-sourced data to build trusted, high-quality data products ready for advanced analytics and agentic use cases. The Framework integrates with Google Cloud products including BigQuery, Dataform, Knowledge Catalog, and Gemini Enterprise Agent Platform. Learn more in our announcement blog, technical documentation, or try a demo deployment today.
From API Management to AI Gateway with Apigee
Massive LLM adoption unlocked automation but exposed critical vulnerabilities, from unpredictable token costs to security risks like prompt injection. Without central management, organizations face accelerated technical debt. Learn how to transform Apigee into an enterprise AI Gateway to centralize governance. This architectural roadmap details how to utilize semantic cache to optimize token costs, implement prompt protection policies for security, and productize tools using the emerging MCP standard.

Read the full architectural roadmap on the Apigee Community Hub
Centrally govern enterprise AI traffic with Apigee AI Gateway
Manage, track, and secure model communication across your entire infrastructure from a single pane of glass. In a new video walkthrough, Principal Architect Tyler Ayers demonstrates how Apigee AI Gateway simplifies agentic governance. Learn how to transparently proxy model traffic, log real-time token counts, and apply runtime security quotas without impacting your developer workflow.

Watch the Apigee AI Gateway demo
Maximize Provisioned Throughput Utilization
Sudden traffic micro-spikes can exceed per-second quotas, triggering 429 errors or forcing overflow into shared resource pools. A new architectural guide demonstrates how to build a serverless "shock absorber" using Cloud Run and Google Cloud Tasks. By decoupling request ingestion from execution, this queue-based pattern flattens volatile traffic bursts and smoothly drips requests to Gemini at your exact quota rate, maximizing Provisioned Throughput utilization while eliminating job failures during peak usage. Read the step-by-step setup guide.
Eliminate security blindspots in agentic tool interactions
Unmonitored agentic tool calls via the Model Context Protocol (MCP) can introduce critical security risks to your enterprise architecture. Join our technical deep dive on Thursday, August 13, to discover how to position Apigee as a centralized security gateway. Featuring the new ParsePayload policy and payload operations groups in API Products, this session demonstrates how to enforce granular tool filtering, manage execution quotas, and scale secure agent ecosystems without impeding developer velocity.

Register for the August 13 Community TechTalk

Jul 27 - Jul 31

Data Cloud and Apigee CDMX: The AI Agent Evolution | August 12, 2026
Enterprise AI demands evolution beyond basic conversational assistants. To generate real value, AI models must connect with the organization's core systems and live data sources. Join us this August 12 at Google CDMX for the exclusive event AI Evolution: Powering Tomorrow's Enterprise. Learn how to design an agile and secure ecosystem by unifying the power of Gemini, Apigee, and data agent technologies through practical demonstrations led by Google Cloud engineers.

Secure your spot for the in-person session in Mexico City Register now!
Vast Edge, built on GCP, launches the first live recovery interface for cloud backups, enabling IT teams to inspect backup contents in real time. This transforms backups from a blind, log-based process into an interactive platform where teams can instantly search, preview, and validate the exact data available for restore.

This platform protects Google Workspace, NetSuite, Salesforce, Workday and many SaaS environments, providing complete visibility and enterprise-grade oversight.

Visit Vast Edge Backup & Disaster Recovery and get a free trial of their backup solutions on the GCP Marketplace for Google Workspace Backup, NetSuite Backup, Salesforce Backup, and Workday Backup.

Jul 20 - Jul 24

Claude Opus 5, Anthropic’s latest model, is now available on Agent Platform. It brings performance improvements over Opus 4.8 across coding, long-running agents, and knowledge work.The model is Zero Data Retention (ZDR) compatible. For safety, high-risk workflows — such as penetration testing or exploit generation — it will notify you and fall back to Opus 4.8.We’re excited to continue to offer enterprise customers options across frontier models to build, deploy, and scale AI securely. Try it here.
Apigee Northam Roadshow 2026 | The AI Agent Evolution: Powering Tomorrow's Enterprise
AI is evolving. As your organization deploys autonomous agents, the integration between APIs and models becomes critical. Join Google Cloud specialists for an exclusive day of deep-dive sessions and live demos. Discover how the unified power of Apigee and the Google Cloud Agent Platform allows you to build, govern, and scale high-performance AI agents with complete control. Call to Action: Register for Sunnyvale | Register for NYC | Register for Chicago
Deploy an Apigee Proxy for MCP Registry Discovery
Learn how to deploy an Apigee X proxy to format Apigee API Hub data into the Model Context Protocol (MCP) Registry format. This tutorial by Tyler Ayers guides developers through cloning the sample repository, deploying using the Apigee Feature Templater (aft), and testing the endpoint to make API data easily discoverable by coding agents.

Read the full community tutorial to get started.
Simplify AI Infrastructure: Getting Started with Apigee AI Gateway
Managing a complex AI landscape with multiple backend environments can present significant operational and governance challenges. A new tutorial walks you through how to build a unified API proxy using Apigee AI Gateway. By establishing a single, secure entry point for all model traffic, teams gain access to real-time analytics, comprehensive tracing, and financial operations auditing—completely seamlessly, and with absolutely no modifications required to client environments or user configurations.

Read the step-by-step setup guide
Your AI agents are ready. Is your data?
The biggest bottleneck to scaling AI isn't the models—it's giving them access to business context. As enterprises move to proactive systems of action, legacy infrastructure often buckles under the nonlinear speed of AI agents. Google Cloud’s new Agentic Data Cloud, built on AI-native infrastructure, solves this by unifying data, AI models, and operational databases. Discover how a borderless Lakehouse and active Knowledge Catalog can empower your AI agents with trusted, real-time context without unnecessary engineering overhead. Read more.
Secure and govern your AI at Apigee AI Horizon in London
Moving AI from basic prompts to complex agentic workflows requires trust and control. Join us on Tuesday, 1st September 2026 at Google London for our 5th edition of Apigee AI Horizon. Discover how Google Cloud product leaders and architects are using Apigee and Model Armor to secure LLM APIs, implement policy controls, and manage token consumption. Do not miss this one—register soon!

Secure your spot for AI Horizon London

Jul 13 - Jul 17

Resource-Based CUD Sharing is Now Enabled by Default
Starting June 16, 2026, the default setting for Google Cloud Resource-based Committed Use Discount (CUD) sharing will change from disabled to enabled for new billing accounts and eligible existing accounts without active CUDs. This update automatically maximizes your savings by pooling underutilized discounts across your resources.

You retain full control and can adjust your CUD sharing preferences at any time by changing your CUD scope configuration. For instructions, see Enable CUD sharing or Disable CUD sharing.
Webinar for India: Google Cloud for EdTech: Optimizing Traffic and Token Governance at Scale
API traffic surges and AI model integration are reshaping the EdTech landscape. Join Satyam Maloo for the webinar Google Cloud for EdTech: Optimizing Traffic and Token Governance at Scale on July 23, 2026. Learn to implement advanced rate limiting, gain granular token visibility, and leverage real-time analytics to govern your platform effectively. Whether you’re scaling for peak academic seasons or integrating complex AI workflows, this session provides the infrastructure blueprint you need.

Register Now
Scaling AI Agents: Treat prompts like software artifacts
As AI agents move into production, monolithic system prompts often result in configuration drift, merge conflicts, and silent runtime failures. The solution is adopting a Prompts-as-Code architecture. By breaking prompts into modular skill files and using a build-time transpiler, engineering teams can introduce dependency resolution, static validation, and CI/CD rigor to their agent's control plane. Stop manually editing massive text files and start building deterministic, reliable agent infrastructure.

Read more here.

Jul 6 - Jul 10

Webinar: Introducing Google Cloud NGFW Enterprise advanced malware protection - powered by Palo Alto Networks
Discover the new Cloud NGFW advanced malware sandbox, arriving in preview later this year. Powered by Palo Alto Networks Advanced Wildfire, it leverages data from 70,000+ customers to help defeat advanced malware. Join us on July 16 at 11 AM EDT to learn how to build a resilient, zero-trust cloud infrastructure that protects your apps and data, wherever they reside.

Register for the webinar now
Safely run AI-generated code in Cloud Run sandboxes
Cloud Run sandboxes, now in public preview, are lightweight, isolated execution boundaries that you can spawn near-instantly within your existing Cloud Run service instances.

Whether you need to let an LLM run a dynamically generated Python script to calculate business margins or spin up a headless browser to perform web research, Cloud Run sandboxes give you a secure, isolated sandbox to run these tasks without leaving your serverless environment.

Read the blog to learn more and get started today.
Australia API Horizon: Scaling Enterprise Governed AI Agents
The transition from AI chatbots to autonomous agents is the most critical integration point for your business. Join Google Cloud at our upcoming events to explore exclusive deep-dive sessions on architecting for the agentic era.

Discover how to use Apigee as an intelligent AI Gateway to govern, secure, and scale high-performance architectures. You will learn to seamlessly build AI tools from your existing APIs and maintain control over your entire ecosystem.

Join us in your preferred city:
Build highly available, multi-region services on Cloud Run
Maintaining uptime for business-critical applications just got a lot easier on Cloud Run. Service health, now Generally Available, automates cross-region failover by leveraging readiness probes for instance-level health checks with a simple, two-click setup. You can configure service health with global external Application Load Balancers for public-facing applications or cross-region internal Application Load Balancers for private networking traffic.

Learn how to configure service health for Cloud Run.
Report: 83% of organizations need infrastructure upgrades for agentic AI
The shift from conversational bots to autonomous agents is breaking legacy systems. Our new State of AI Infrastructure report details how engineering leaders are adapting to these massive new workloads. To eliminate inference bottlenecks, control hidden scaling costs, and manage agent sprawl, the industry is rapidly moving toward fluid compute, centralized governance, and unified, co-designed architectures.

Explore our key infrastructure insights
Stop tinkering, start scaling: the industrialized AI Playbook
Did you know that only 5% of custom AI investments actually return measurable business value? The problem isn’t the technology—it’s how organizations are wired to run it.

In this compelling read, Google Cloud Consulting breaks down the operational blueprint that bridges the stark gap between "cool tech experiments" and real, P&L-impacting enterprise ROI.

Read the full article on Medium
AI Agent Clinic: Slashing App Latency by 80%
Prototyping an AI agent is easy, but scaling for live traffic presents unique challenges. In the latest AI Agent Clinic, our technical experts partner with a developer to optimize PlaybackIQ, a live football analysis agent. This session demonstrates how to use OpenTelemetry to trace bottlenecks in the Gemini Enterprise Agent Platform and deploy to Cloud Run for high-concurrency scaling, achieving an 80% reduction in response time. Learn production-grade debugging strategies to optimize your own LLM applications.

Watch the 60-minute teardown

Jun 29 - Jul 3

Claude Sonnet 5, Anthropic’s latest model, is now available on Agent Platform.
This addition serves as a drop-in replacement for Sonnet 4.6, giving organizations expanded choice for task completion across enterprise workflows. It features enhanced reasoning, cleaner code generation, and computer use capabilities for desktop and browser workflows.

By continuing to rapidly bring frontier models to our platform, Google Cloud offers an uncompromised choice of the industry's best technology to build, test, and scale enterprise-grade AI.

Get started today.
Automate your AI governance with Apigee and YAML
Manual API gateway configurations can quickly slow down your AI engineering velocity. Join the Apigee community on Thursday, July 16, to discover an automated, declarative blueprint for model garden management. Learn how a simple, repeatable YAML pattern lets your AI practitioners instantly spin up secure, policy-backed enterprise configurations without friction. Bring your questions and connect during our live Q&A session.

Register for the July 16 Community TechTalk
Build next-generation AI portals for autonomous agents
Standard developer portals were designed for human developers to subscribe to static APIs. Today, autonomous agents, LLM toolkits, and dynamic runtimes demand a central nervous system for governance. Join our technical deep dive on Thursday, July 23, to explore Apigee's new AI Portals solution. You will see exactly how to deploy full-service, MCP powered hubs to safely manage enterprise self-service for models, tools, and agents.

Register for the July 23 Community TechTalk
Protect your infrastructure from advanced cyberattacks at the API layer (Presented in Portuguese)
In an era of increasingly sophisticated threats, relying solely on traditional firewalls leaves critical data gaps. Join our technical community TechTalk on Thursday, July 30—conducted in Portuguese—to learn how to proactively mitigate risks directly at the gateway layer. This session demonstrates how to configure and govern essential Apigee security policies to build a robust line of defense, ensuring maximum availability and complete integrity for your enterprise microservices.

Register for the July 30 Portuguese Community TechTalk

Jun 22 - Jun 26

Accelerate TPU model loading while saving RAM on GKE.
Large model cold starts often stall scaling and leave high-value TPUs idle. The open-source Run:ai Model Streamer now natively supports TPUs with Google Cloud Storage in TPU vLLM 0.18.0. This integration accelerates inference pipelines on GKE by streaming tensors directly into CPU memory, bypassing local disk bottlenecks and the "double-buffering" trap. In benchmarks, loading a 480B parameter model was over 2x faster while cutting peak host memory usage by half. Read the full guide and get started today.
Stop Training Blind: Scaling AI with the New OpenTelemetry-Based TPU AI Telemetry Collector Agent
Google Cloud’s new AI Telemetry Collector agent standardizes TPU monitoring using OpenTelemetry. It optimizes enterprise ML workloads by identifying silent failures and providing zero-cost operational metrics without draining host CPU cycles. The agent seamlessly routes telemetry to Google Cloud Monitoring or Prometheus and custom Grafana setups. Pre-installed on Google-optimized Ubuntu images or available via Docker, it tracks memory, network latency, and core utilization to maximize multi-node training efficiency.

You can read more of this capability by clicking this link.

Jun 15 - Jun 19

Join us for a deep dive into agentic AI control with AppyThings
Your integrations aren’t failing—they are evolving. When users interact with AI agents, they no longer arrive directly at your site, resulting in experiences stripped of your context, expertise, and intended experience. Join us on Thursday, June 25, for a community tech talk in partnership with AppyThings to learn how to solve this new gateway challenge. We will explore how MTN laid an integration foundation with the Model Context Protocol (MCP) to deliver accurate, consistent experiences. Our technical experts will demonstrate how to leverage Apigee as a centralized tools management solution to govern agent access.

Register for the session
Optimize Spot VM Deployments with Capacity Advisor for Spot, Now in Public Preview
Google Compute Engine has launched Capacity Advisor for Spot to Public Preview, now open to all customers. This tool turns Spot capacity discovery into a data-driven process by providing real-time deployment recommendations to maximize obtainability and minimize preemption risks. Query the Capacity Advisor API for obtainability and minimum estimated uptimes, or use the new Console UI featuring a global availability map, spot price lookups, and historical preemption rate trends to visually find the most cost-efficient compute capacity.

Get started today to start optimizing your Spot VM deployments!
Build a multi-tenant agentic AI system
When scaling generative AI across different business units, your teams need specialized AI agents with unique operational rules and tools. Our new reference architecture helps you build a centralized multi-tenant platform to prevent fragmented silos, eliminate data exposure risks, and maintain unified compliance. Read the guide to design and deploy a multi-tenant agentic AI system in Google Cloud.
How to Configure Gemini Enterprise to Connect to a Custom MCP Server
The Gemini Enterprise MCP Connector was a big announcement at Google Cloud Next because it introduces the ability to connect Gemini Enterprise to MCP servers. This blog post provides a step-by-step guide on how to configure your first Custom MCP Server connector using the Google Maps Ground Lite MCP server as an example. Once you understand this flow, you can configure multiple MCP servers with Gemini Enterprise to bring all the context you need.

Jun 8 - Jun 12

Simplify Multi-Cloud Planning with Cloud Location Finder, now Generally Available
Cloud Location Finder provides up-to-date data on public regions, zones, and Google Distributed Cloud Connected locations across Google Cloud, AWS, Azure, and OCI. You can now programmatically discover locations based on provider, proximity, territory, and carbon footprint to optimize your global infrastructure strategy for performance, compliance, and sustainability.

Get started for free today

Jun 1 - Jun 5

Modeling the physical world with BigQuery Graph
Managing complex supply chains requires more than just spreadsheets; it requires a digital replica of the physical world. In this post, Guru Rangavittal and Candice Chen explore how BigQuery Graph enables organizations to build a digital twin by turning physical assets into an interconnected map of nodes and edges. By moving beyond traditional relational databases, businesses gain real-time clarity into operations—from executing surgical ingredient recalls to analyzing weather-driven logistics risks. Discover how BigQuery Graph transforms reactive firefighting into proactive, precision modeling, allowing you to see critical connections in seconds and future-proof your supply chain.
Apigee for AI: Govern LLMs and MCP Servers (Presented in Spanish)
Learn how to securely transition your AI initiatives from experimental prototypes to enterprise-ready deployments. Join Luis Cuellar on June 18 for a technical deep dive (presented in Spanish) exploring Apigee’s latest AI gateway capabilities. Discover how to centralize governance over Model Context Protocol (MCP) servers, protect Large Language Models (LLMs) with robust API gateway security policies, and manage token-based quotas.

Register for the June 18 Spanish Community TechTalk

May 25 - May 29

Anthropic’s Claude Opus 4.8 is now available on Gemini Enterprise Agent Platform. As we continue to expand our platform's model offerings, this addition gives organizations more options for handling complex, multi-stage enterprise workflows. Claude Opus 4.8 brings strong capabilities in agentic coding, allowing developers to manage extensive refactors and tracking dependencies over extended sessions.
API Horizon Munich July 6, 2026: Orchestrating the Next Era of AI and APIs
Master the orchestration of next-gen AI and digital ecosystems. Join Google Cloud experts and DACH tech leaders on July 6 for an exclusive look at the Apigee roadmap, Agent Management, and Model Context Protocol (MCP). Gain real-world insights and connect with the regional integration community.

Register now
Securing AI Agents: The Extended Agent Gateway Pattern
Learn how to prevent autonomous AI agents from invoking unauthorized APIs. Join Apigee Specialist Joel Gauci on June 4 for a technical deep dive into the Extended Agent Gateway pattern. This session covers enforcing Fine-Grained Authorization (FGA), implementing secure token exchange, and establishing Model Context Protocol (MCP) governance at the API gateway layer to protect enterprise backend services.

Register for the June 4 Community TechTalk
API-to-Agent Security: Exposing REST APIs to Gemini Enterprise via MCP
Connect Gemini Enterprise agents to core data without creating security hazards. Join Google Cloud Specialist Nigel Walters on June 11 to learn how to instantly transform legacy REST APIs into secure Model Context Protocol (MCP) servers. We’ll cover how to safely register tools with Gemini while enforcing gateway-level guardrails like rate limiting and access control policies.

Register for the June 11 Community TechTalk

May 18 - May 22

Chinese Webinar | June 4: AI Command and Control
As AI agents move from experimental pilots to core enterprise functions, governance has become a critical next step. Join Google Cloud on June 4th at 10:00 AM (Beijing Time) to learn how to build a secure AI management layer architecture. We'll explore how to develop governed MCP (Model Context Protocol) endpoints, manage tool access to enterprise data, and leverage robust audit logs to operationalize AI. This session also includes a practical demonstration of these governance frameworks on Google Cloud.

Register here
GCP Announces New Features to Benchmark and Optimize LLMs for On-Device Use Cases
Deploying fine-tuned LLMs from GCP to edge devices like smartphones is complex due to fragmented hardware. Google AI Edge Portal bridges this gap, giving GCP developers the ability to test AI performance on 120+ Android devices, representing the full diversity of high, medium, and low tier smartphones on the market today. This week at I/O, we announced brand new capabilities to benchmark and debug LLM performance across these devices. Sign-up to utilize these new features in private preview today.

May 11 - May 15

Build Your AI & MCP Control Tower for Universal Governance
Master the future of agentic security with Apigee. Join our Community TechTalk on May 21 to discover how Apigee serves as a central "Control Tower" for the Model Context Protocol (MCP). We will explore how new JSON-RPC tool authorization enables fine-grained access policies across your organization, ensuring secure and scalable AI deployments. Whether managing internal tools or external users, learn to govern your agentic ecosystem with absolute precision. This session is designed for global coverage across EMEA and AMER regions.

Register for the May 21 Community TechTalk

Apr 27 - May 1

Master Your Launch: The Apigee Production Go-Live Checklist
Ensure a secure launch with the Apigee production guide. Join Nicola Cardace on May 28 to explore security guardrails, including IAM roles, mTLS configurations, and encrypted KVM migrations. Scheduled at 11 AM EDT / 5 PM CEST to support EMEA and AMER teams, this TechTalk provides the technical roadmap you need to flip the switch with absolute confidence.

Register for the May 28 Community TechTalk
Transforming APIs into Governed Agentic Tools on the Google Cloud Agentic Platform
Turn your APIs into secure, governed agentic tools on the Google Cloud Agentic Platform. Join Specialist Christophe Lalevée on May 7 for a technical deep dive into AI productization. Scheduled at 5 PM CEST / 11 AM EDT to maximize coverage for developers across EMEA and AMER, this session explores the integration and governance frameworks required to scale enterprise-ready AI with confidence.

Register for the May 7 Community TechTalk
Fractional G4 VMs are Generaly Available, providing a highly efficient and cost-effective entry point for AI and graphics workloads. These new configurations, using NVIDIA virtual GPU (vGPU) technology, allow you to leverage the power of the NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs in flexible, smaller increments, so you can right-size your infrastructure to match the specific demands of your applications. By providing more granular access to advanced hardware, fractional G4 VMs let you optimize resource allocation and reduce overhead without sacrificing performance. You can now select from additional GPU slice sizes for your specific needs:
- 1/2 GPU: Ideal for more intensive tasks such as LLM inference, robotics sensor simulation, and high-fidelity 3D rendering.
- 1/4 GPU: Optimized for mainstream workloads, including mid-range creative design, video transcoding, and real-time data visualization.
- 1/8 GPU: Great for lightweight applications such as remote desktops, productivity tools, and entry-level streaming services.
Transitioning AI from a sandbox prototype to an enterprise-grade system is a major hurdle. A monolithic script won't suffice for widespread deployment. To achieve true scale and reliability with Gemini, organizations must adopt service-oriented micro-agent architectures, establish Zero-Trust security, and implement rigorous EvalOps. Master the "Agentic Maturity Ladder" to ensure your AI & Agentic solutions are robust, secure, and ready for the real world.

Watch the deep dive and read the developer blog to learn more.
ML Development in VS Code with Google Cloud Power: Workbench Extension Now Available
Data scientists and developers can now combine the local productivity of VS Code with the scalable infrastructure of Google Cloud. The new Google Cloud Workbench Notebooks extension allows you to connect to and run notebooks on managed cloud environments directly within your local IDE. This integration streamlines the ML lifecycle by eliminating context switching and providing high-performance compute for complex workloads in a familiar interface. As part of our commitment to the developer ecosystem, the extension is fully open-sourced to support community-driven innovation.
- Install from Marketplace: GoogleCloudTools.workbench-notebooks
- Contribute on GitHub: colab-enterprise-vscode

Apr 20 - Apr 24

Announcing the 2026 Google Cloud Partners of the Year
Google Cloud is honored to celebrate the winners of the 2026 Partner of the Year awards! These awards recognize an exceptional group of partners across AI, Security, Infrastructure, and more, who have demonstrated a commitment to customer success. From global system integrators to specialized startups, these winners are leveraging the power of Google Cloud to solve complex challenges and drive digital transformation worldwide. Join us in congratulating these organizations for their innovation, collaboration, and impactful results over the past year.

See the 2026 Partner Award winners

Apr 13 - Apr 17

We're excited to announce the Public Preview of Datastream’s metadata integration with Knowledge Catalog. This is the first step in our vision to provide a centralized, "single pane of glass" for all Datastream assets. The enhancement automatically synchronizes Streams, Connection Profiles, and Private Connections, eliminating data silos. It enhances discoverability, allowing you to search for Datastream assets using the same interface as BigQuery tables. Centralized governance is also provided, making your real-time data estate more transparent and easier to manage.
Upgrading Apigee OPDK to 4.53 with OS Modernization
Modernize your infrastructure using Google’s official, sequential upgrade path. Our Technical expert, Rakesh Talanki outlines how to upgrade Apigee OPDK to v4.53 while migrating to a supported OS (RHEL 8.x/9.x). This guide covers the "build-out" methodology, including multi-data center syncing, to ensure a stable, zero-downtime transition

Read the guide
Cloud Run Worker Pools and CREMA: Powering Serverless AI at Scale
Google Cloud has announced the General Availability of Cloud Run worker pools, a new resource type designed specifically for pull-based, non-HTTP workloads. Unlike traditional Cloud Run services that scale based on request traffic, worker pools provide an "always-on" environment for background tasks like processing message queues or running large-scale AI inference. To support this, Google Cloud also open-sourced the Cloud Run External Metrics Autoscaler (CREMA). Built on KEDA, CREMA enables queue-aware autoscaling for worker pools, allowing them to dynamically scale based on external signals like Pub/Sub backlog or Kafka lag.
Apigee Model Context Protocol (MCP) now Generally Available
Expose enterprise APIs as MCP tools for agentic AI applications with the General Availability of MCP in Apigee. This update allows developers to transform APIs into AI-ready tools using OpenAPI Specifications, removing the need for local MCP servers or additional infrastructure. With managed endpoints and semantic search in API hub, you can now provide AI agents with secure, governed access to enterprise data at scale.

Explore the MCP overview

Apr 6 - Apr 10

Community TechTalk: Powering Retail Agents with ADK, UCP & Apigee X
Move beyond basic chatbots to secure, transactional AI experiences. Join our Community TechTalk on April 16 to learn how Apigee X and Gemini build a "Trust Layer" for AI shopping assistants using UCP standards. We’ll demonstrate how to block prompt injections with Model Armor and implement cost governance via token limits to secure the path from discovery to purchase.

Register for the TechTalk
Implement multimodal capabilities in your AI agents
Explore three new reference architectures for building sophisticated multi-agent AI systems that can process and analyze multimodal data. To analyze disparate multimodal data and produce a high-confidence classification, see Classify multimodal data. To create a fluid conversational AI that processes audio and video streams in real time, see Enable live bidirectional multimodal streaming. To consolidate fragmented multimodal data into a searchable knowledge graph, see Multimodal GraphRAG resource orchestration.
Automate SecOps workflows with an agentic AI system
To accelerate incident response and reduce manual toil for your security team, you need a system that can automate remediation playbooks. Our new reference architecture helps you build an AI agent that orchestrates complex triage and investigation workflows across disparate security tools, such as SIEM, CSPM, and EDR, from a single interface. See the full guide to orchestrate security operations workflows.

Mar 30 - Apr 3

ASEAN Webinar | April 30: Mastering Agentic Governance at Scale with GCP
As AI agents move from experimental pilots to core enterprise functions, governance is the critical next step. Join Google Cloud experts Shilpi Puri & Wely Lau for a webinar on April 30th at 11:00 AM SGT to learn how to architect a secure AI Management layer. We’ll explore developing governed MCP endpoints, managing tool access to enterprise data, and operationalizing AI with robust audit logs. The session includes a live demo of these frameworks in action on Google Cloud.

RSVP here.

Mar 23 - Mar 27

Turn your API sprawl into an agent-ready catalog
As organizations scale, APIs often become scattered across multiple gateways, creating "blind spots" that hinder AI adoption. To solve this, we’ve introduced two new capabilities for Apigee API hub: a new integration with API Gateway to automatically centralize API metadata into a single control plane, and a specification boost add-on (now in public preview). This add-on uses AI to enhance your API documentation with the precise examples and error codes that AI agents need to function reliably.

Read the full blog post to get started.
Webinar | April 16: AI Command & Control
As AI agents move from experimental pilots to core enterprise functions, governance is the critical next step. Join Google Cloud expert Satyam Maloo for a webinar on April 16th at 11:00 AM IST to learn how to architect a secure AI Management layer. We’ll explore developing governed MCP endpoints, managing tool access to enterprise data, and operationalizing AI with robust audit logs. The session includes a live demo of these frameworks in action on Google Cloud.

RSVP here.
Modernizing and Decoupling Event Ingestion with Apigee
In modern cloud-native architectures, decoupling producers from consumers is critical for building resilient systems. While Google Cloud Pub/Sub provides a scalable backbone, exposing it directly to external clients can introduce security and management overhead. This new guide explores how to leverage Apigee as an intelligent HTTP ingestion point. Learn how to handle security, mediation, and traffic control before messages reach your internal bus using the PublishMessage policy or Pub/Sub API.

Read the full guide.

Mar 16 - Mar 20

Gemini-powered Assistant in BigQuery Studio Gets Context-Aware Upgrades
The Gemini-powered assistant in BigQuery Studio has been transformed into a fully context-aware analytics partner, supporting your entire data lifecycle. The new capabilities include intelligent resource discovery, which uses Dataplex Universal Catalog search to find resources across projects and deep dive into metadata using natural language. You can now automate tasks, such as scheduling production-grade queries directly through the chat interface, and instantly troubleshoot long-running or failed jobs with root cause analysis and cost control auditing.

Explore the full range of what the assistant can do.

Mar 9 - Mar 13

Want to use Gemini to develop code and don't know where to start?
This article includes a couple of examples of developing code with Gemini prompts; it identified changes that were needed to be made to get the code working. The article also refers to other examples that are available on github.

Mar 2 - Mar 6

Introducing Gemini 3.1 Flash-Lite, our fastest and most cost-efficient Gemini 3 series model. Built for high-volume developer workloads at scale, 3.1 Flash-Lite delivers high quality for its price and model tier. Gemini 3.1 Flash-Lite can tackle tasks at scale, like high-volume translation and content moderation, where cost is a priority. And it can also handle more complex workloads where more in-depth reasoning is needed, like generating user interfaces and dashboards, creating simulations or following instructions.

Starting today, 3.1 Flash-Lite is rolling out in preview to enterprises via Vertex AI and developers via the Gemini API in Google AI Studio.
TechTalk: Implementing Device Authorization Grant (RFC 8628) for Apigee
Learn how to authorize "headless" devices like Smart TVs or AI agents that lack keyboards and browsers. Join our Community TechTalk on March 19 (5PM CET / 12PM EDT) to go under the hood of Apigee X/Hybrid. We’ll cover the real-world mechanics of state management, polling, and human-in-the-loop security patterns for devices and autonomous agents.

Register for the TechTalk

Feb 23 - Feb 27

Pro-level image generation gets faster and more accessible with Nano Banana 2
Nano Banana 2 is our state-of-the-art image generation and editing model. It delivers Pro-level image generation and editing at the speed you expect from Flash — making the quality, reasoning, and world knowledge you loved about Nano Banana Pro more accessible. Learn more about the model here.

The Intelligent Path to Compliance: Transforming Regulatory QC with Google Cloud
Reducing "Refuse to File" (RTF) risks and submission cycle times is critical for life sciences leaders. Google Cloud’s Regulatory Submission Semantic QC Auditor leverages Gemini and RAG architecture to transform Quality Control from a manual burden into an active, intelligent workflow.

By automating semantic cross-referencing, narrative coherence checks, and dynamic guidance-based auditing, this solution ensures rigorous accuracy and auditability. Operating within a secure GxP-ready environment, it empowers teams to detect subtle inconsistencies and generate remediation plans without sacrificing data privacy.

Learn more.
Stop typing, start interacting! The Gemini Live Agent Challenge is here. Build immersive agents that can help you see, hear, and speak using Gemini and Google Cloud. Compete for your share of $80,000+ in prizes and a trip to Google Cloud Next '26!

Submissions are open from February 16, 2026 to March 16, 2026. Learn more and register at geminiliveagentchallenge.devpost.com

Feb 9 - Feb 13

Introducing Gemini 3.1 Pro on Google Cloud.
3.1 Pro is a noticeably smarter, more capable baseline for complex problem-solving. We’re shipping 3.1 Pro at scale, building upon our goal to help you transform your business for the agentic future. Learn more about the model’s capabilities here. Gemini 3.1 Pro is available starting today in preview in Vertex AI and Gemini Enterprise. Developers can access the model in preview via the Gemini API in Google AI Studio, Android Studio, Google Antigravity, and Gemini CLI.
Automate Storage Compatibility with GKE Dynamic Default Storage Classes
Managing storage across mixed-generation VM clusters in GKE just got easier. With the new Dynamic Default Storage Class, Google Kubernetes Engine automatically selects between Persistent Disk (PD) and Hyperdisk based on a node's specific hardware compatibility. This abstraction eliminates the need for complex scheduling rules and manual pairing, ensuring your volumes "just work" regardless of the underlying infrastructure. By defining both variants in a single class, you reduce operational overhead while maintaining peak performance and cost-efficiency across your entire cluster.

Explore automated disk type selection
Community TechTalk: AI-Powered Apigee Development with strofa.io
Join the Apigee community on February 26 for a deep dive into strofa.io. Guest speaker Denis Kalitviansky will demonstrate how this new AI-powered tool automates and orchestrates Apigee development, from local emulators to large-scale hybrid environments. Discover how to scale your API management and streamline team collaboration using the latest in AI-driven automation.

Register now to reserve your spot.

Jan 26 - Jan 30

Simplify API Governance with Native OpenAPI v3 Support
Eliminate integration debt and accelerate deployment velocity with the General Availability of OpenAPI v3 (OASv3) support for API Gateway and Cloud Endpoints. You no longer need to downgrade modern specifications to OASv2. Instead, you can now define API contracts and enforce critical policies—including telemetry, quotas, and security—using native Google-specific extensions directly within your OASv3 files. This update ensures your APIs are secure by design while remaining fully compatible with the modern developer ecosystem and Google Cloud’s AI services.

Get started with OpenAPI v3 on API Gateway and Cloud Endpoints.

Accelerate API Testing with the New Open Source API Tester
Start validating your APIs with API Tester, a simple, YAML-based Test Driven Development (TDD) framework. Designed for the Apigee community, this tool allows you to write human-readable tests, run them instantly via a web client or CLI, and perform deep unit testing on Apigee proxies. With native support for JSONPath assertions and Apigee shared flows, you can verify everything from payload data to internal variables like proxy.basepath without leaving your terminal.

Explore the API Tester guide and start testing your proxies today.
Secure Sensitive Data with Kubernetes Secrets in Apigee hybrid
Enhance security in Apigee hybrid by accessing Kubernetes Secrets directly within your API proxies. This hybrid-exclusive feature keeps sensitive credentials within your cluster boundary and prevents replication to the management plane. It supports strict separation of duties: operators manage secrets via kubectl, while developers reference them as secure flow variables—ideal for high-compliance and GitOps workflows.

Implement Kubernetes Secrets in your hybrid proxies.
See the Console in a Whole New Light: Dark Mode is Now Generally Available in Google Cloud
Elevate your cloud management workflow with Dark Mode, now generally available in the Google Cloud console. We have delivered a modern, cohesive, and accessible experience reimagined for maximum comfort and productivity—especially during extended working hours and low-light environments. Dark Mode can be enabled automatically based on your operating system's preference, or manually through the Settings -> Appearance menu.

Switch to Dark Mode today to enjoy a modern, comfortable, and productive environment!
Apigee X Networking: PSC or VPC Peering?
Deciding how to connect Apigee X? Watch this video to compare Private Service Connect and VPC Peering. We break down northbound and southbound routing, IP consumption, and how to reach targets on-prem or in the cloud. Learn to simplify your architecture and avoid common networking "gotchas" for a smoother deployment.

Watch the video.

Jan 19 - Jan 23

Bridge the Gap: Excel-to-API Conversion in Apigee Portals
Give your customers more ways to connect! This new article by Tyler Ayers explores how to extend the Apigee Integrated Portal to support direct Excel file uploads. By leveraging SheetJS and custom portal scripts, you can enable users to upload spreadsheets, preview data, and submit it directly to your APIs, all without writing a single line of integration code themselves. It’s a powerful way to simplify onboarding for those who aren't yet API-ready.

Learn how to build it.
Elevate your applications with Firestore’s new advanced query engine
We have fundamentally reimagined Firestore with pipeline operations for Enterprise edition. Experience a powerful new engine featuring over a hundred new query features, index-less queries, new index types, and observability tooling to improve query performance. Seamlessly migrate using built-in tools and leverage Firestore’s existing differentiated serverless foundation, virtually unlimited scale, and industry-leading SLA. Join a community of 600K developers to craft expressive applications that maximize the benefits of rich queryability, real-time listen queries, robust offline caching, and cutting-edge AI-assistive coding integrations.

Learn more about Firestore pipeline operations.

New Gemini courses for financial services and legal teams

Fri, 30 Oct 2026 13:00:00 +0000

Today Google Skills is sharing new, industry-specific video learning bundles to get you into Gemini and using agents. One bundle is designed for financial services and one is built specifically for those in the legal profession. You can access all of these videos at no cost on Google Skills today.

Whether you're managing complex market portfolios or navigating rigorous compliance reviews, these bite-sized video courses show you exactly how to work smarter with agentic AI. They start with use cases you’re probably familiar with, and share how you can jump into Gemini to get work done more efficiently.

Turn market complexity into clarity with Gemini for financial services

Financial analysts and portfolio managers deal with massive volumes of real-time market data, fluctuating risk profiles, and tight turnarounds. Let’s say you’re a financial advisor preparing for your first session with a client. You’ve got a meeting with a new client in 20 minutes. Reading hundreds of SEC pages manually isn’t possible. But, doing it in two minutes with Gemini for financial services makes it easy. Get a sense of three ways you can start using Gemini in this video, or jump into learning with the full course list below below.

We've launched four practical video courses to help your financial services team start transforming workflows immediately. You can see them all today on Google Skills:

Streamline compliance and drafting with Gemini for legal

In legal operations, precision is everything. Let’s say you’re staring at a proverbial pile of documents that need review. Instead of having to check terms line by line, you can use Gemini to build compliance standards and review agreements against them. Gemini then flags violations, explains why they go against standards, and suggests a remedy. And that’s just one way you can jump into higher efficiency with Gemini for legal. See three more ways to start using it today:

Get started with five new bite-size courses built to elevate your day-to-day legal workflows or explore all the Gemini for legal content on Google Skills:

Take your skills further with Gemini Agent Ready (GEAR)

Is this all feeling a little too introductory for you or your business? We get it. Maybe you’re ready to jump from introductory workflows to building production-grade agentic systems.

Through our no-cost Gemini Agent Ready program you can earn industry-recognized skill badges and validate your real-world expertise. When you register for GEAR today, you’ll receive 35 credits to explore interactive training environments on Google Skills — giving your team a risk-free space to build, test, and master agentic AI.

Get started with GEAR today

Cloud CISO Perspectives: Introducing new $250,000 tier for Google Cloud VRP (Q&A)

Thu, 29 Oct 2026 16:00:00 +0000

Welcome to the second Cloud CISO Perspectives for October 2026. Today, Chris Betz talks with Michael Cote, our vulnerability rewards program lead, about the new tier of our Cloud VRP program and the current state of vulnerability rewards.

As with all Cloud CISO Perspectives, the contents of this newsletter are posted to the Google Cloud blog. If you’re reading this on the website and you’d like to receive the email version, you can subscribe here.

aside_block: <ListValue: [StructValue([('title', 'Get vital board insights with Google Cloud'), ('body', <wagtail.rich_text.RichText object at 0x7fdf5f8ef050>), ('btn_text', 'Visit the hub'), ('href', 'https://cloud.google.com/solutions/security/board-of-directors?utm_source=cgc-site&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GCP39634-email-dl-dgcsm-CISOP-NL-177159&utm_content=-&utm_term=-'), ('image', None)])]>

Why we've created a new $250,000 tier for Google Cloud VRP (Q&A)

By Chris Betz, CISO, Google Cloud

The Google Cloud Vulnerability Reward Program (VRP) partners with the global security research community to help elevate cloud security for all by encouraging the discovery of critical software vulnerabilities. In an era when automated research has made it more challenging to verify authentic vulnerabilities, we have a critical need to boost high-level, human-led research that can transcend automated-only discovery.

Today, we are expanding our top reward tier with a new $250,000 Root-in-Cloud reward, specifically designed to recognize high-impact architectural research. Identifying tenant-isolation bypasses and complex cross-service logic flaws requires human creativity, intuition, and rigorous systems analysis combined with the power of agentic systems.

To earn this premier reward, you must demonstrate full administrative control, the equivalent of “roles/owner” or complete IAM control, over arbitrary Google Cloud organizations or projects with no prior access or special project setup.

The exploit path can not depend on:

Pre-existing access or footholds in the victim project.
Leaked, phished, or stolen credentials.
User interaction or social engineering.

Proof-of-root: Clear, cryptographic validation

To make testing safe, clear, and reproducible, without impacting production environments, we have defined technical criteria for validating root-in-cloud access.

Additionally, valid vulnerability reports demonstrating remote code execution (RCE) in underlying Google production infrastructure (Borg) or achieving root-in-prod will automatically be evaluated by the Google Cloud VRP panel for root-in-cloud eligibility.

Because code execution in Borg has the potential to impact service availability or cross-tenant data, researchers must halt all probing immediately upon achieving any execution in Borg. Escalation, extracting production credentials, and lateral movement are not allowed and will result in researcher disqualification.

The Google Cloud VRP panel will analyze the initial entry point, execution context, and attack surface to determine whether full arbitrary tenant or project takeover is achievable from that position, and award the bounty accordingly.

This new bounty tier reflects how security research continues to evolve, and the importance of continuing to recognize the most innovative and valuable security research. As part of those efforts, Google Security held its annual Escal8 conference in Singapore last week, and I had the opportunity to discuss the changing landscape with Michael Cote, Google Cloud’s vulnerability reward program lead.

The following transcript has been lightly edited.

Chris Betz: You are at Escal8 in Singapore announcing the new $250,000 Root-in-Cloud tier for our VRP. Why introduce this tier now, and what kind of research are you hoping to spark?

Michael Cote: This is a recognition of how the field of security research has changed over the past year. We value quality submissions from anyone, and we’ve seen that the combination of human creativity and agentic power is much richer than either on its own.

While automated scanners generate a high volume of low-impact noise, first-time researchers who pair human intuition with agentic tools are finding, on average, more interesting bugs than novices did two years ago. With the new Root-in-Cloud tier, we want to challenge the community and increasingly reward the complex, high-impact findings — like tenant-isolation bypasses and cross-service logic flaws — that require deep architectural intuition alongside agentic tools, because getting that information is essential to protecting our customers.

Chris Betz: Google Threat Intelligence Group (GTIG) recently shared research showing that monthly CVE disclosures have doubled as agentic tools mature. From your seat leading the Cloud VRP, how has automation technology impacted the reports we’ve received?

Michael Cote: It has transformed our intake volume, though not in the way many people assume. While the number of valid vulnerability reports submitted to the Google Cloud VRP has remained stable over the last 18 months, the total number of reports has grown tremendously.

Automation has helped democratize vulnerability discovery, and the barrier to entry has been rapidly flattening, something even our top researchers noted at Escal8. Because we’re seeing more researchers and more first-timers with interesting bugs, that creates pressure on more experienced researchers to move faster and bring more impactful findings — although their experience continues to be a key differentiator in success.

Chris Betz: I’ve been working with the research community for more than 20 years. One of the things I appreciate most is how much the community values making the world more secure. Bounty programs let us recognize this valuable work. How do you see the community changing as we move further into the agentic era?

Michael Cote: That shared commitment to making the world more secure is still the heart of this community, which is why the pressure to move faster is something we have to watch closely. As our GTIG colleagues found, the sharpest rise in the number of exploited vulnerabilities comes from n-days, not zero-days.

Open source accounts have suggested that threat actors are using LLMs to rapidly turn newly-public vulnerability details into working exploits. When triage teams are already working through a surge in report volume, disclosing an unmitigated vulnerability well ahead of the standard 90-day coordinated disclosure window gives attackers the exact knowledge and time window they need to target customers.

With the influx of new submissions, I worry about a growing pressure to rush to publish. Something that concerns me because we’re already seeing early indications of it. Because LLMs lower the barrier to finding bugs in source-available software, researchers worry that waiting to verify risks will allow someone else to be first to publish. Even more concerning, that same competitive pressure can tempt even established security companies to disclose unmitigated vulnerabilities without coordination, and that rush puts our users directly at risk.

Project Zero helped establish the industry’s 90-plus-30-day responsible disclosure policy, and autonomous detection and exploitation capabilities make following coordinated disclosure more important than ever. In the long run, rushing to be first works against a security company's own self-interest. Novel discoveries may bring temporary visibility, but customers will ultimately choose not to work with organizations that put them and the broader ecosystem at risk.

Chris Betz: When you offer a $250,000 bounty, how do you make sure researchers can validate their findings without putting customer environments or service availability at risk?

Michael Cote: High incentives require clear, safe rules of engagement. We never want researchers testing exploits against real customer projects. Instead, we created a deterministic proof-of-root mechanism using a designated service account. Researchers can cryptographically prove unauthorized access against that identity.

We’ve also updated our program rules to establish strict boundaries around underlying production infrastructure. If researchers think they are close to a breakthrough but are uncertain where the boundary lies, we encourage them to reach out. We are always more than happy to work with them to ensure they are recognized and rewarded for the value of their research without taking steps that would invalidate the bounty.

Chris Betz: What should enterprise CISOs take away from these trends? Especially those who run their own vulnerability management pipelines and partner with external researchers, what advice would you offer for navigating this AI inflection point?

Michael Cote: First, prepare your vulnerability triage workflows for agent-generated submissions. To keep valid reports from getting stuck in a backlog, security teams need ways to separate plausible-sounding hallucinations from real security risks.

Second, compress your remediation timelines once a vulnerability becomes public. Defensive patching and mitigations have to move faster because autonomous technology compresses the time from disclosure to working exploits.

Finally, hold your security partners and vendors to high standards of coordinated disclosure. It’s important that our industry continues to normalize agentic vulnerability research, but we must do so responsibly. Let’s continue to keep user safety at the center of everything we do.

For more information on the Google Cloud VRP, including detailed endpoint specifications, JSON payloads, and CLI examples, please check out our rules page.

aside_block: <ListValue: [StructValue([('title', 'Join the Google Cloud CISO Community'), ('body', <wagtail.rich_text.RichText object at 0x7fdf5eea7490>), ('btn_text', 'Learn more'), ('href', 'https://rsvp.withgoogle.com/events/google-cloud-ciso-community-interest-form-2026?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q1-global-GCP30328-physicalevent-er-dgcsm-parent-CISO-community-2025&utm_content=cisop_&utm_term=-'), ('image', None)])]>

Threat Intelligence news

Investigating ephemeral supply chain tampering: For the first time, Google Threat Intelligence Group (GTIG) and Mandiant have encountered a software supply chain compromise that was implemented with very short tampering windows that were active for only five to 10 minutes, and effectively evading traditional point-in-time triage and automated file scanning. Read more.
ARMORY CASTLE exploits BeyondTrust: During an incident response engagement, Mandiant identified evidence that ARMORY CASTLE, a suspected PRC-nexus espionage threat actor, exploited a vulnerability impacting BeyondTrust Remote Support appliances. Organizations should prepare for potential widespread exploitation following this disclosure, as ARMORY CASTLE and other threat actors have historically conducted broad, opportunistic exploitation once the vulnerability becomes public. Read more.
Vulnerability discovery and exploitation trends in the AI era: To counter the increased risk from rapid vulnerability discovery and exploitation, organizations should transition from unprioritized mass-patching to threat intelligence-driven triage, combining targeted edge-defense with automated, agentic remediation. Read more.
Defending against active exploitation of Citrix NetScaler ADC and Gateway appliances: Mandiant Consulting and Google Threat Intelligence Group (GTIG) identified active, in-the-wild exploitation of a zero-day vulnerability affecting Citrix NetScaler ADC and NetScaler Gateway appliances. Here’s our containment and remediation guidance. Read more.

Please visit the Google Cloud blog for more threat intelligence stories published this month.

Now hear this: Podcasts from Google Cloud

Cloud Security Podcast: Patching browsers with AI, agents, Rust, and your tabs: Jasika Bawa and Doug Turner of Chrome Security explore how Google Chrome now uses AI agents to autonomously identify and patch security vulnerabilities at an unprecedented scale, significantly accelerating the browser's update cadence. Listen here.
Cloud Security Podcast: All about Project Atlas, Wiz's AI vulnerability research: Nir Orfeld, head of vulnerability research, Wiz, discusses how his team uses multi-agent AI systems for discovering high-impact zero-day vulnerabilities in cloud infrastructure. Listen here.
Cloud Security Podcast: How Google eliminates classes of vulnerabilities at scale: How do you build the foundations for a secure Google-scale enterprise that stays secure even if an AI is writing the code and nobody has time to review it? Christoph Kern, principal security engineer, Google, explores what secure-by-design really means in the AI era. Listen here.

To have our Cloud CISO Perspectives post delivered twice a month to your inbox, sign up for our newsletter. We’ll be back in a few weeks with more security-related updates from Google Cloud.

Querying Databricks Apache Iceberg Tables with the borderless Lakehouse

Thu, 29 Oct 2026 16:00:00 +0000

Enterprise organizations often leverage multiple data platforms, including Databricks, to execute heavy Apache Spark jobs alongside BigQuery to power highly concurrent analytics workloads. Historically, bridging these systems often meant building complex pipelines to copy data between environments. This approach increases storage costs, introduces latency, and fragments security controls.

With Google Cloud’s borderless Lakehouse, you can now query Databricks-managed Apache Iceberg tables straight from BigQuery. This zero-copy approach removes the need to duplicate data: BigQuery reads the same files Databricks writes, and new changes appear after Lakehouse's next scheduled metadata refresh (as often as every 5 minutes).

How Lakehouse and Databricks work together

Managed Iceberg tables automatically generates Iceberg-compatible metadata alongside native Delta logs. Data engineering teams can store Parquet files once in Google Cloud Storage (GCS) using Databricks. Rather than loading this information into BigQuery, Lakehouse reads the Iceberg metadata directly, applying BigQuery’s vectorized engine directly to open-format files in GCS.

Although Google Cloud Storage (GCS) serves as the primary storage layer in the above example, Lakehouse extends this borderless federation directly to external cloud environments like Amazon S3 and Azure Blob Storage. By pairing the open Apache Iceberg REST Catalog with cross-cloud connections, Lakehouse lets BigQuery query data across clouds without moving it. Each federated catalog lives in a Google Cloud location you choose, ideally the region closest to your data. This lets BigQuery read open-format Parquet files where they live, delivering multi-cloud analytics without replication pipelines. Remote-cloud egress charges still apply, but Cross-Cloud Interconnect (AWS) and Lakehouse caching can reduce them.

Beyond simply querying external data, Lakehouse framework establishes true read and write (R/W) interoperability across engines. Because the platform is built on an open Apache Iceberg foundation, data teams can effortlessly execute multi-statement SQL commands directly inside BigQuery.

Centralized security and governance

Handling access controls across disparate systems can introduce vulnerabilities. Lakehouse addresses this through delegated access. Administrators can configure a BigQuery Cloud Resource Connection tied to a service account that manages IAM rights for GCS buckets. Granting users access to the Lakehouse table entity lets you enforce BigQuery controls including row-level, column-level security, and dynamic data masking on external Iceberg tables while Databricks handles ingestion.

Catalog federation and credential vending

Previously, connecting these platforms meant manually configuring BigQuery queries to point at static metadata paths. Modern setups leverage the open Apache Iceberg REST Catalog API. Databricks Unity Catalog functions as the central metadata layer, allowing a BigQuery administrator to establish a Lakehouse runtime catalog with a federated connection. When running a query, Lakehouse contacts Unity Catalog for current table state, and short-lived tokens are issued through credential vending to grant BigQuery temporary read access to GCS.

Partition pruning

BigQuery uses each table's Iceberg metadata to plan the query, then reads only the relevant data files in place. Iceberg's hidden partitioning lets you filter on logical columns, such as timestamps, without knowing the directory layout. Note that Databricks managed Iceberg tables don't support partition transforms; Databricks recommends liquid clustering instead.

Filters in a standard WHERE clause let BigQuery use the Iceberg manifests to skip partitions that can't match. Compare partition columns with literal values so pruning can apply. These manifests maintain detailed column-level statistical bounds, enabling BigQuery to bypass irrelevant manifest records and unneeded Parquet files immediately. Consequently, queries scan only necessary byte ranges, accelerating query execution while significantly reducing on-demand slot consumption and storage scan costs.

Fast queries with Iceberg metadata and Lakehouse caching

Iceberg manifests already identify which data files to read, so BigQuery doesn't need a metadata cache for Iceberg tables. For cross-cloud tables, such as those in Amazon S3, Lakehouse caching (Preview) keeps retrieved data blocks in Google Cloud so repeat queries read them locally. BigQuery reads the Iceberg manifest files directly when it plans each query; there's no metadata caching to enable. This dynamic partition pruning bypasses unneeded files, significantly reducing runtime and bytes scanned.

Maintenance and lifecycle management

Modern lakehouses demand active upkeep; without routine care, performance degrades into an inefficient repository. Fortunately, both BigQuery and Databricks supply native capabilities to preserve table hygiene and accelerate analytical workloads.

Keeping your tables optimized

To maintain optimal query performance, active maintenance of your lakehouse storage footprint remains necessary.

Trigger regular compaction pipelines via Databricks APIs to merge tiny Parquet files into larger, optimized layouts and use Predictive Optimization.
Execute the Databricks VACUUM command to clear unreferenced files outside active snapshots, avoiding extra GCS storage costs.

Compaction and the small file problem

Frequent write operations, continuous ingestion jobs, and streaming workloads continuously produce thousands of small Parquet files. This fragmentation creates a storage bottleneck that can limit BigQuery’s reading efficiency. Establishing thousands of network connections to GCS and processing metadata footers across numerous tiny files consumes significant compute time, diminishing the performance advantages of vectorized query execution.

Running routine compaction within Iceberg resolves these inefficiencies. Databricks manages this automatically using Liquid Clustering which dynamically adjusts file layouts based on access patterns or through native table management utilities.

To compact small files manually on Databricks, run OPTIMIZE:

code_block: <ListValue: [StructValue([('code', "-- Run on Databricks to compact small files\r\n-- On Databricks:\r\nOPTIMIZE customer_events;\r\n-- For Iceberg tables you manage outside Databricks:\r\nCALL my_catalog.system.rewrite_data_files(\r\ntable => 'default.customer_events',\r\nstrategy => 'binpack',\r\noptions => map(\r\n'target-file-size-bytes',\r\n'268435456',\r\n'min-file-size-bytes',\r\n'67108864'\r\n)\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5e33d210>)])]>

Executing this command aggregates scattered file segments into larger, structured blocks typically between 256MB and 512MB that can help improve BigQuery’s scan throughput. The binpack approach operates rapidly by prioritizing total file size balancing, though alternative sorting strategies can organize dataset ordering along specific column keys.

Managing orphan files and snapshot retention (VACUUM)

Every transactional update, record modification, and table compaction creates fresh snapshots within Iceberg to preserve dataset integrity. Over time, historical Parquet objects detached from active table states become orphaned. Although these legacy files facilitate time-travel analytics, neglecting them can drive up GCS storage charges over time.

Data teams can use the Databricks VACUUM operation to scan and purge abandoned storage files.

code_block: <ListValue: [StructValue([('code', "ALTER TABLE customer_events SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = '7 days');\r\nVACUUM customer_events FULL;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f8767d0>)])]>

Standard configurations apply a mandatory seven-day threshold (deletedFileRetentionDuration) before executing VACUUM routines. Preserving this delay prevents active analytical jobs from encountering missing file errors while keeping historical recovery options available. Scheduling routine VACUUM jobs, or letting predictive optimization run them, removes unreferenced data files and, for tables with Iceberg reads, old Iceberg metadata. That keeps storage costs low and performance high across your lakehouse.

Conclusion

Connecting Databricks Apache Iceberg datasets to Lakehouse can help you activate your data with BigQuery. By separating processing from underlying storage, embracing open formats, and using standard REST APIs with credential vending, you can run scalable engineering workloads and concurrent analytics without migrating data or sacrificing performance

Pairing Databricks Iceberg reads (UniForm) with Lakehouse federation, Lakehouse caching, and regular OPTIMIZE and VACUUM maintenance helps you build an efficient, zero-copy lakehouse. This approach can help lower storage spend, avoids fragile pipeline maintenance, and prepares your data environment for modern analytics and emerging AI workloads.

Constructing a unified architecture no longer requires moving data files across platforms. You can begin querying Databricks Iceberg tables by registering them with the Lakehouse runtime catalog today for bi-directional federation. Learn more by reading our documentation to get started.

Grounding agents in one context graph connecting semantic models you already trust

Thu, 29 Oct 2026 16:00:00 +0000

Picture the scene: Before an executive business review, your VP of Sales asks an AI assistant, "What was net revenue for our top enterprise accounts last quarter?" In seconds, the agent returns a polished chart! Unfortunately, the numbers don't match the finance report. Why? Because the agent counted cancelled orders as revenue and pulled from an unvalidated staging table.

The agent didn't fail because of the model, or because it couldn't translate a user question into a query. It failed because it didn't understand your business. The real kicker is that understanding usually already exists in the form of a semantic model in a Looker, dbt, Snowflake, Databricks, or SAP system. But because each definition stays locked inside its own tool, every agent guesses at it… and often gets it wrong.

This is where Knowledge Catalog comes in. It brings the semantic models from all of those tools into one context graph, so every agent works from the same trusted definitions. And when two tools define the same metric differently, both definitions appear with their provenance, so data stewards can reconcile the conflict before it reaches end users.

Today, we're announcing the general availability of expanded semantic model support. Knowledge Catalog now natively ingests semantic models and metric definitions from Looker LookML, BigQuery Graph (including BigQuery measures), dbt MetricFlow, Snowflake Semantic Views, Databricks Metric Views, and SAP Core Schema Notation (CSN), and connects them with schema, lineage, data profiles, business glossary and other key metadata in a single context graph, without moving data or rewriting business logic in a new language.

By grounding your AI agents in those models, they get the same business definitions your analysts rely on, so their answers line up with the numbers your business trusts. In fact, based on internal benchmarks, grounding agents in Knowledge Catalog makes them nearly 4X more accurate, with up to 33% lower latency, and using up to 75% fewer tokens.

The unified context graph enables you to:

Reuse the semantic models you already trust: Knowledge Catalog grounds Gemini agent, BigQuery Conversational Analytics, and your custom agents in the metrics, filters, and join paths your teams have already defined, wherever they live.
Go beyond hand-curated definitions with self-learned context: Knowledge Catalog pairs the well-defined metrics and KPI definitions in your semantic models with relevant context it extracts from unstructured knowledge sources, such as operational playbooks, meeting notes, chat threads, code, and more. Powered by Gemini, self-learning enrichment continuously finds missing or outdated context and turns it into governed, reusable context sets, ensuring your agents' context stays current as definitions change, without relying only on manual curation.
Pair business logic with enterprise trust: Even the right formula produces the wrong answer when it runs on stale or uncertified data. That's why Knowledge Catalog can connect semantic definition to data quality scores, freshness signals, and lineage, so an agent knows what it can trust before it writes a line of SQL.

Side-by-side comparison of the same question in Gemini without Knowledge Catalog (left) and grounded in Knowledge Catalog (right). Highlights the grounded agent (right) giving an accurate response with less token and lower latency, compared to the agent without Knowledge Catalog (left) hallucinating and using more tokens with higher latency.

One context graph across your data estate

The context graph that Knowledge Catalog creates is a connected map of your data and semantic estate: tables, semantic models, glossary terms, and data products are nodes; lineage, associations, schema keys, joins mined from real query history, and the join paths declared in your semantic models are the edges. Ingested semantics land in that same graph, next to pre-existing governance and usage signals, so an agent moves from business concept to trusted formula and verified join paths in one traversal. Each source adds its own perspective on your business:

Looker LookML (GA): Indexes models, explores, views, and dashboards using Live sync from Looker Core, capturing compiled metric SQL, fan-out-safe join conditions, mandatory filters, and lineage from source tables to executive dashboards.
BigQuery Graph (GA): Indexes native property-graph definitions, node and edge tables, graph measures, and business synonyms, so agents reason over connected entities with Graph Query Language (GQL) traversals instead of brittle multi-table self-joins.
dbt MetricFlow (GA): Links source objects to dbt models and MetricFlow metrics, alongside dbt data quality test results, filters, saved queries, freshness SLAs, and downstream exposures.
Snowflake Semantic Views via Horizon Catalog (GA): Pairs federated BigQuery or Google Cloud Lakehouse tables with Snowflake Horizon metadata, bringing in Semantic View dimensions, facts, metric formulas, relationships, and synonyms, plus Data Metric Function quality scorecards and PII masking tags.
Databricks Metric Views via Unity Catalog (GA): Ingests metric view definitions, measure formulas, scoping filters, and join cardinalities from Unity Catalog, alongside table certification badges and Lakehouse Monitoring profiling results.
SAP Core Schema Notation (CSN) via SAP Business Data Cloud (BDC) (GA): Captures business labels, dimension and cube modeling patterns, default aggregations, currency and unit bindings, key and composite join associations, and data sensitivity flags when SAP BDC Data Products are federated through Google Cloud Lakehouse.

Because every source lands as a node or an edge in the same graph, a LookML join, a dbt exposure, a Snowflake relationship, or an SAP association are traversable side by side, with links tying each one back to the physical tables it depends on. And nothing is silently overwritten: overlapping definitions stay side by side, each labeled with its source, giving data stewards the full picture they need to settle on a single version.

Navigating semantic models, join paths, and lineage on the context graph in Knowledge Studio.

You can explore and govern all of this in Knowledge Studio (preview), your command center to explore and manage your context. Explore your context graph, including your semantic definitions, using natural language prompts and traverse connection paths using the context graph canvas. Then, once you've validated the right assets and definitions, you can package them into reusable context sets that map to specific use cases and domains in your organization, which Gemini and custom agents can consume in production.

Get started

Let’s get back to that net revenue question. With Knowledge Catalog, the VP of Sales’ agent issues a single context query to discover the trusted asset, applying the exact metric formula and filters that your domain experts defined, all while respecting join keys across systems, and confirming that the underlying data passed its quality checks. Better yet, the numbers in the report are correct!

To get started, explore your context graph in Knowledge Studio and visit the Knowledge Catalog documentation to connect to more sources.

What’s new with Google Data Cloud

Thu, 29 Oct 2026 16:00:00 +0000

October 26 - October 30

Knowledge Catalog introduces self-learning context enrichment and Knowledge Studio (Preview)
Knowledge Catalog's enrichment agent now learns from agent and user interactions and from sources such as playbooks, code repositories, and business documents to find and fix missing or outdated context, which teams can package into reusable context sets. Knowledge Studio, the new studio experience in Knowledge Catalog, lets context engineers and data stewards explore their data estate conversationally, navigate a visual context graph, and review changes before they reach users and agents. Based on internal benchmarks, grounding agents in Knowledge Catalog makes them nearly 4x more accurate, with up to 33% lower latency and using up to 75% fewer tokens. Read the launch blog.
Knowledge Catalog now grounds AI agents in the semantic models you already trust (GA)
Knowledge Catalog natively ingests semantic models and metric definitions from Looker LookML, BigQuery Graph, dbt MetricFlow, Snowflake Semantic Views, Databricks Metric Views, and SAP Core Schema Notation, and connects them with lineage, data quality, and access controls in a single context graph. Gemini Enterprise, BigQuery conversational analytics, and custom agents retrieve a metric's trusted formula, verified join path, and backing table in one context call, without moving data or rewriting business logic. Read the launch blog.

October 19 - October 23

BigQuery introduces column aliases in GoogleSQL and cross-region table copy GA
GoogleSQL in BigQuery now supports column aliases in SELECT and WHERE clauses (GA opt-in), avoiding nested subqueries and simplifying migrations from Snowflake and Teradata. Cross-region table copying is also now generally available to streamline regional data replication and disaster recovery. Review the BigQuery release notes.
Conversational analytics in BigQuery expands to Canada and adds CSV/PDF export
Conversational analytics in BigQuery is now available in Montréal (northamerica-northeast1) and Toronto (northamerica-northeast2) to support Canadian data residency requirements. You can also now export agent responses — including text, tables, charts, and citations — directly to CSV or PDF (GA). Learn more about conversational analytics in BigQuery.
AlloyDB Omni 18.4.0 is now GA with Advanced Query Insights and external KMS support
AlloyDB Omni 18.4.0 brings PostgreSQL 18.4 to self-hosted and multi-cloud environments, adding the google_insights_v2 extension for granular query execution and wait-event diagnostics. It also adds Thales CipherTrust Manager support for Transparent Data Encryption (TDE) alongside HashiCorp Vault. Explore the AlloyDB Omni release notes.
Cloud SQL for PostgreSQL adds managed connection pooling and Private Service Connect defaults
Cloud SQL for PostgreSQL now supports enabling built-in managed connection pooling on existing Private Service Connect (PSC) instances to scale high-concurrency workloads. PSC is also now the default private IP option for new Cloud SQL instances in new projects to simplify cross-project networking. Review Cloud SQL updates.
Customer momentum: Unico prevents over $5B in fraud on Google's Agentic Data Cloud
Digital identity platform Unico migrated from Databricks Spark/Scala clusters to BigQuery and Spanner at the core of its data architecture. Unifying real-time transaction streams with petabyte-scale analytics enabled low-latency identity verification that has prevented over $5 billion in fraud. Read the Unico case study.
Developer guide: Getting started with Looker Data Apps
Following the debut of Looker Data Apps in preview, a new walkthrough on the Google Developer Community shares practical patterns for building prompt-driven applications inside Looker. Read the guide on the Google Developer Community.

October 12 - October 16

Looker Data Apps are now in Preview to build and host interactive, agent-generated applications natively inside Looker
Generated using natural language prompts, the Antigravity CLI, or Claude Code, these interactive web applications, natively hosted inside Looker, transform business reporting into operational systems of action. Users can test scenarios, adjust parameters, and trigger workflows in downstream platforms while inheriting LookML semantic modeling, row-level security, and access controls with no runtime LLM token costs. Read the announcement blog.
Build end-to-end data science pipelines with the Data Agent Kit
Following the general availability of the Data Agent Kit, a new end-to-end walkthrough demonstrates how data teams can build, test, and schedule machine learning pipelines directly from their preferred code editors. Explore the walkthrough and codelab.
Manage dashboard agents as code to bring CI/CD and version control to LookML dashboards
Data teams can now declare agent parameters, configurations, and prompt instructions alongside dashboard files in code. This integration enables standard developer workflows for conversational BI, including Git version control, peer review, branching, and automated CI/CD validation before agent modifications reach production end users. Read the technical guide on the Google Developer Community.
Simplify AI search with native AlloyDB hybrid search and Reciprocal Rank Fusion
AlloyDB for PostgreSQL simplifies hybrid search architectures by combining vector similarity search and keyword BM25 retrieval within a unified database engine. Using Reciprocal Rank Fusion (RRF), developers can merge lexical scoring and semantic embeddings into a single ranked result without writing a complex SQL query. This unified approach removes the operational overhead of running and synchronizing external search engines alongside operational databases for retrieval-augmented generation (RAG) and search applications. Explore hybrid search in AlloyDB.

October 5 - October 9

Data Agent Kit is now generally available to bring Google Data Cloud to any coding agent
Data Agent Kit provides a free collection of Model Context Protocol (MCP) tools and Google-authored agent skills that connect more than 15 Google Data Cloud services directly to coding agents across VS Code, Antigravity, Cursor, Claude Code, and Codex. This release expands support for developers and data practitioners to inspect schemas, author queries, and build end-to-end data pipelines in natural language directly from their IDE or CLI. Read the announcement blog.
Spanner Omni is now generally available for deploy-anywhere, multi-model workloads
Spanner Omni brings Spanner's distributed SQL, graph, vector, and key-value capabilities to any environment, including on-premises data centers, other public clouds via Kubernetes or VMs, and local developer laptops. Organizations can build and run multi-model applications with consistent APIs and query engines across hybrid and multi-cloud footprints while seamlessly scaling to managed Spanner on Google Cloud. Read the launch blog and explore how Spanner also removed cumulative mutation limits for DML transactions.
AlloyDB delivers PostgreSQL for agents and native BM25 hybrid search
We announced PostgreSQL for agents in AlloyDB, introducing an agentic database architecture engineered for real-time data access at agent scale with workload isolation. In addition, native BM25 ranking is now in Preview for AlloyDB and Cloud SQL, allowing developers to combine keyword search and vector embeddings directly in PostgreSQL without maintaining an external search engine. For hybrid deployments, the AlloyDB Omni RPM Orchestrator is now generally available, and you can dive deeper in our new Build AI apps and agents with AlloyDB eBook.
Lakehouse runtime catalog adds regional endpoints across 22 regions and GA support for flexible column names
Lakehouse runtime catalog regional endpoints are now live across 22 Google Cloud regions across the Americas, Europe, Asia-Pacific, and the Middle East, supporting both the Apache Iceberg REST catalog endpoint and the Apache Hive catalog endpoint to help customers meet strict data residency and sovereignty requirements. In addition, flexible column names for Apache Iceberg tables are now generally available by default across Iceberg external tables and managed tables, enabling seamless querying of columns containing spaces, hyphens, and Unicode characters. We also announced the Preview of cross-cloud caching and connections for the borderless Lakehouse.
Unlock predictive and agent-ready insights with BigQuery augmented analytics TVFs, TabFM, and identity columns
BigQuery introduced augmented analytics table-valued functions (TVFs): six built-in functions that automate metric diagnostics, trend analysis, and pattern discovery directly where your data lives and integrate as skills for AI agents. We also introduced TabFM in BigQuery to bring tabular foundation model capabilities to predictive analytics, alongside BigQuery identity columns to automatically generate sequential surrogate keys and simplify data warehouse pipelines.
Dataflow adds Pause/Resume and NVIDIA RTX PRO 6000 Blackwell GPU support for large-scale AI workloads
New Dataflow capabilities make it easier to run high-throughput streaming and batch AI pipelines at scale, including Pause/Resume job controls and support for NVIDIA RTX PRO 6000 Blackwell GPUs. And for teams running Apache Spark workloads, learn how to mitigate compute stockouts and maximize availability using flexible VMs.
Unlock up to 3x higher QPS and microsecond latency with Memorystore for Valkey 9.1
Memorystore for Valkey 9.1 is now available, delivering up to 3x higher queries per second (QPS) and microsecond-level caching latencies to accelerate high-throughput applications and real-time AI agent state management. Read the blog.
Customer momentum across Google Data Cloud — Yahoo, PayPal, Surescripts, Airwallex, and Lucius AI
Organizations across industries are scaling their data and AI foundations on Google Data Cloud. Yahoo uses flexible VMs in Managed Service for Apache Spark to reduce provisioning failures by 85%, while PayPal migrated mission-critical analytics workloads to Managed Service for Apache Spark to scale and reduce operational overhead. On the database front, Surescripts migrated 30.5 billion annual healthcare transactions to AlloyDB with 99.998% uptime, Airwallex manages more than 5,000 databases with 99.99% availability on Cloud SQL with a team of four DBAs, and Lucius AI runs a 210,000-tender global platform on AlloyDB and MCP with 47x faster ScaNN vector search.

September 7 - September 10

Pub/Sub SMTs can now AI Inference your Gemini Enterprise Agent Platform models!
Pub/Sub AI Inference SMTs allow you to apply inference on an incoming stream of events using models hosted in Gemini Enterprise Agent Platform. The model’s prediction is appended to your event, making it available for downstream processing in your data warehouse (like BigQuery) or operational database (like BigTable). This feature, now generally available, can dramatically simplify or enhance anomaly detection systems you are operating.
PostgreSQL Source Connector is now generally available in Managed Service for Apache Kafka!
Managed Service for Apache Kafka’s PostgreSQL connector allows customers to capture changes from their PostgreSQL database and ingest them into their Kafka infrastructure with low latency. This source connector is compatible with Cloud SQL for Postgres, AlloyDB, and self-managed PostgreSQL databases. Try this along with our entire portfolio of managed connectors, including MirrorMaker 2.0, BigQuery, Cloud Storage, and Pub/Sub! E-mail kafka-hotline@google.com if you have questions or feedback!

Pause-on-failure for Dataflow batch jobs is GA
Dataflow pause-on-failure enables you to preserve the state of a batch Dataflow job before it fails. By pausing your Dataflow job, you can address issues that are external to the pipeline and resume processing without losing completed work. This helps you better manage resource costs and improve job reliability when you face temporary outages or capacity constraints.

The insertAll API is now the BigQuery Storage Write API (REST)
The legacy insertAll streaming API is now rebranded as the BigQuery Storage Write API (REST). By dropping the "legacy" label, developers can confidently build long-term HTTP-based streaming workflows. This stateless JSON-over-HTTPS endpoint offers a lightweight alternative to heavy gRPC libraries—ideal for serverless web apps, IoT telemetry, and AI logging. The transition is seamless for existing users, requiring zero code changes and offering 100% backward compatibility. However, the Storage Write API (gRPC) version remains the recommended standard for high-throughput, continuous pipelines.

August 31 - September 4

Stateful processing is available in BigQuery continuous queries in Preview
Stateful operations significantly expand what’s possible with BigQuery continuous queries. This feature allows users to leverage functions like JOINs, aggregations, and windowing functions directly in their streaming queries. Now you can calculate metrics over time (for example, a 30-minute average) to power your downstream applications and AI agents with much richer, real-time signals.

Try out our feature here and share your feedback with bq-continuous-queries-feedback@google.com!
Synthetic data generator tool is available for Managed Service for Kafka
You’ve launched your first Kafka cluster. Now what? The next thing to do is to produce some data to the cluster, but that involves modifying a client application somewhere or spinning up a virtual machine. The synthetic data generator tool, now generally available, can start sending mock data to your cluster in 3 clicks, and will get data streaming into your cluster in less than two minutes. The perfect utility for those moments you just want to test your cluster and new features. Try our quickstart today!

Dataflow pipeline updates are faster & more flexible
Dataflow pipeline updates can now stop-and-replace pipelines, a major addition to the existing in-place-update feature. The new parallel pipeline option accelerates the migration between the old & new pipeline, resulting in reduced disruption to your business. You can also set a timeout on drains that prevents runaway costs for your pipeliness in the event of stuck processing. This feature is generally available. Try it here!

July 6 - July 10

New Lakehouse managed tables now in preview
Lakehouse tables for Apache Iceberg are now in preview and available in the console. By using Google-managed Apache Iceberg tables in Lakehouse, you can eliminate the overhead of maintaining duplicate data pipelines and complex synchronization logic between BigQuery and open-source engines. This unified table format delivers native, multi-engine read and write interoperability, allowing you to run concurrent DML/DDL operations across diverse analytics tools on a single, shared storage layer. Built-in automated table management handles painful background optimization tasks like compaction and partition tuning, freeing up your team to focus on building rather than managing storage maintenance.

June 1 - June 5

Beyond the Query: Powering AI Agents with Bigtable, Firestore & Memorystore
Discover the latest advancements in Google Cloud's NoSQL Database portfolio, including Bigtable, Firestore, and Memorystore. This series is designed for a broad audience: whether you are exploring these databases for the first time or are an existing user looking to leverage the new capabilities announced at Next '26.

Register here to secure your spot!

Cloud Engineer's AI Toolkit Workshops: Solve data-driven challenges with BigQuery, AlloyDB, Gemini and more. Hosted by Google Cloud Labs, this highly technical event is built specifically for Platform Engineers, SREs, and cloud infrastructure teams ready to bridge the gap between AI prototypes and production-grade deployments. Look out for more locations coming soon

Toronto - June 25 (Data Cloud) | RSVP Here
Chicago - June 30 (Data Cloud) | RSVP Here
Start a 10-day Bigtable free trial with a 1 node SSD cluster and up to 500GB of storage capacity. With no credit card required to start, you can easily ingest workloads and manage workloads that require low-latency, high-throughput, and predictable access. Plus, new Google Cloud customers get $300 in free credits on signup.

May 11 - May 15

Managed Service for Apache Airflow has launched a wave of new features, including the general availability of Airflow 3.1, AI-powered agentic troubleshooting, a new managed Airflow MCP Server for custom agent integration, and declarative YAML-based orchestration pipelines—discover all the details in the full blog post.

April 20 - April 24

Google-built ODBC Driver for BigQuery is now available in Preview
We are excited to announce the launch of the new, Google-built ODBC driver for BigQuery. This new open-source driver provides a direct, high-performance connection for applications to BigQuery and is developed entirely in-house by Google. Download a new driver and connect your application to BigQuery.

April 13 - April 17

We announced we are reintroducing Data Studio to play a significant role in the AI era, expanding from data visualizations and reports to host BigQuery conversational agents and data apps built in Colab notebooks.
We announced BigQuery Graph is now available in preview, offering an easy-to-use, highly scalable graph analytics solution, empowering data professionals to model, analyze and visualize massive-scale relationships in an entirely new way.

April 6 - April 10

We introduced Conversational Analytics for Looker Embedded environments, enabling users to add natural language experiences to their own custom data-driven applications, powered by Gemini.
We expanded Looker’s capabilities for faster ad-hoc analysis, with the introduction of self-service Explores, enabling you to bring your own data to Looker’s semantic layer and gain instant access to insights in a governed data environment.

March 23 - March 27

We showed you how you can scale your reads with Cloud SQL autoscaling read pools. This feature allows you to provision multiple read replicas that are accessible via a single read endpoint and to dynamically adjust your read capability based on real-time application needs.
Our customers are leveraging the full power of Conversational Analytics and Looker to drive major business and technical breakthroughs in the AI era. Companies like Telenor, Pet Circle, Fluent Commerce, Lighthouse Intelligence, Wego, and ROLLER are turning data into insights and actions, grounded by Looker’s semantic layer.

March 16 - March 20

We introduced an enhanced Gemini assistant in BigQuery Studio, transforming the agent from a code assistant into a fully context-aware analytics partner.

February 23 - February 27

We introduced managed and remote MCP support for Google Cloud databases, including AlloyDB, Spanner, Cloud SQL, Bigtable and Firestore, to power the next generation of agents. This announcement extends the ability for AI models to plan, build, and solve complex problems, connecting to the database tools our customers leverage daily as the backbone of their work environment.
We outlined how you can build a conversational agent in BigQuery using the Conversational Analytics API to help you build context-aware agents that can understand natural language, query your BigQuery data, and deliver answers in text, tables, and visual charts.

February 16 - February 20

Our customers are leveraging the full power of Looker to drive major business and technical breakthroughs. Companies like Arrive, Audika, Carousell, Framebridge, GumGum, Intel, Overdose Digital, Ocean Network Express, Subskribe and Promevo are leveraging Looker’s newest AI-driven capabilities, including Conversational Analytics, to transform data to insights and actions, and empower their entire organization with a single source of truth, powered by Looker’s semantic layer.

February 2 - February 6

Join us on March 4 for our webinar, Win Your AI Strategy with Cloud SQL Enterprise Plus, to learn how to power your generative AI workloads with 3x higher performance and 99.99% availability. Register today to discover how to build a scalable, enterprise-grade foundation for your most demanding AI applications.

January 26 - January 30

We introduced Conversational Analytics in BigQuery, which allows users to analyze data using natural language. Conversational Analytics in BigQuery is an intelligent agent that generates, executes and visualizes answers grounded in your business context directly in BigQuery Studio, making data insights for data professionals more conversational.
We outlined how data products have become the foundation for AI agents, providing the context needed to make autonomous agents reliable and trusted for real business use, backed by organized business logic and semantic understanding.
We highlighted how you can supercharge data analytics workflows, and outlined Google Cloud’s AI agent offerings for data engineering, data science, and development tools, so you can integrate agentic workflows in your applications, empower your teams and speed discovery.

January 19 - January 23

We have fundamentally reimagined Firestore with pipeline operations for Enterprise edition. Experience a powerful new engine featuring over a hundred new query features, index-less queries, new index types, and observability tooling to improve query performance. Seamlessly migrate using built-in tools and leverage Firestore’s existing differentiated serverless foundation, virtually unlimited scale, and industry-leading SLA. Join a community of 600K developers to craft expressive applications that maximize the benefits of rich queryability, real-time listen queries, robust offline caching, and cutting-edge AI-assistive coding integrations.
Introducing Google Cloud SQL on MSSQLTips: We are highlighting a new technical guide published on MSSQLTips titled "Introducing Google Cloud SQL." This article serves as an essential resource for SQL Server administrators and developers exploring Google Cloud's fully managed database service. It provides a detailed overview of Cloud SQL capabilities, including high availability, security integration, and the seamless transition of on-premises SQL Server workloads to the cloud, making it an ideal resource for those planning their migration strategy.
We are excited to announce the Public Preview of Microsoft Entra ID (formerly Azure Active Directory) integration with Cloud SQL for SQL Server. Designed to tackle the challenge of identity sprawl in multi-cloud environments, this integration allows organizations to govern database access using their existing Microsoft identity infrastructure. Key benefits include centralized identity management, enhanced security features like Multi-Factor Authentication (MFA), and simplified user administration through direct group mapping. This feature is available for SQL Server 2022 and supports both public and private IP configurations.

January 12 - January 16

Google-built JDBC Driver for BigQuery is now available in Preview
We are excited to announce the launch of the new, Google-built JDBC driver for BigQuery. This new open-source driver provides a direct, high-performance connection for Java applications to BigQuery and is developed entirely in-house by Google. Download a new driver and connect your Java application to BigQuery.
Troubleshoot Airflow tasks instantly with Gemini Cloud Assist investigations: Cloud Composer just got smarter. We are excited to announce that Gemini Cloud Assist investigations are now available directly within Cloud Composer 3. Instead of manually sifting through raw logs, you can now simply click "Investigate" on a failed Airflow task. Gemini analyzes logs and task metadata to identify failure patterns—such as resource exhaustion or timeouts—and provides actionable recommendations driven by Gemini Cloud Assist to resolve the issue. This integration shifts the debugging experience from manual toil to automated root cause analysis, significantly reducing the time required to restore your pipelines. Learn more about AI-assisted troubleshooting.

Introducing the AlloyDB Omni web UI for easier cluster observability

Wed, 28 Oct 2026 16:00:00 +0000

Managing PostgreSQL databases across on-premises, edge, and multi-cloud environments often forces administrators to rely on command-line tools, making it hard to see cluster health and quickly diagnose issues. To solve this, we are announcing the General Availability (GA) of the AlloyDB Omni Web UI for Red Hat and containers. This production-ready, read-only console gives you direct visibility into hardware telemetry, query performance, and configuration flags for AlloyDB Omni so you can troubleshoot workloads quickly and safely without leaving your local or enterprise environment.

What is AlloyDB Omni?

AlloyDB Omni is a downloadable, self-managed edition of AlloyDB that brings enterprise capabilities and full PostgreSQL compatibility to your own infrastructure. Built to run anywhere — across on-premises data centers, edge environments, and multi-cloud deployments — it includes built-in columnar acceleration and integrated AI tooling. With AlloyDB Omni, you can modernize demanding transactional and analytical workloads while retaining complete control over your operating environment.

Key Web UI capabilities at a glance

Cluster overview and profiles: Switch between target connection profiles quickly without using the command line.
System monitoring: View real-time performance telemetry for CPU, memory, and disk I/O to plan capacity and triage infrastructure issues.
Query performance: Identify resource-heavy SQL statements through a visual breakdown of database load, latency bottlenecks, and slow queries.
Columnar Engine diagnostics: Track the in-memory columnar store, caching, and coverage to verify analytical query acceleration.
Parameter and flag auditing: Inspect runtime database parameters centrally to identify configuration drift against your organizational baselines.
AlloyDB AI and ecosystem shortcuts: Inspect vector search and AI workflows, and access quick launchpad shortcuts for ecosystem tools like pgBackRest.

Production-safe diagnostics and profile management

When you triage complex database workloads across bare-metal VMs, containers, or Kubernetes, you need a clear, isolated view of instance health. The Web UI provides a dedicated visual environment for this.

Profile management: Store and toggle between saved connection profiles for local development, staging, or production environments.
Read-only operations: The interface operates strictly in read-only mode, ensuring that diagnostic sessions cannot execute write commands or modify your underlying database configurations.

Dual-layer observability: System and query monitoring

To isolate production performance spikes, you need immediate visibility into both hardware health and SQL statement execution.

System monitoring: The Web UI integrates with standard Prometheus telemetry to show you real-time CPU use, memory allocation, storage I/O, and active connection trends.
Query monitoring: The dashboard automatically ranks execution-heavy SQL statements by total latency and call frequency. You can instantly isolate unindexed or resource-intensive queries to resolve issues faster.

System Insights and Query Insights in AlloyDB Omni Web UI

Real-time Columnar Engine diagnostics

AlloyDB Omni includes an advanced Columnar Engine that organizes frequently accessed data in memory, accelerating analytical queries significantly compared to standard PostgreSQL. The Web UI helps you monitor this feature directly:

Memory footprint tracking: Check real-time columnar memory consumption against your hardware limits.
Columnarization and cache coverage: See exactly which tables and columns are actively cached in memory to confirm your workloads are running as fast as possible.

AlloyDB AI and Columnar Engine Insights in AlloyDB Omni Web UI

Database flag and parameter auditing

Keeping database parameters uniform across distributed environments keeps your operations stable. The Web UI gives you a central catalog to inspect active database flags and runtime settings. You can verify node settings against your organizational policies without connecting to servers via SSH or parsing configuration files manually. If configuration drift is detected, changes should be applied via the authoritative provisioning workflow (e.g., updating Kubernetes CRDs/GitOps manifests, running Ansible playbooks, or using alloydbctl).

Database flags in AlloyDB Omni Web UI

Built-in AlloyDB AI and tooling hub

As you build generative AI applications on top of PostgreSQL, the Web UI gives you direct visibility into vector search workflows and AI model integrations. You can also quickly navigate to documentation and external ecosystem resources, including backup tools like pgBackRest, directly from the console's tooling hub.

Operational scope and prerequisites

We designed the AlloyDB Omni Web UI with clear operational boundaries so you can deploy it easily within enterprise security boundaries and air-gapped environments.

Non-Intrusive Monitoring: The interface operates with minimal permissions out of the box, preserving your existing command-line tools and CI/CD pipelines as the authoritative controls for cluster provisioning and administrative workflows.
Standard monitoring prerequisites: To see complete system hardware metrics, you need standard Prometheus monitoring configured within your host environment.

Get started

Ready to modernize your PostgreSQL workloads and get dedicated observability for your AlloyDB Omni cluster ?

To request access to RPM-based enterprise distributions, advanced tooling, and the Web UI, complete the sign-up form for RPM based deployment of AlloyDB Omni.
To request access to container-based enterprise distributions, advanced tooling, and the Web UI, complete the sign-up form for container-based deployment.

Install the Web UI: Follow the step-by-step installation instructions in the AlloyDB Omni documentation to deploy the AlloyDB Omni Web UI

For deployment using Red Hat RPM: Deploy via native RPM Package
For deployment using Docker or Podman: Deploy via container image

Behind the scenes, two months later: How we ship Google Agent Skills like products

Wed, 28 Oct 2026 16:00:00 +0000

In my previous post, I took you behind the scenes of Google Agent Skills, covering how the project started, how we maintain quality at scale, and how we handle governance. In this post, I'll share what we've built since then: the automated quality gates that every change must pass, the AI review agent that inspects skill quality, and the lessons that we learned along the way. You can adopt similar gates and review rules in your own skill repository.

Since my last post, the Google Agent Skills repository has passed 21,000 GitHub stars, up from 15,000. It now hosts over 170 skills from teams across Google, and we distribute them across multiple AI platforms.

Building agent skills for a single developer or a small project is straightforward. You write a SKILL.md file, define a few instructions, test it manually, and it works. At our scale, manual workflows stop being effective. Unvetted edits can introduce subtle bugs, and it becomes difficult to catch issues before they reach users.

The core philosophy: Ship skills like products

One key lesson from my previous post: a skill is a living product, not a one-off document. In practice, that means we ship every skill update like a product release.

It's tempting to treat a skill as documentation. But documentation explains concepts to a human reader, while a skill steers an AI agent's reasoning loop, tool selection, and execution path. A misplaced phrase in a skill can cause an agent to invoke invalid command flags, enter an infinite loop, or waste tokens.

That makes every instruction edit a behavioral change. You wouldn't ship a product update without testing it, and the same goes for a skill. This principle drives three core requirements:

Strict semantic versioning: Every behavioral change requires an explicit version bump.
Deterministic automated validation: Linters and validators check every proposed change before a human or AI reviewer sees it.
Mandatory evaluation evidence: Every change includes an evaluation report. It compares the skill against its previous version, or—if the skill is new—against an agent without the skill.

Automated conformance gates: The pull request pipeline

In my previous post, I briefly listed the checks that every skill passes on check-in: linters, link checkers, and AI-assisted checklists. Here's what's inside them, plus two gates that I haven't covered before: semantic versioning and evaluation suite validation.

When an author submits a change to our internal skills repository, an automated continuous integration and continuous delivery (CI/CD) pipeline triggers immediately. Before a skill is exported to GitHub, it must pass these six automated gates and receive human approval:

Structural conformance: Directory layout, allowed files, and taxonomy.
Skill linters: Frontmatter, folder naming, and Markdown rules.
Semantic versioning: Version bump for every behavioral change.
Evaluation suite: Valid eval suite and a fresh eval report.
Link validation: Links are valid.
AI review agent: Skill quality and design standards.
Human approval: Final approval from a human reviewer (a subject matter expert).

Structural conformance and skill linters

Our automated validation suite inspects every pull request for structural and syntactical correctness. Some of the rules include these requirements:

Folder name and metadata name must match.
SKILL.md and description length limits are enforced.
All required fields in the frontmatter metadata are present.
Only a curated list of files and directories is allowed within a skill directory.
All Markdown files follow formatting rules.
The main README.md file and the machine-readable index.json registry are up to date.

Semantic versioning

Every skill declares a semantic version in its SKILL.md frontmatter metadata:

code_block: <ListValue: [StructValue([('code', '---\r\nname: spanner-basics\r\nmetadata:\r\n version: "1.1.1"\r\n category: Databases\r\ndescription: ...\r\n---'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f874d10>)])]>

First, our automated checks verify that the version is a quoted string. YAML parses unquoted values like 2.0 as numbers, which causes unexpected parsing errors in tools that expect a string.

Second, the validator checks the version transition itself. New skills must start at 1.0.0, and any change to an existing skill's instructions, scripts, or references requires a version bump or the pull request is blocked. Standard reset rules apply: bumping MAJOR (for example, 1.4.2 to 2.0.0) resets MINOR and PATCH to 0, and bumping MINOR (for example, 1.4.2 to 1.5.0) resets PATCH to 0.

Why enforce strict versioning if the agent only reads the Markdown instructions? The version number is for the developer and their package tooling, not for the model at runtime. Skills don't auto-update in the background, which means there's no network check or latency overhead each time an agent invokes a skill. Instead, explicit versions let developers compare their locally installed skills against the upstream catalog and decide when to pull changes—for example, by running the npx skills update command. This versioning also supports workflows where teams want to lock a critical skill to a known-good version to guarantee reproducible agent behavior across their projects.

Evaluation suite validation

Our continuous evaluations (evals) compare agent performance with and without each skill. Those results are only as reliable as the evaluation suites behind them. If a suite contains broken file references or compound expectations, test results become noisy and untrustworthy.

Our validator parses each evaluation suite and the pull request description. Then it checks several strict invariants:

Resolution of file-based prompts: When a test prompt references a file (such as @file:test_prompt.txt), the validator confirms that the target file exists and that it isn't empty.
Atomic expectations: Each expectation must check exactly one criterion. The validator blocks compound expectations until authors split them. Lesson 2 later in this post shows why.
Duplicate detection: The validator flags duplicate test prompts and conflicting expectations within the same evaluation suite.
Mandatory evaluation report: Every pull request that modifies a skill must link to an evaluation report in its description.
Eval staleness check: Authors usually iterate on a pull request as reviewers leave feedback. The validator confirms that the linked report ran against the latest commit.

Link validation

Over 170 skills link to documentation for fast-evolving Google products, and those pages can move long after a skill passes review. Rather than waiting for users to report broken links, we validate links at two stages. Before merge, pull request checks verify all relative links, such as files in references/.

Then, every Monday, a GitHub Actions workflow runs lychee across all external links in the public repository and it reports any broken links to skill owners for remediation.

AI review agent

Linters and schema validators catch syntactic errors, but they can't evaluate overall quality. They can't tell you if an instruction is confusing, if a reference guide is too verbose, or if a task should have been a bash script instead of a large language model (LLM) instruction.

To solve this, we integrated an AI review agent into our review pipeline. When a change affects a skill, the AI reviewer inspects it using a dedicated review skill. Yes, we use a skill to review skills.

Here are the core rules the AI reviewer evaluates. You can adopt these rules in your own skill development workflows.

1. Skill suitability and the deterministic trap

The first question our AI reviewer asks is simple: Does this task belong in an instruction?

We often see authors fall into the deterministic trap. They write rigid, numbered sequences of command-line interface (CLI) commands directly into Markdown text.

LLMs are probabilistic engines. If an operation requires a strict sequence of commands where a variation can cause an error, embedding those commands in the instruction text invites hallucinations.

Our AI reviewer enforces a clear boundary between deterministic and probabilistic logic. Rigid CLI sequences, JSON parsers, and deployment steps must live in executable scripts under scripts/. Markdown instructions are reserved for tasks that require judgment, such as choosing an architecture, diagnosing error logs, or synthesizing code.

This rule complements the Model Context Protocol (MCP) guidance that I shared last time: prefer remote MCP tools whenever possible. When you must fall back to CLI or API calls, wrap them in a script instead of spelling them out in the instructions.

2. The L1/L2/L3 modular architecture

Context windows are valuable. Loading a 2,000-line skill into an agent consumes context and degrades reasoning.

Our AI reviewer enforces a three-tier information hierarchy that follows the progressive disclosure model of Agent Skills:

Level 1 (Metadata): The YAML frontmatter (name, description). The agent uses this concise summary for discovery and routing.
Level 2 (Core instructions): The main SKILL.md file. The body must stay compact (under 500 lines). It provides workflow overviews, decision trees, and guardrails.
Level 3 (Reference docs): Detailed API references, schemas, and other reference tables live in a references/ directory.

Our AI reviewer enforces two distinct rules for Level 3: flat directory structure and single-hop indirection. Keeping references/ flat (no subdirectories) is a repository convention that discourages sprawling documentation trees and makes file discovery simpler. More importantly for runtime performance, the reviewer blocks chained references, where SKILL.md links to a reference file that links to yet another file. Each hop requires an extra tool call, adding latency and cost, and our evaluations showed that agents frequently stop before following a second level of chained references.

3. Non-interactive script design

When skills bundle helper scripts in scripts/, we expect agents to execute them directly in terminal sandboxes.

Our AI reviewer flags any script that blocks on interactive prompts. Every script must accept inputs through command-line flags or environment variables, provide --help documentation, and include a --dry-run or confirmation flag for destructive operations. Scripts also need to separate output cleanly, writing structured data (usually JSON) to standard output and writing actionable error messages to standard error.

Example AI review checklist snippet

The review skill also checks frontmatter for spec compliance and discovery, and it turns the L1/L2/L3 architecture into concrete structure rules. Here's an excerpt from those criteria:

code_block: <ListValue: [StructValue([('code', '### Front Matter & Discovery\r\n\r\n- **Spec Compliance**: YAML front matter MUST strictly follow the Agent Skills\r\n Reference Specification (https://agentskills.io/specification). Use `>-`\r\n (folded strip-chomping) format for multi-line descriptions.\r\n- **Description Quality**: The `description` field must follow the\r\n [Description Guide](references/description_guide.md).\r\n\r\n### Content Structure & Authoring Quality\r\n\r\n- **L1/L2/L3 Architecture**: Enforce modular structure. The main `SKILL.md`\r\n body must stay under 500 lines. Move deep domain reference material to\r\n `references/` (see [Skill Structure](references/skill_structure.md)).\r\n- **Flat References Directory**: `references/` must be a flat directory (one\r\n level deep, no nested subdirectories). References > 100 lines must include a\r\n Table of Contents with line hints (see\r\n [Skill Structure](references/skill_structure.md)).\r\n- **Avoid Deeply-Nested References**: Avoid deeply-nested references (e.g.,\r\n `SKILL.md` -> `references/guides.md` -> `assets/output.tmpl`). Keep\r\n reference structures shallow (one level of indirection from `SKILL.md`)\r\n because agents might not load such link targets fully.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f8247d0>)])]>

Human approval

After it passes all automated checks, every pull request must receive approval from a human reviewer. The reviewer is typically the skill's subject matter expert and, for new skills, a member of the Central Skills team.

Lessons learned from repository history

Six months of commit history and pull request discussions reveal several practical takeaways.

1. Scope CI checks carefully

Early in the project, we configured automated pull request checks with broad directory patterns.

One check required an approved bug tracking ticket on every change. Because the pattern matched too broadly, engineers making a one-line typo fix were blocked for missing a tracking ticket. Meanwhile, newly added skills in deeper subdirectories went uninspected.

Takeaway: Match automated check rules to specific file operations, such as added versus modified files, and verify exact path depths. Treat minor edits to existing skills differently from new skills.

2. Atomic expectations

When we started writing evaluation suites, we saw authors write compound expectations like this:

code_block: <ListValue: [StructValue([('code', '# Bad: Compound expectation\r\n- "The agent must create a Cloud Storage bucket in us-central1, enable\r\n uniform bucket-level access, and apply lifecycle rules."'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eea4350>)])]>

If the agent configured the region and lifecycle rules but missed the uniform access flag, the LLM-as-a-judge scorer returned inconsistent ratings.

Migrating to atomic expectations resolved the inconsistent ratings:

code_block: <ListValue: [StructValue([('code', '# Good: Atomic expectations\r\n- "The agent specifies us-central1 for the bucket location."\r\n- "The agent enables uniform bucket-level access on the created bucket."\r\n- "The agent defines a lifecycle configuration rule deleting objects\r\n older than 30 days."'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f70bbd0>)])]>

Takeaway: Check exactly one criterion per expectation. Atomic expectations make evaluation results clear, reliable, and debuggable.

3. Documentation drift happens fast

In a multi-contributor repository, documentation tables drift within days if maintained manually.

Takeaway: If you publish an index or catalog, never rely on contributors to update it manually. Instead, write a generator script and enforce it with a CI unit test. That's the origin of the README.md and index.json checks in our linters. Our index.json even opens with a warning: "This file is generated. Do not edit it by hand."

4. Gate expensive LLM checks behind fast deterministic ones

Running full evaluation suites and an AI review agent on every change can get expensive fast, both in token usage and CI runtime—especially when authors push frequent small commits during review.

In our pipeline, fast deterministic checks run first. Structural conformance, skill linters, and semantic versioning act as blocking gates: if any of them fail, the pipeline stops immediately and it won't trigger the AI reviewer or evaluation checks until those issues are fixed.

Takeaway: Stage your pipeline so cheap, deterministic checks block broken changes before LLM-powered gates run. When you build a similar system, consider adding further cost guardrails, such as manual triggers for heavy checks (for example, a /run-evals pull request comment) or only triggering automatic re-runs when the diff exceeds a specific threshold.

Conclusion

Building a scalable Agent Skills repository requires more than good prompt engineering. It requires solid developer infrastructure:

Ship skills like products: version, validate, and evaluate every change.
Enforce semantic versioning and atomic expectations with automated CI gates.
Use an AI reviewer to catch design anti-patterns, such as the deterministic trap.
Check links before merge and on a schedule.

Links and further reading

To get started with Google Agent Skills, check out these resources:

Google Agent Skills repo: github.com/google/skills
Previous post: Behind the scenes: How we build, test, and scale Google Agent Skills
Launch announcement: Level Up Your Agents: Announcing Google's Official Skills Repository
Skills tutorial: Introduction: What Are Google Cloud Agent Skills?

What's next?

If you found this post helpful, share it with your friends on social media and connect with me on LinkedIn, X, or Bluesky.

Thanks for reading!

How to troubleshoot GKE workloads faster with VPC Flow Logs

Wed, 28 Oct 2026 16:00:00 +0000

Having visibility into your network traffic is essential to operating Kubernetes environments effectively. When a service slows down or loses connectivity, knowing who is talking to whom lets you narrow the problem down quickly. In a standard cloud network, flow logs provide that view by recording connections between IP addresses, ports, and protocols. In Kubernetes, however, pods are temporary. Their IP addresses change constantly as pods scale, crash, or move between nodes, so a raw log entry showing 10.4.2.18 talking to 10.4.8.44 tells you little about which workload (and pod) owned that address, what namespace it was in, or what application it was trying to reach. By the time you search your cluster, the pod may already be gone!

In a Google Cloud environment, VPC Flow Logs closes this gap at the network layer. Google Cloud's virtual network already sees every connection a pod makes, so each sampled flow is recorded with the Google Kubernetes Engine (GKE) metadata behind the IP address: pod, workload, namespace, and service. You get workload-level attribution for L3/L4 traffic without deploying extra agents or sidecars, and it complements in-cluster Container Network Interface (CNI) and dataplane observability tools you may already run when you need deeper detail. Let’s take a deeper look at how VPC Flow Logs and GKE work together, and how to get started with it.

How GKE metadata enriches VPC Flow Logs

VPC Flow Logs samples traffic directly inside Google Cloud's virtual network. When flow logs are enabled for a subnet that hosts a GKE cluster, every record of pod traffic that passes through the VPC network is annotated with the Kubernetes context that owned the IP address at the time of sampling. This helps ensure the context is preserved even after the pod is gone:

Cluster: The cluster name and location.
Workload: The pod name and namespace, along with the controller that owns the pod, such as a deployment, StatefulSet, or DaemonSet.
Service name: The Kubernetes service that received the traffic.
Node and zone: The standard VPC fields, including the node VM and its zone on both ends of the flow.

If you register your GKE workloads in App Hub, each record also carries application-level labels (apphubSource and apphubDestination) that identify the business application, environment, and criticality of each endpoint. This is especially useful when GKE microservices talk to App Hub-registered resources outside the cluster, such as Cloud Run services.

Before you start

Upgrade your log bucket to Observability Analytics (formerly Log Analytics): Flow Analyzer reads only from an upgraded bucket, typically _Default. Note: This upgrade is permanent.
gcloud logging buckets update _Default \ --location=global \ --enable-analytics

Enable VPC Flow Logs organization-wide: One organization-level configuration covers every subnet in every VPC network, including future clusters (requires Network Management Admin role). Keep include-all-metadata on so every record carries namespace and pod details. To balance visibility against cost, you can add a secondary sampling rate (--flow-sampling), an aggregation interval (--aggregation-interval), or a filter expression (--filter-expr) to view only the traffic of interest.
gcloud network-management vpc-flow-logs-configs create CONFIG_NAME \ --location=global \ --organization=ORGANIZATION_ID \ --metadata=include-all-metadata

Turn on intranode visibility: Autopilot clusters already have it, but you need to enable it on Standard clusters. Note: Enabling it restarts control plane and node components and adds some per-node overhead, so test it on a non-production cluster first.
gcloud container clusters update CLUSTER_NAME \ --location=LOCATION \ --enable-intra-node-visibility

Now you’re ready to get started.

Analyze traffic visually in Flow Analyzer

VPC Flow Logs write every record to Cloud Logging, you can search and query it in Logs Explorer or Log Analytics. For day-to-day work, Flow Analyzer, part of Network Intelligence Center, turns the same records into an interactive chart and table, so you can group and filter traffic by cluster, namespace, workload, pod, or service in a few clicks.

The walkthroughs below use Online Boutique, an open-source microservices demo, on a GKE Autopilot cluster in us-central1. A loadgenerator deployment sends synthetic shopper traffic to the frontend, which calls productcatalogservice, cartservice, currencyservice, recommendationservice, shippingservice, adservice, and checkoutservice.

Case 1: Turn IP addresses into workload names
Whether you’re investigating an incident or assessing an architecture change, the first question is always the same: Which endpoints are communicating, and at what volume?

Rather than presenting ephemeral IP address pairs, GKE metadata allows Flow Analyzer to answer this question directly using Kubernetes workload names.

Steps in Flow Analyzer:

Open Network Intelligence Center > Flow Analyzer and set the time range to last 1 hour.
Under Source and Destination, set Organize flows by to GKE workload.
In the filter bar, add the GKE workload is known filter so only pod-to-pod traffic is shown.
Click Run new query.

Grouping traffic by Source GKE workload and Destination GKE workload in Flow Analyzer to map microservice dependencies without raw IP lookups.

Key insights: Sorted by volume, the table is a ready-made application dependency map: frontend handles incoming requests from loadgenerator (representing user traffic), while productcatalogservice answers calls from both recommendationservice and frontend. Because each row shows workload names instead of raw IP addresses, any unauthorized or unexpected workload-to-workload communication immediately becomes apparent.

Case 2: Drill into a single service
When a service is slow or about to change, you need to know who depends on it and how heavily.

Steps in Flow Analyzer:

Change Traffic aggregation to Client ↔ server (bidirectional), so requests and responses between a pair are counted together.
Under Server, add the filter GKE workload = productcatalogservice.
Click Run new query, then click Details on the top row.

Filtering on Server GKE workload (productcatalogservice) with Client ↔ server (bidirectional) aggregation to view caller share and the Details timeline.

Key insights: You get every caller of the catalog service, each caller's share of its traffic, and a timeline for every pair, so if one caller's line climbs while the others stay flat, you know where to look first. When the question is latency rather than volume, switch the display mode to latency to rank the same callers by round-trip time.

Case 3: Find the pods that talk across zones
In a regional GKE cluster, chatty services that land in different zones send every request across a zone boundary, adding inter-zone data transfer charges. Because VPC Flow Logs record the zone at both ends of every flow, the pod pairs driving that traffic are easy to spot.

Steps in Flow Analyzer:

Switch from Basic filters to SQL filters, which let you compare two fields of the same flow.
In the WHERE box, enter src_gcp_zone <> dest_gcp_zone.
Set Organize flows by to Source GCP zone, Source GKE pod, Destination GCP zone, and Destination GKE pod.
Click Run new query.

Using SQL filters with src_gcp_zone <> dest_gcp_zone and multi-attribute grouping to identify pod pairs driving cross-zone network traffic.

Key insights: The table displays cross-zone traffic ranked by volume, identifying the exact pods and zones on each end. In our cluster, the top flows occur between a frontend pod in us-central1-b and a currencyservice pod in us-central1-c, followed by checkoutservice, shippingservice, and productcatalogservice pairs. To investigate further, click Explore in Log Analytics to open the underlying SQL query for additional customization, such as adding joins or time buckets.

GKE has a built-in answer: set trafficDistribution: PreferSameZone (PreferClose on older versions) on the Service to prefer healthy endpoints in the caller's zone, and make sure each zone has enough replicas to serve its own traffic.

What to keep in mind

Pod-to-internet traffic: VPC Flow Logs carry no pod annotations, because the masquerade agent replaces the pod IP with the node IP before the flow is sampled. Keeping internal destinations in the non-masquerade list preserves pod names for those flows, and if you run ip-masq-agent with intranode visibility, that list must also include the cluster's node and pod IP ranges to avoid connectivity problems.
Blocked traffic: Traffic blocked by a network policy never reaches the VPC network, so use NetworkPolicy logging to investigate it.
Sampling: Flow logs are sampled, which makes byte and packet counts well suited for ranking and trending rather than per-connection accounting.

Next steps

If your clusters already have VPC Flow Logs turned on, upgrading the _Default bucket and opening Flow Analyzer is all it takes to reproduce the three walkthroughs above. To learn more, see the documentation:

How GKE networking scales to support high densities of concurrent AI agents

Wed, 28 Oct 2026 16:00:00 +0000

What do you need to orchestrate high-density concurrent AI agents? As we transition from static requests toward autonomous agentic workflows, the need for secure, high-density sandboxes is pushing conventional infrastructure far beyond its architectural breaking point. This transition is driving top-tier research labs to demand infrastructure at unprecedented scale — often up to one million concurrent code-execution sandboxes!

At this scale, the efficiency of your Kubernetes networking infrastructure directly impacts the economic viability of an agentic initiative. In advanced workflows like reinforcement learning (RL), extreme pod churn can mean thousands of isolated sandboxes spinning up and down every minute. To make sure that valuable GPUs and TPUs are spending their time executing models rather than waiting on sandboxes to initialize, you need sub-second provisioning and extreme compute density.

By providing secure, lightweight isolation, Agent Sandbox on GKE is uniquely positioned to power these highly dynamic execution environments. Furthermore, for next-generation workloads with millions of concurrent idle sessions, Agent Substrate on GKE builds on these primitives to deliver even greater density and sub-second state rehydration.

In this post, you will learn how GKE Dataplane V2 optimizes network identity management, solves identity scaling limits, and enables sub-second provisioning to power high-density, large-scale AI agent workloads.

A common scale challenge: network identity management

Operating with massive concurrency introduces fascinating new engineering challenges, particularly in how you manage network identities. Traditionally, custom controllers and workload orchestrators often assign unique, dynamic labels to each pod (such as agent-id, timestamps, or claim-uid). GKE Dataplane V2, powered by eBPF technology, helps enforce robust network security policies by mapping pod labels to a numeric identity. Because agentic workflows generate highly unique labels for every pod, the system proactively provisions a distinct identity for each sandbox. In a rapidly changing environment, this serial allocation process can briefly pause pod creation as the system securely updates eBPF maps, occasionally leading to slower-than-desired initialization. Additionally, sophisticated workloads can approach the cluster-wide limit of 65,536 network identities, either through this rapid generation or overall scale of the workload itself.

GKE network dataplane innovations for an agentic world

Providing a reliable and highly secure platform is fundamental to everything we do. As such, we needed to find a way to provide the same underlying identity and security controls while providing higher scalability and performance. That's where the architectural innovations in GKE Dataplane V2 come in. A customer has testified to the success of Agent Substrate on GKE to orchestrate hundreds of thousands of secure environments across clusters and handle spikes of over 30,000 sandboxes on a single cluster.

To achieve this, GKE relies on a two-pronged networking approach:

Migrating high-cardinality data

Google's GKE Dataplane V2 separates "identifying" data from "functional" metadata. Ensure your fields that do not actively participate in service selector matching or core resource grouping are migrated from the Pod's Labels set to the Annotations set. GKE Dataplane V2 intelligently calculates network identities based on labels rather than annotations, moving this high-cardinality metadata out of the labels completely bypasses the need for per-Pod identity generation. This elegant shift natively resolves identity scaling limits without sacrificing visibility.

Advanced Cilium label filtering

In addition, applying precise label exclusion filters (e.g., using the cilium-config-emergency-override ConfigMap in kube-system) by configuring rules like !agents.x-k8s.io/sandbox-name-hash or !timestamp, these explicitly instruct GKE Dataplane V2 to gracefully ignore these dynamic labels during security identity calculation.

This means that even if a developer framework inadvertently introduces high-cardinality labels, configuring appropriate exclusion filters allows Google’s network dataplane to drop them automatically.

As a result, identical agent types continue sharing a single Cilium pod identity, maintaining the ultra-low-latency startup times critical for dynamic AI workloads. By preventing linear identity growth and avoiding Cilium’s 65,536 identity limit, GKE provides leading speed and efficiency for fully isolated agents with 300 sandboxes per second at sub-second latency.

Looking ahead

For workloads that require extreme performance, scale, and density, Agent Substrate natively integrates these GKE Dataplane V2 recommendations while bypassing Kubernetes scheduling limits, pushing GKE’s performance and scale even further. In benchmark validation running 200,000 agents, Agent Substrate sustained 500 activations per second at less than 500 ms suspend and resume latency. You can deploy it on your existing GKE clusters today to minimize idle compute costs for your most demanding AI workflows.

By optimizing network identity calculation and filtering high-cardinality metadata, GKE Dataplane V2 addresses critical infrastructure bottlenecks in large-scale AI workloads. These architectural improvements reduce sandbox provisioning latency to sub-second levels, minimize expensive GPU idle times, and help maintain high compute density. Ultimately, these efficiencies let you scale your agentic AI operations reliably while controlling operational costs.

To learn more, explore Agent Sandbox and Agent Substrate on GKE.

Near-zero downtime upgrades: Announcing Cloud SQL for MySQL blue-green deployments

Wed, 28 Oct 2026 16:00:00 +0000

Keeping production databases on supported versions shouldn’t require giving up your weekend. To stay secure, compliant, and with the best performance and newest AI capabilities, organizations need to run on the latest database engine versions. Yet for many teams, major version upgrades mean weeks of cross-team coordination, negotiating narrow maintenance windows, and hours of application downtime. In an era where mission-critical applications and AI agents operate as 24/7 systems of action, even a brief maintenance outage can mean disrupted customer experiences and lost revenue.

To help, we are excited to announce the preview of fully managed blue-green deployments in Cloud SQL, starting with Cloud SQL for MySQL. You can now execute major version upgrades and configuration updates with minimal downtime via the Google Cloud console or automated CLI scripts. By continuously synchronizing a parallel environment, teams can safely test with production data before a seamless cutover — all while keeping the original database as a reliable safety net after the switchover.

Why the upgrade dilemma matters to your business

Putting off major version upgrades (like moving from MySQL 8.0 to 8.4) exposes you to security vulnerabilities and causes you to miss out on performance improvements and the latest AI capabilities. To test changes and avoid in-place upgrade downtime, teams often turn to a blue-green deployment — testing changes on a separate, upgraded staging copy (green) alongside the live database (blue) and switching traffic over once it’s ready. However, manual blue-green setups are incredibly complex to build, synchronize, and safely cut over.

Cloud SQL’s fully managed blue-green deployments can turn your database upgrades from a high-risk weekend project into a predictable, low-downtime operation.

The traditional upgrade	The managed blue-green way
Late-night maintenance: Scheduling hours of offline downtime at 2:00 AM on a Saturday.	Business-hour upgrades: Staging, sync, and testing happen in the background during normal work hours.
Limited testing options: Tests are limited to non-production environments, adding operational risks.	Pre-cutover verification: Safely testing actual applications against real-time production data copy before any traffic shifts.
High-stress rollbacks: If an issue is found, rebuilding or restoring from backups takes hours.	Built-in fallback: Cancel the upgrade and leave your blue instance as is if issues come up, or keep your “old blue” as a manual fallback after cutover.

The technical differentiators

With Cloud SQL, managed blue-green deployments automate the entire lifecycle across three stages:

Blue environment (production): Your current primary Cloud SQL instance, which continues serving live application traffic without interruption.
Green environment (staging): A temporary clone of your blue instance that Cloud SQL upgrades to your target database version and keeps in sync via continuous replication.
Switchover: When you're ready to cut over, Cloud SQL briefly sets the blue instance to read-only, finishes the final data synchronization, and promotes the green instance to your new primary database.

Three notable capabilities make this release a game-changer for enterprise workloads:

Near-zero downtime cutover: The transition from the old version to the new version is incredibly fast. Organizations using Cloud SQL Enterprise Plus experience sub-second downtime for maintenance.
No application changes: When you trigger the switchover, Cloud SQL automatically transfers your existing database IP address, instance name, and backups to the new database. Your developers do not need to rewrite connection strings, modify configuration files, or update client applications.
Safe, real-data testing: You can run real application traffic and queries against the upgraded green environment to verify performance before going live. If you spot an issue, simply delete the deployment before switchover without touching your live database.

Simple to orchestrate, built to scale

Upgrading your database environment can now be initiated in just a few clicks within the console, or via a simple CLI script.

code_block: <ListValue: [StructValue([('code', "# Create the synchronized, upgraded green deployment environment\r\ngcloud sql blue-green-deployments create my-upgrade \\\r\n --source-instance=prod-mysql-db \\\r\n --target-database-version=MYSQL_8_4\r\n\r\n# Check the status and get the test endpoint\r\ngcloud sql blue-green-deployments describe my-upgrade \\\r\n--region=us-central1\r\n\r\n# Connect and test the upgraded copy\r\ngcloud sql connect TARGET_INSTANCE_NAME --user=admin\r\n\r\n# Switch your live traffic to the upgraded database in seconds\r\ngcloud sql blue-green-deployments switchover my-upgrade\r\n\r\n# Clean up the old database when you're ready\r\ngcloud sql blue-green-deployments delete my-upgrade \\\r\n --region=us-central1 \\\r\n --delete-old-source"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f89f150>)])]>

With near-zero downtime switchovers, this feature takes the risk out of database upgrades. By shifting maintenance from a weekend chore to a routine daytime task, your team can stay ahead of security lifecycles, unlock the latest AI-ready engine features, and focus on building features that drive business growth, not managing infrastructure risk.

Try it today

Near-zero downtime database upgrades are available in preview for Cloud SQL for MySQL standalone primary instances, including High Availability configurations, with support for PostgreSQL coming soon.

Get started today by visiting the Cloud SQL console or reviewing the step-by-step documentation.

Step into a new dimension with XREAL AURA, the first-of-its-kind wired XR glasses

Wed, 28 Oct 2026 14:41:00 +0000

The world of work is rapidly evolving, and with it, the tools we use to stay productive and connected. As AI adoption transforms daily workflows, form factors like XR headsets and glasses offer fresh ways to reimagine how productive work happens across apps and devices.

Today marks the launch of XREAL AURA, a first-of-kind set of wired XR glasses built on Android XR. XREAL AURA’s form factor brings new and impressive features for enterprises such as:

Spatial computing on wired glasses using a newly introduced split-compute architecture.
An optical-see-through display with a 70-degree field of view that layers rich visual content directly onto your physical world, allowing you to stay connected.
A glasses frame weight of less than 95g, allowing for extended work sessions by employees.

Most importantly, AURA brings unique productivity benefits to users. Employees will have out-of-the-box support for enterprise apps, including popular titles currently available on the Google Play Store. And if the hundreds of Android productivity titles aren’t enough, you can also connect your laptop and bring those applications into your spatial environment as well. AURA’s displayport-in (DP-in) function makes it seamless to connect laptops across platforms directly alongside Android apps.

Management and security of Android XR devices are crucial for IT teams. We introduced Android Enterprise management on Android XR earlier this year, and XREAL AURA devices will be managed through the same framework. Key management and security features include:

Managed Google Play: Securely distribute and manage public and private business apps, to ensure that end users have all the tools they need.
Android zero-touch enrollment: Automatically deploy Android devices remotely out-of-the-box, to save time and enable enrollment at scale.
Device management: Support of fully managed device mode, to support configuration of core system resources like Wi-Fi, as well the ability to set system policies like disallowing apps.
Google Play Protect: Defend against threats with proactive machine-learning powered detection of malware, phishing and ransomware.
Core Android platform security: Multi-layered protections spanning from hardware to OS, with verified boot, and device encryption that keep devices protected from emerging threats with regular and modular security updates from Google.
Device Trust from Android Enterprise: Secures devices, respects privacy, and empowers employees to work from anywhere, including devices that may not be managed.

XREAL AURA allows users to easily see both the world around them as well as digital data at the same time. Because of its unique form factor, users can seamlessly switch between extended reality and interacting with their physical space. This unlocks new use cases for enterprise users that include:

Offering spatial productivity across virtual monitors visible only to the user and with 3D content
Getting help from virtual experts while working on a piece of equipment
Easily visualizing complex information on top of physical spaces
Designing and simulating products in 3D
Using voice to easily guide information from the physical world into digital systems of record

Android XR brings advanced computing and AI to daily work through powerful devices like the XREAL AURA wired glasses, all seamlessly managed by the secure and familiar Android Enterprise framework. This holistic approach ensures businesses can harness the full potential of XR today.

Interested to find out more about Android or have follow up questions, let us know in the Customer Community.

For more information on how XREAL AURA can transform the way you work, watch, and play, check out the For more information on how XREAL AURA can transform the way you work, watch, and play, check out the News from Google blog.

To purchase the device, check out the XREAL AURA shop.

_{XREAL AURA is only available for use by users in the United States, Canada, Japan, and South Korea. Additionally, it is only available for ages 18+. Some apps and features require download, setup, or subscription}

Introducing VMware solution on Google Cloud

Tue, 27 Oct 2026 20:00:00 +0000

Many organizations with workloads on VMware are looking for ways to expedite their data center exits, migrate and modernize their mission-critical workloads, or simply leverage the cloud as a secondary disaster recovery site. But they want to do so without altering existing operational playbooks.

Today, we are announcing the general availability of the VMware solution on Google Cloud, part of the Google Cloud Modernize portfolio, giving you full administrative authority for VMware Cloud Foundation (VCF) on dedicated Google Cloud bare metal.

This new deployment model complements our existing Google-managed service, offering you greater flexibility and architectural choice for running VMware workloads in Google Cloud. With this new self managed offering, organizations with dedicated operational practices maintain direct control over their virtualization stack, specific maintenance windows, and custom integration with third-party monitoring and management tools.

The launch of VMware Cloud Foundation 9.x by Broadcom is a key driver behind this self-managed deployment option. Featuring a unified VCF control plane for end-to-end stack deployment and lifecycle management, this solution enables Google Cloud customers to directly leverage Broadcom's latest innovations and fully maximize their licensing investments in VMware Cloud Foundation.

“Customers want the agility of Google Cloud without rearchitecting their VMware environments or abandoning the operational practices they have invested in. With the new VMware solution on Google Cloud, VCF license portability allows customers to bring their existing subscriptions and run their VMware workloads unchanged, with complete administrative control on dedicated Z3 bare metal and the ability to apply Google Cloud commitments and discounts to optimize their costs.” - Abhay Kumar, Global Head of Hyperscalers, VMware Cloud Foundation Division, Broadcom

Expanding deployment choices for VMware workloads

When it comes to VMware workloads, Google Cloud now offers two distinct choices tailored to your priorities, letting you choose the operational model that matches your workloads’ characteristics and the levels of control you need: Google Cloud VMware Engine, and the VMware solution on Google Cloud.

Capability	Google Cloud VMware Engine	VMware solution on Google Cloud
Target workloads	Turnkey operations prioritizing operational simplicity and offloaded maintenance	Architectural flexibility for teams requiring full stack customization and direct ownership
Underlying software	VMware Cloud Foundation 5.2	VMware Cloud Foundation 9.x
Administrative access	Role-based vCenter administrative privileges	Full root administrative access across ESXi, vCenter, NSX Manager, and rest of the VCF components
Lifecycle management	Automated patching, updates, and monitoring managed by Google	Customer-or partner-driven updates via VCF Operations Management tools
Licensing model	Bring Your Own License (BYOL) portable VCF subscriptions	Bring Your Own License (BYOL) portable VCF subscriptions
Hardware platform	VMware Engine ve1 and ve2 node families	Dedicated Compute Engine (GCE) bare metal instances (e.g Z3)

High-performance architecture on bare metal

The self-managed VMware solution is deployed on dedicated GCE Z3 bare metal instances (z3-highmem-192-highlssd-metal). Powered by 2.2 GHz - 4th Generation Intel Xeon Processors (Sapphire Rapids) processors, each node delivers:

96 physical cores (192 hyper-threads)
1.5 TB RAM
72 TB all-flash NVMe storage
200 Gbps networking

Operating natively within Google Cloud alongside GCE and Google Kubernetes Engine (GKE), this architecture provides high bandwidth and low-latency networking for transactional databases and direct access to native Google Cloud services, including BigQuery, the Gemini platform, Cloud Run, and more.

The solution's storage architecture is built on VMware vSAN hyperconverged infrastructure using high-performance, all-flash NVMe storage from Z3 nodes. Beyond standard storage, these drives can also be utilized for NVMe memory tiering. In addition to vSAN, the solution also supports NetApp volumes.

"VMware solution on Google Cloud gives enterprises greater control, choice, and architectural freedom as they move to the cloud. We are excited to expand our partnership with Google Cloud by offering NetApp Volumes as an external datastore. Together, we’re helping customers confidently migrate their VMware workloads and data to Google Cloud while retaining the flexibility, performance and data management capabilities they rely on.” - Pravjit Tiwana, SVP/GM, Cloud Storage, NetApp

Realizing clear customer value and TCO optimization

Pairing VMware Cloud Foundation 9.1 with Google Cloud’s Z3 bare metal infrastructure delivers significant economic and operational efficiency:

Commercial flexibility and BYOL: Bring portable Broadcom VCF subscriptions while allocating Google Cloud commitments and Flexible Committed Use Discounts (Flex CUDs) toward Z3 bare metal shapes.
NVMe memory tiering: Tiering between DDR memory (Tier 0) and high-speed local NVMe (Tier 1) can reduce server TCO by up to 40%.
vSAN Express Storage Architecture (ESA): Utilizing high-throughput local NVMe storage reduces storage TCO by up to 39% compared to traditional external arrays.
Active live patching: Up to 80% live patching coverage for critical security updates reduces planned maintenance downtime.

Architectural and commercial differentiation

In addition to the above-mentioned benefits, Google Cloud provides distinct operational and technical advantages that go beyond standard cloud hosting:

Triple-governance operational choices: Select from Google-, customer-, or partner- frameworks to align precisely with your operating model.
Granular capacity sizing: Access bare metal shapes across GCE hardware families to optimize utilization resulting in a lower TCO.
Global virtual networking: Peer complex multi-edge and multi-VPC topologies natively via Andromeda and Network Connectivity Center (NCC).
AI Acceleration: Seamlessly connect systems of record directly to BigQuery and Gemini platform to enable AI capabilities.

What our customers are saying

“Our early assessment shows significant potential. Separating the hardware lifecycle from the virtualization layer gives us the ability to scale bare-metal capacity in minutes, while still retaining full administrative control. This provides the flexibility of the cloud with the level of control we require from our infrastructure platforms.” - Scott Ronan, Senior Director of Platforms, Databases & Cloud, GXO Logistics

Partner-managed ecosystem

For organizations that prefer managed services, Google Cloud partners with organizations with expertise across both Google Cloud and VMware Cloud Foundation (VCF) to provide end-to-end support for self-managed VMware solution including:

Day 0: Architecture planning and solution design
Day 1: Deployment and migration execution
Day 2 and beyond: Ongoing lifecycle management and operations

Delivered via professional or managed services contracts, you can collaborate with your preferred providers or tap into our featured partner offerings on the self-managed VMware solution: Accenture, Advanced Business Computing, Cognizant, Devoteam, HCL, IBM, Infosys, Insight, LiverX, ModernZ, Pellera, Quantiphi, Tata Consultancy Services, Wipro, and Xtravirt.

Getting started

VMware solution on Google Cloud is generally available across 22 Google Cloud regions, with planned expansion to more regions in upcoming quarters.

To get started:

Visit the VMware solution on Google Cloud webpage for more details.
Review the solution overview and core concepts on the documentation page.
Reach out to your Google Cloud account team or an authorized partner to evaluate this offering.

Powering the agentic enterprise with latest innovations in Oracle AI Database@Google Cloud

Tue, 27 Oct 2026 19:30:00 +0000

For decades, core enterprise operations — from global supply chains and financial ledgers to billing engines — have relied on the performance and transactional integrity of Oracle databases. Today at Oracle AI World in Las Vegas, Google Cloud and Oracle are expanding our partnership across the AI stack — spanning AI compute and infrastructure (including making Google TPUs available through Oracle Cloud Infrastructure), enterprise data, and agentic AI — by deepening the integration between Oracle AI Database@Google Cloud, Google’s Agentic Data Cloud, and Gemini.

By unifying Oracle’s mission-critical operational data and applications with Google Cloud’s data and AI ecosystem — including BigQuery and Gemini models — enterprises can move beyond static analytics and build autonomous, agentic workflows. This architecture breaks down traditional data silos, giving agents direct, secure, and real-time access to the foundational enterprise data required to drive real-world action.

Foundational building blocks for agentic AI

To unlock production-grade agentic AI, enterprises need more than raw model capability — they need strong database connectivity, unified data governance, and rich semantic context working together as a cohesive foundation. First announced at Google Cloud Next '26, the following core capabilities serve as the building blocks for building conversational intelligence, end-to-end governance, and autonomous agent environments on Oracle AI Database@Google Cloud:

Remote MCP Server with Data API: The Remote Model Context Protocol (MCP) Server for Oracle workloads — powered by the IAM-governed ExecuteSQL Data API — is now generally available. Together, they provide a unified, standardized interface that enables AI agents, Google Cloud services, and enterprise applications to securely run SQL and interact directly with Oracle databases. By resolving database credentials automatically through Secret Manager and enforcing Google Cloud IAM policies, this capability eliminates the need for custom natural-language-to-SQL middleware, bastion VMs, or plaintext passwords.
Knowledge Catalog integration: Google Cloud’s Knowledge Catalog integration, currently in preview, unifies enterprise metadata discovery and governance across Oracle databases and the broader Google Agentic Data Cloud. By automatically cataloging schemas and business metadata, organizations can enforce consistent access controls, track data provenance, and supply the rich semantic context that agents require to reason accurately over complex operational data. Click here to sign-up for this feature.

Gemini connector for Oracle AI Database@Google Cloud

Building directly on the foundational capabilities discussed above, we’re also announcing the preview of Gemini connector for Oracle AI Database@Google Cloud. With this native integration, business users and developers can interact directly with their Oracle databases on Oracle AI Database@Google Cloud using natural language queries right inside the Gemini app. Behind the scenes, Gemini automatically leverages Knowledge Catalog to discover, search, and ground responses strictly in the governed Oracle data each user is authorized to access — turning complex operational databases into an intuitive, conversational experience without compromising enterprise security. Click here to sign-up for this feature.

Oracle in Gemini and Gemini in Oracle

Beyond direct database queries, Google Cloud and Oracle are connecting agentic workflows across the broader application layer — bringing Oracle data into Gemini and embedding Gemini models natively inside Oracle applications:

Oracle in Gemini: Available today, Oracle in Gemini introduces conversational analytics, cross-cloud database connectors, and domain-aware agents — including the new Oracle AI Database Agent in Gemini. Anchored by over 135 pre-built operational and developer skills and standardized MCP connectivity with zero plaintext credentials, enterprises can orchestrate multi-agent workflows across JD Edwards, E-Business Suite, NetSuite, and Oracle Fusion without custom SQL or brittle middleware.
Gemini models in Oracle applications: Concurrently, Gemini frontier reasoning is embedded directly into Oracle Fusion AI Agent Studio, Fusion Claw, Oracle Fusion Applications, and NetSuite — combining Oracle database intelligence with Gemini’s agentic capabilities to automate execution across transactional systems of record.
Partner-ready agentic blueprints: To help organizations rapidly deploy these governed workflows, Google Cloud and Oracle are collaborating with leading partners and global systems integrators — including Argano, Automus, Calfus, HCL, IBM, Infosys, LTM, Pythian, TCS, and Tessell — who provide pre-built operational skills, custom MCP connectors, and industry blueprints for production-grade agentic architectures.

Empowering choice with lakehouse, streaming, and federation

Every enterprise has distinct architectural priorities, latency thresholds, and governance requirements when connecting operational Oracle data to BigQuery and AI workloads. Rather than prescribing a one-size-fits-all integration pattern, Google Cloud and Oracle offer a complete spectrum of data unification choices so customers can select — or combine — the exact approach that best fits their workload and use case:

Bi-directional Google Cloud borderless Lakehouse and Oracle AI Lakehouse

Modern enterprise data architectures are increasingly multi-cloud and grounded in open standards. Building on our strategic partnership, Google Cloud and Oracle delivered a key innovation earlier this year to support cross-cloud data interoperability powered by open Apache Iceberg standard: integrating Google’s borderless Lakehouse with Oracle AI Lakehouse.

This work enabled the borderless Lakehouse to read Apache Iceberg tables created by Oracle AI Lakehouse across any public cloud or on-premises environment, leveraging catalogs and storage supported by both platforms.

Today, we are advancing it further by making it fully bi-directional with Oracle Access to Google Cloud borderless Lakehouse (preview). Now, Oracle Autonomous AI Database and Google’s borderless Lakehouse (powered by BigQuery and Managed Spark) can directly query and execute write/DML operations on shared Apache Iceberg tables in Google Cloud Storage, completely eliminating the need for ETL or data replication.

By utilizing a Lakehouse runtime REST catalog integrated into Oracle via DBMS_CATALOG, this bi-directional integration delivers an open-standards storage framework while empowering analytical teams (using BigQuery and Gemini) and operational teams (using Oracle SQL) to collaborate over a single, unified source of truth. You can click here to sign-up for this feature.

Sub-second CDC streaming with OCI GoldenGate

For organizations that prefer to continuously reflect mission-critical operational data inside BigQuery for high-scale analytics and AI, real-time change data capture (CDC) provides an immediate competitive edge. Through native OCI GoldenGate integration, CDC events are extracted directly from Oracle redo logs without touching table blocks or adding overhead to transactional workloads. Transactions stream securely across Google Cloud private networks straight into BigQuery managed tables, delivering sub-second analytical freshness to power Gemini, feature stores, and live business intelligence dashboards, while also streamlining migrations from on-premises environments to Oracle AI Database@Google Cloud.

BigQuery query federation with Oracle

When workloads call for on-demand operational visibility or infrequent cross-estate joins without moving data, BigQuery query federation with Oracle, in preview, enables real-time, in-place analytics directly against live Oracle databases. Using the EXTERNAL_QUERY function, data teams can execute native Oracle SQL directly from BigQuery queries, dashboards, and pipelines to retrieve live transactional records and join them easily with petabyte-scale BigQuery datasets. This zero-copy approach simplifies operations and lowers Total Cost of Ownership (TCO) by eliminating duplicate storage and ETL maintenance for ad-hoc lookups, intraday risk reporting, and live fraud detection. Please reach out to your Google Cloud account team if you want to sign-up for this feature.

Architectural option	Mechanism	Data Freshness and Latency	Impact on Oracle OLTP	Primary Use Case
Bi-Directional Borderless Lakehouse	Shared Apache Iceberg tables via Lakehouse runtime REST catalog (DBMS_CATALOG) and Glue Federation	Real-time shared storage (zero copy)	Zero (shared analytical storage layer)	Multi-cloud open interoperability, unified BigQuery/Spark/Oracle SQL access without vendor lock-in
Real-Time CDC via OCI GoldenGate	Continuous log-based streaming into BigQuery via Storage Write API	Near real-time / Sub-second (< 1s)	Zero (non-invasive extraction from redo logs)	Mission-critical operational reflection in BigQuery, live AI feature stores, continuous ML and BI pipelines
BigQuery Query Federation (Preview)	In-place query execution using EXTERNAL_QUERY via BigQuery Connection API	On-demand / Live in-place	Variable (query-dependent)	Infrequent ad-hoc querying, zero-copy lookups, cross-estate joins, regulatory reporting

Global expansion and public sector compliance

We continue to expand the global physical footprint and compliance boundaries of Oracle AI Database@Google Cloud to meet customers wherever they operate, with new regions and certifications.

New regions launched

The europe-west12-a(Turin, Italy) and northamerica-south1-b(Queretaro, Mexico) regions are now live, joining global hubs including Milan, Iowa, São Paulo, Tokyo, Sydney, and Mumbai to deliver ultra-low-latency access and local data residency.

FedRAMP High certification

At Oracle AI World, Oracle announced plans to pursue FedRAMP High certification for Oracle AI Database@Google Cloud. This initiative will allow US government and public sector entities to run regulated workloads using Oracle Exadata Database Service on dedicated infrastructure within Google Cloud Assured Workloads.
Operating inside a FedRAMP High-authorized environment enables federal agencies to safeguard sensitive, unclassified data while co-locating Oracle workloads with existing applications and Gemini. Agencies can access live Oracle data with minimal latency, streamlined billing, and simplified procurement via Google Cloud Marketplace or certified partners — all within their compliance boundaries.

Building the agentic future

By combining Oracle’s proven transactional engine with Google’s Agentic Data Cloud, enterprise data transitions from passive systems of record into an active, intelligent operational engine. Whether unifying data through open Apache Iceberg lakehouses, streaming sub-second changes via GoldenGate, federating live queries from BigQuery, or conversing directly with governed Oracle data through Gemini, organizations now have the complete flexibility and security required to deploy autonomous AI agents at scale — driving predictive insights and automated actions across their most critical business processes.

Get started today

Oracle AI Database@Google Cloud is available directly through the Google Cloud Marketplace, allowing you to deploy using your existing Google Cloud commitments, unified billing, and Oracle Support Rewards.

To explore further, visit the Oracle AI Database@Google Cloud overview, dive into the official Oracle Database@Google Cloud Documentation, or reach out to your Google Cloud account team to schedule an architecture briefing.

Securely connecting Gemini Enterprise to Snowflake data

Tue, 27 Oct 2026 16:00:00 +0000

Enterprise AI needs to go beyond simple chat interfaces. To provide real value, AI agents must access your data warehouses to generate actionable insights, all while maintaining strict security and data governance.

This guide explores how to build a secure bridge between Google Cloud’s Gemini Enterprise and Snowflake. By using the Model Context Protocol (MCP) and the Google Agent Development Kit (ADK), you can empower your agent to act as an assistant that understands natural language, generates precise SQL via Snowflake Cortex and executes queries with user-level permissions.

Choosing the right integration pattern

Direct Connection vs. custom orchestration

The Google ADK architecture demonstrated in this post represents the advanced / custom orchestration pattern. It is designed for developers building complex, multi-agent systems on Google Cloud, such as workflows that combine Snowflake insights with external enterprise tools, custom reasoning loops, or cross-platform state management in Gemini Agent Engine.

For standard enterprise basic use cases where you want to connect Gemini Enterprise directly to Snowflake use the joint solutions mentioned in this link.

The architectural approach

This architecture allows a business user to ask questions like, "What were our top 5 selling items in Texas last quarter?"

Rather than exposing raw SQL execution to the client, the agent delegates both query generation and execution to a governed Snowflake Cortex Agent exposed through the Snowflake MCP server:

Governed translation: The ADK agent passes the user's natural language question to the Snowflake MCP server, which invokes the Cortex Agent (CORTEX_AGENT_RUN) backed by Cortex Analyst semantic view.
Direct execution within the governed boundary: The Cortex Agent translates the question into SQL and executes it directly inside Snowflake using the authenticated user's OAuth session and role privileges, returning the structured results to the ADK agent.

This approach provides deterministic text-to-SQL translation mapped to your corporate semantic definitions, keeps query execution inside Snowflake's governed boundary, and reduces the risk of schema hallucinations or unvalidated SQL execution.

System architecture flow

The diagram below illustrates the trust boundaries and the numbered flow of execution between the Gemini Enterprise app and Snowflake ecosystems.

Detailed execution sequence

To highlight how the agent delegates natural language query translation and governed execution to the Snowflake Cortex Agent over MCP, see the sequence diagram below:

Step 1: Setting up the Snowflake security integration

A major risk in enterprise AI is granting the model broad access via a generic service account, which could allow users to bypass security restrictions. We solve this by using OAuth 2.0 to perform user impersonation.

First, establish a confidential OAuth client in Snowflake to protect the client secret. The snippet below configures the security integration inside Snowflake:

code_block: <ListValue: [StructValue([('code', "USE ROLE ACCOUNTADMIN; \r\nCREATE OR REPLACE SECURITY INTEGRATION <SECURITY_INTEGRATION_NAME> \r\nTYPE = OAUTH \r\nENABLED = TRUE \r\nOAUTH_CLIENT = CUSTOM \r\nOAUTH_CLIENT_TYPE = 'CONFIDENTIAL' \r\n-- Google Cloud's official handshake receiver address: \r\nOAUTH_REDIRECT_URI = 'https://vertexaisearch.cloud.google.com/oauth-redirect' \r\nOAUTH_ISSUE_REFRESH_TOKENS = TRUE \r\n-- Let the connection stay alive for 90 days (max Snowflake allowed limit) \r\nOAUTH_REFRESH_TOKEN_VALIDITY = 7776000;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f9d6f10>)])]>

To retrieve the generated client credentials needed for the Google Cloud configuration, run the following command in Snowflake:

code_block: <ListValue: [StructValue([('code', "-- Retrieve OAuth Client ID and Client Secret\r\nSELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<SECURITY_INTEGRATION_NAME>');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eb6ecd0>)])]>

Step 2: Data governance and access control

Apply the principle of least privilege by creating a dedicated role for your agent inside Snowflake.

code_block: <ListValue: [StructValue([('code', 'USE ROLE SECURITYADMIN;\r\n-- 1. Create a dedicated role\r\nCREATE ROLE IF NOT EXISTS <GENAI_ROLE_NAME>;\r\nGRANT ROLE <GENAI_ROLE_NAME> TO USER <BUSINESS_USER_NAME>; \r\nUSE ROLE SYSADMIN;\r\n-- 2. Grant structural access\r\nGRANT USAGE ON DATABASE <DATABASE_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\nGRANT USAGE ON SCHEMA <DATABASE_NAME>.<SCHEMA_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 3. Grant compute access\r\nGRANT USAGE ON WAREHOUSE <WAREHOUSE_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 4 .Grant access to the semantic layer\r\nGRANT SELECT, REFERENCES ON SEMANTIC VIEW <DATABASE_NAME>.<SCHEMA_NAME>.<SEMANTIC_VIEW_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 5. Grant select privileges on underlying raw data tables\r\nGRANT SELECT ON ALL TABLES IN SCHEMA <DATABASE_NAME>.<SCHEMA_NAME> TO ROLE <GENAI_ROLE_NAME>;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f995f10>)])]>

IMPORTANT

The user context must have SELECT privileges on the physical tables backing the semantic view. Granting access only to the semantic view will cause runtime errors during query execution.
If granting direct access to base tables is not permitted by your security policy, place a Snowflake Secure View over the physical tables and build the Semantic View on top of it. Because Snowflake views execute with Owner's Rights, the user's GenAI role only needs SELECT privileges on the Secure View and Semantic View rather than the raw tables.
Snowflake OAuth tokens capture and bind to the user's DEFAULT_ROLE and DEFAULT_WAREHOUSE at the exact moment of authorization. If a user authorizes the connection before these defaults are configured, the session will be locked to the wrong role(role available at that time) and query execution will fail if the intended role will not have required privileges.
- Set defaults(as shown below) prior to authorizing in Gemini Enterprise.
- Authorize connection: Have the user perform the one-time OAuth authorization in Gemini Enterprise.
- (Optional) Revert defaults: Once authorized, the user can safely revert their default role and warehouse in Snowflake back to their standard operational preferences.

code_block: <ListValue: [StructValue([('code', "ALTER USER <BUSINESS_USER_NAME> SET DEFAULT_ROLE = '<GENAI_ROLE_NAME>';\r\nALTER USER <BUSINESS_USER_NAME> SET DEFAULT_WAREHOUSE = '<WAREHOUSE_NAME>';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f996710>)])]>

Step 3: Provisioning the Cortex Agent and MCP server inside Snowflake

Next, create a governed Cortex Agent in Snowflake using your semantic view, then provision an MCP server that exposes the agent via the CORTEX_AGENT_RUN tool type. This approach delegates both SQL generation and query execution to Snowflake while enforcing the caller's OAuth identity and role permissions.

code_block: <ListValue: [StructValue([('code', 'USE DATABASE <DATABASE_NAME>;\r\nUSE SCHEMA <SCHEMA_NAME>;\r\nUSE ROLE SYSADMIN;\r\n\r\n-- 1. Create the Cortex Agent over your semantic view\r\nCREATE OR REPLACE AGENT <AGENT_NAME>\r\n COMMENT = \'Governed data assistant for business queries\'\r\n PROFILE = \'{"cortex_analyst": {"semantic_models": ["<DATABASE_NAME>.<SCHEMA_NAME>.<SEMANTIC_VIEW_NAME>"]}}\';\r\n\r\n-- 2. Provision the MCP Server exposing the Cortex Agent\r\nCREATE OR REPLACE MCP SERVER <SERVER_NAME>\r\nFROM SPECIFICATION $$\r\ntools:\r\n - name: "run_cortex_agent"\r\n type: "CORTEX_AGENT_RUN"\r\n identifier: "<DATABASE_NAME>.<SCHEMA_NAME>.<AGENT_NAME>"\r\n title: "Cortex Agent Assistant"\r\n description: "Converts natural language questions into SQL and executes them directly within Snowflake using the caller\'s OAuth session permissions."\r\n$$;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5faeb610>)])]>

ISOLATION & GOVERNANCE NOTE: By using CORTEX_AGENT_RUN, query generation and execution remain fully contained within Snowflake's governed security boundary. Avoid exposing raw execution tools like SYSTEM_EXECUTE_SQL to external clients, as doing so introduces unnecessary security surface area and bypasses centralized Cortex Agent governance.

Step 4: Locating and constructing the MCP server URL

The ADK code requires the endpoint URL of your Snowflake-managed MCP server. Now that the server is provisioned, you must first grant access to the server, and then you can retrieve its exact endpoint URL using the following query in a Snowflake worksheet:

code_block: <ListValue: [StructValue([('code', '-- 1. Grant access to the Cortex Agent and the MCP server\r\nUSE ROLE SECURITYADMIN;\r\nGRANT USAGE ON AGENT <DATABASE_NAME>.<SCHEMA_NAME>.<AGENT_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\nGRANT USAGE ON MCP SERVER <DATABASE_NAME>.<SCHEMA_NAME>.<SERVER_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 2. View the MCP URL\r\nDESCRIBE MCP SERVER <DATABASE_NAME>.<SCHEMA_NAME>.<SERVER_NAME>;\r\n-- Or:\r\nDESC MCP SERVER <DATABASE_NAME>.<SCHEMA_NAME>.<SERVER_NAME>;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eea5210>)])]>

In the command output, inspect the metadata properties to locate the endpoint link. The URL is structured as follows:

code_block: <ListValue: [StructValue([('code', 'https://<org_name>-<account_name>.snowflakecomputing.com/api/v2/databases/<database_name>/schemas/<schema_name>/mcp-servers/<server_name>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5eea49d0>)])]>

Step 5: Connecting via Google ADK

With the MCP Server created and its URL resolved, write your agent code using the Google Agent Development Kit (ADK). In your Python code, define the unique identifier AUTH_ID (e.g. snowflake_oauth_conn) that the agent will use to extract user credentials.

code_block: <ListValue: [StructValue([('code', 'import os\r\nimport re\r\nfrom typing import Optional\r\nfrom google.adk.agents.llm_agent import LlmAgent\r\nfrom google.adk.tools.mcp_tool.mcp_toolset import McpToolset\r\nfrom google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams\r\nfrom google.adk.tools.tool_context import ToolContext\r\n\r\n# Define the Auth ID first in your code. \r\n# You will use this exact name when registering the agent in the Google Cloud Console.\r\n# Gemini Enterprise maps the authorization token to this identifier in the ToolContext.\r\nAUTH_ID = "snowflake_oauth_conn" \r\n\r\n# 1. OAuth Header Extraction:\r\n# Define a callback to dynamically extract the user\'s OAuth token injected by Gemini Enterprise \r\n# and generate the Authorization headers required to authenticate with the Snowflake MCP.\r\ndef get_auth_headers(tool_context: Optional[ToolContext] = None) -> dict: \r\n """ \r\n OAuth Handling Callback: Dynamically extracts the user\'s OAuth token injected by Gemini Enterprise and generates the headers required to authenticate with the Snowflake MCP. \r\n """ \r\n token = None \r\n if tool_context and hasattr(tool_context, "state"): \r\n try: \r\n # Parse the state dictionary injected by Gemini Enterprise containing authorization states \r\n state_dict = tool_context.state.to_dict() if hasattr(tool_context.state, \'to_dict\') else tool_context.state \r\n pattern = re.compile(fr".*{re.escape(AUTH_ID)}.*", re.IGNORECASE) \r\n # Find the active token matching our Auth ID (snowflake_oauth_conn)\r\n matching_keys = [k for k in state_dict.keys() if pattern.match(k)] \r\n if matching_keys: \r\n token = state_dict.get(matching_keys[0]) \r\n except Exception as e: \r\n print(f"Warning: Failed to read ToolContext OAuth state: {e}") \r\n # Return authorization headers. If token is None, requests to MCP will fail.\r\n return { \r\n "Authorization": f"Bearer {token}", \r\n "Content-Type": "application/json", \r\n "Accept": "application/json, text/event-stream", \r\n } \r\n\r\n# 2. MCP Initialization:\r\n# Define the Snowflake MCP URL retrieved from \'DESCRIBE MCP SERVER\' directly in the code:\r\nMCP_SERVER_URL = "<YOUR_MCP_SERVER_URL>" # Replace with the URL retrieved from \'DESCRIBE MCP SERVER\' \r\n\r\n# Initialize the Snowflake MCP Toolset using this URL.\r\nsnowflake_mcp = McpToolset( \r\n connection_params=StreamableHTTPConnectionParams( \r\n url=MCP_SERVER_URL \r\n ), \r\n header_provider=get_auth_headers\r\n) \r\n\r\n# 3. Build the Agent:\r\n# Construct the LlmAgent using the Gemini 2.5 Flash model and attach the Snowflake MCP Toolset.\r\nroot_agent = LlmAgent( \r\n model="gemini-2.5-flash", \r\n name="enterprise_data_analyst", \r\n instruction=( \r\n "You are an enterprise data analyst. Use the `enterprise_data_agent` tool " \r\n "on the Snowflake MCP server to answer business questions. Pass the user\'s " \r\n "natural language question to the tool, which translates it into SQL and " \r\n "executes it directly within Snowflake\'s governed boundary, then present " \r\n "the results clearly to the user." \r\n ), \r\n tools=[snowflake_mcp]\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ee7fc50>)])]>

NOTE: The Python snippet above represents a plain/vanilla version of the agent setup. Depending on your organization's specific requirements, you should add robustness on top of this template (e.g., custom error handling, structured schemas, custom prompts, configurations, and additional tool wrappers).

Step 6: Project structure and deployment

To deploy your ADK agent to Agent Runtime in Agent Platform, organize your files in the following directory layout:

code_block: <ListValue: [StructValue([('code', 'snowflake_agent/\r\n├── agent.py # The agent definition and MCP connection code (from Step 5)\r\n├── __init__.py # Package initializer exposing the agent\r\n├── .env # Environment configurations (Google Cloud Project, etc.)\r\n└── requirements.txt # List of project dependencies (google-adk, etc.)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f75f250>)])]>

File details

__init__.py: Exposes the root_agent object to the deployment CLI:

code_block: <ListValue: [StructValue([('code', '# Snowflake ADK Agent package\r\nfrom .agent import root_agent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f7c4390>)])]>

.env: Declares environment configuration:

code_block: <ListValue: [StructValue([('code', 'GOOGLE_CLOUD_PROJECT="<YOUR_GCP_PROJECT_ID>"\r\nGOOGLE_CLOUD_LOCATION="<LOCATION>"\r\nGOOGLE_GENAI_USE_VERTEXAI="TRUE"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ee82290>)])]>

requirements.txt: Specifies dependencies:

code_block: <ListValue: [StructValue([('code', 'google-adk[mcp]==2.3.0\r\ngoogle-genai==2.10.0\r\npydantic-settings==2.14.2\r\ngoogle-cloud-aiplatform[agent_engines]>=1.50.0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ee83c90>)])]>

2. Deploying via the CLI

Rather than running complex custom Python scripts or manual container builds, you can deploy using the official Google Agents CLI (agents-cli). The CLI packages your code, sets up the server, and handles the deployment pipeline:

code_block: <ListValue: [StructValue([('code', '# Deploy the agent to the Google Cloud Agent Runtime\r\nagents-cli deploy --deployment-target agent_runtime'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ee83a90>)])]>

The CLI automatically handles the deployment lifecycle. Once complete, it outputs the unique project resource path (e.g., projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID) which you will use to register the agent in the next step.

TIP: For more information and advanced configuration options for ADK agent deployment, refer to:

Step 7: Registering the custom agent in Gemini Enterprise

Once the agent code is ready and deployed, register the agent in the Google Cloud Console. Here, you will link the agent configuration and map the OAuth parameters retrieved from your Snowflake Security Integration.

Extracting the OAuth Endpoints from Snowflake

Run this query in Snowflake to extract the precise Token and Authorization endpoints:

code_block: <ListValue: [StructValue([('code', 'DESCRIBE SECURITY INTEGRATION <SECURITY_INTEGRATION_NAME>;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5ebd3690>)])]>

In the results, locate the values for the following properties:

OAUTH_AUTHORIZATION_ENDPOINT: Your Snowflake Authorization URI.
OAUTH_TOKEN_ENDPOINT: Your Snowflake Token URI.

2. Registration steps in Google Cloud console

Go to the Gemini Enterprise page in the console.
Select the application you want to register the agent with.
In the left navigation, click Agents, then click + Add agent.
Select Add for Custom agent via Agent Platform. The Authorizations setup displays.
Set up the Snowflake OAuth connection:
- Click Add authorization.
- Authorization name: Enter the exact ID you defined in your ADK code (e.g., snowflake_oauth_conn). This ensures the credentials map correctly to the code's AUTH_ID.
- Client ID & Client secret: Input the credentials you retrieved from Snowflake using the SYSTEM$SHOW_OAUTH_CLIENT_SECRETS query.
- Token URI: Input the exact token endpoint value extracted from DESCRIBE SECURITY INTEGRATION.
- Authorization URI: Take the authorization endpoint value extracted from DESCRIBE SECURITY INTEGRATION and append ?response_type=code at the end (along with your client ID and scope query parameters, for example):

code_block: <ListValue: [StructValue([('code', 'https://<org_name>-<account_name>.snowflakecomputing.com/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=https%3A%2F%2Fvertexaisearch.cloud.google.com%2Foauth-redirect&scope=session%3Arole-any&response_type=code'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf5f8b3590>)])]>

IMPORTANT
Ensure the Authorization URI ends with &response_type=code (or ?response_type=code if there are no other parameters). This parameter is required by Google Cloud to trigger the OAuth 2.0 authorization code flow.

Click Done, then click Next.

6. Configure the agent properties:

7. Click Create to complete registration.

Understanding identifier alignment

ADK Code AUTH_ID <==> Google Cloud Authorization Name: The AUTH_ID in your Python script must exactly match the Authorization Name/ID you input during console registration. Because we write code first, we reuse the code-defined identifier during registration.
Snowflake Security Integration Name (e.g. <SECURITY_INTEGRATION_NAME>): This is purely a Snowflake-side database object name. It does not need to match the Google Cloud Authorization Name or the AUTH_ID in your ADK Python code.

Get started

By uniting the Gemini model’s reasoning capabilities, ADK's orchestration, and Snowflake's governed data layer, you can safely bring AI to your data. This architecture provides an agentic assistant that respects your security perimeters while delivering business value.

Scale agents securely with IAM Helper Agent Skills and MCP Tools

Tue, 27 Oct 2026 16:00:00 +0000

As organizations adopt autonomous agents to build applications, securing identities and access has become more challenging. Developers relying on agents to provision cloud resources, write Terraform, and deploy microservices at machine-speed only find their CI/CD pipelines blocked even faster as security friction scales.

To help you get ahead of agentic-era Identity and Access Management, today we’re introducing IAM Helper. This suite of intelligent, agent-facing building blocks can automate complex, end-to-end IAM workflows.

As an agent-native orchestration and interface layer for Google Cloud IAM, it augments Google Cloud’s core IAM engines — including Policy Intelligence and Privileged Access Manager (PAM) — making IAM skills callable directly by autonomous code assistants, deployment pipelines, and custom agents. Using this functionality reduces the administrative overhead of maintaining least-privilege security and agent governance, while maximizing utility, and accelerating deployment.

IAM Helper Agent Skills: Fast, secure deployment with automated governance

Manual troubleshooting of permission blockers creates friction for engineering and administrators, while shortcuts can lead to broad agent over-permissioning that puts least privilege at risk.

IAM Helper empowers agents to handle access management dynamically. It shifts the burden of policy evaluation away from human administrators and LLMs, offloading complex orchestration directly to the Google Cloud backend, to maximize token efficiency and prevent costly operational bottlenecks.

Rather than operating as isolated utilities, IAM Helper Agent Skills guide agents through the cloud access lifecycle. These end-to-end workflows, helper scripts, and guardrails packaged using the open Agent Skills standard can orchestrate multiple underlying functions and APIs to resolve complex IAM tasks. They work across common agents (Gemini CLI, Gemini Cloud Assist, ADK, Claude Code, and Cursor).

Built-in guardrails and real-world impact

Every IAM Helper agent skill separates read-only discovery from policy changes: Diagnostics and simulations run automatically, while any change to access policies pauses for human-in-the-loop (HITL) confirmation based on customizable risk tiers. To see the value of IAM Helper in practice, consider how it transforms two everyday scenarios:

Scaled user-assisted remediation: Suppose a developer's coding agent hits a 403 error while deploying a new application. Rather than filing a support ticket and idling, the agent uses iam-helper-for-troubleshooting to identify the missing Pub/Sub permission in seconds, then uses iam-helper-for-privileged-access-management to request a one-hour JIT grant, eliminating hours of debugging friction.
Autonomous pipeline self-healing: An infrastructure agent encounters a permission block during a routine deployment pipeline. Rather than failing the build, the pipeline uses IAM Helper Agent skills to generate a revised, least-privilege policy, verifies against 90 days of logs via iam-helper-for-policy-simulator that active services won't break, and routes the change to an admin for quick approval.

IAM Helper Agent Skills are designed for maximum token and cost efficiency, allowing agents to execute multi-step administrative operations autonomously.

Authoring compliant, least-privilege policies: As DevOps engineers translate access requirements into JSON, YAML, or Terraform HCL, iam-helper-for-policy-management generates and validates IAM v1 allow bindings and IAM v2 deny rules. It automatically catches and blocks risky configs before they are applied, including public access (allUsers) and broad basic roles (roles/owner, roles/editor).
Unblocking 403 errors in seconds: When an on-call engineer or deployment agent hits a cryptic 403 PERMISSION_DENIED error, iam-helper-for-troubleshooting identifies the exact missing permission or blocking rule in seconds. It adapts to the user’s role: Developers can check if they can unblock themselves locally or generate a structured ticket for their administrator (Requester flow), while security administrators can trace inherited allow and v2 deny rules across organization, folder, and project hierarchies to resolve the issue (Resolver flow).
Simulating blast radius before rolling out changes: Before a platform engineer updates a policy or applies IAM Recommender role reductions, they need confidence that active workloads won't break. iam-helper-for-policy-simulator walks the agent through a structured plan, simulate, analyze, and apply flow, testing proposed changes against 90 days of historical access logs to confirm existing traffic won't be disrupted before any update takes effect.
Elevating access just-in-time instead of granting standing privileges: When responders or maintenance agents need temporary production access, iam-helper-for-privileged-access-management manages the lifecycle of on-demand credentials through Privileged Access Manager (PAM). It supports requester, administrator, and approver workflows so elevated access is audited, time-bound, and automatically revoked once the task is done.

While IAM Helper Agent Skills supply the high-level workflow logic, they are all based on a common set of foundational MCP Tools.

Powered by Google Cloud IAM MCP tools

Google Cloud IAM Helper MCP tools provide the backend connection through atomic, read-only functions exposed via Google-managed MCP servers across core IAM endpoints (Policy Troubleshooter, Policy Analyzer, Policy Simulator, and IAM v1/v2 APIs).

Rather than requiring teams to write custom API wrappers, MCP tools give agents a standard way to query the cloud backend and get exact answers without parsing verbose policy documents in the prompt, maximizing token efficiency. Agents can dynamically discover and invoke these tools to execute basic operations like checking permissions or listing roles when custom logic is required.

Because operations like hierarchy traversal, group expansion, and policy evaluation happen on dedicated IAM endpoints (spanning IAM v1 allow roles, IAM v2 deny, Policy Troubleshooter, and Policy Analyzer), skills run quickly and accurately with minimal token usage. Teams can also use these atomic MCP tools directly when writing their own custom Agent Skills, making it straightforward to combine Google Cloud's IAM capabilities with internal ticketing systems, custom compliance checks, and existing deployment pipelines.

Getting started

Accelerate your agentic workflows, reduce operational overhead, and bring intelligent, scalable security to your deployment pipelines. Start building with IAM Helper Agent skills today by exploring our Google Cloud Agent Skills Catalog and dive deeper with the official IAM documentation.

Bringing Google TPUs to Oracle Cloud Infrastructure

Tue, 27 Oct 2026 14:00:00 +0000

As AI workloads scale across every industry, organizations need compute options that optimize throughput, latency, and unit economics across the AI lifecycle. To meet this demand, Oracle and Google Cloud are partnering to bring Google Tensor Processing Units (TPUs) to Oracle Cloud Infrastructure (OCI), making OCI the first hyperscaler outside Google to offer TPUs. Together, we will deploy TPU capacity on OCI starting in the calendar year 2027.

TPUs: Co-designed from silicon to software

Google built its first TPU more than ten years ago on a clear product thesis: co-designing custom silicon alongside optical networking, power delivery, liquid cooling, and compiler software yields gains in performance per watt and total cost of ownership that isolated components cannot match.

TPU v1 delivered 30x the throughput per watt of contemporary processors. Today, TPUs train and serve Gemini across Google's billion-user products, and the eighth-generation TPUs deliver up to 12.6 PFLOPS of native FP4 compute per chip, over 100x TPU v1's 92 TFLOPS at up to 2x the performance per watt of the previous generation. However, raw FLOPS alone do not determine customer economics across training and inference. For training, the governing metric is goodput; the percentage of time a cluster spends doing productive computation. For inference, the governing metrics are latency and cost per token. TPUs address both through system-level co-design.

By pairing on-die Inter-Chip Interconnect (ICI) routing with Optical Circuit Switching (OCS), the control plane detects hardware or link degradations and dynamically routes optical paths around faults in real time without job restarts, sustaining over 97% goodput across thousands of chips on large-scale training runs and high availability for production serving. Increased on-chip SRAM, more HBM capacity, and a new low-diameter interconnect topology that cuts network hops by more than 50% allow the latest generation TPUs to deliver up to 80% better performance per dollar for low-latency serving.

This hardware efficiency translates into product velocity when developers can adopt it without friction. Our recent announcements at the PyTorch Conference reinforce our commitment to making the Google TPU software ecosystem an open, developer-friendly environment for the PyTorch community. Notably, TorchTPU, our native PyTorch stack for Google TPUs, is now available as open source on GitHub. You can now train, serve, and deploy models on TPUs using the tools you already rely on, including vLLM, SGLang, llm-d, TorchTitan, Ray, TorchRec, Hugging Face, LiteRT.

This portability lets teams assign each workload to the accelerator that delivers the lowest cost per token or fastest time to train, without rewriting model code. And with today’s announcement, they will soon be able to assign those workloads to TPUs on Google Cloud or Oracle infrastructure.

Expanding the AI infrastructure ecosystem with OCI

Even as TPU adoption on Google Cloud grows, the global demand for AI compute exceeds any single cloud provider's footprint.Bringing TPUs to OCI gives customers four distinct benefits:

Data centers engineered for AI density: Google's TPU systems are designed for direct liquid cooling at rack scale, and OCI's next-generation data centers are built for exactly that profile. Oracle delivers flexible, durable capacity that can shift between frontier model training and production inference as customer demand changes. Pairing TPU efficiency with Oracle’s innovative power and cooling approaches, helps bring energy-efficient AI-compute capacity online rapidly, and at global scale.
Secure, high-performance networking with Oracle Acceleron: While TPUs move chip-to-chip traffic over ICI and OCS, Oracle Acceleron provides the networking foundation that connects TPU capacity to the rest of OCI. Acceleron’s SmartNIC with hardware-level tenant isolation, High Performance Fabric, and Zero Trust Packet Routing moves data between Oracle databases, storage, and TPU clusters with high throughput and low latency, without taxing host compute and without weakening security boundaries.
Proximity to enterprise data: Oracle databases are often the system-of-record for enterprise organizations. Offering TPUs directly within OCI lets organizations run fine-tuning and inference next to their existing enterprise data without costly cross-cloud transfers.
Multi-architecture choice: Providing TPUs alongside GPUs inside OCI gives teams the flexibility to assign each AI workload stage to the optimal accelerator for cost and performance.

By bringing Google TPUs to Oracle Cloud Infrastructure, Google Cloud and Oracle are opening up over a decade of purpose-built AI systems engineering to a broader ecosystem of builders. When customers have more choices of purpose-built compute across more clouds, the entire industry builds faster and operates more efficiently. We can’t wait to see what you build.