Developers & Practitioners

Scaling AI Agents: A Step-by-Step Guide to Deploying ADK on GKE Autopilot

Thu, 04 Jun 2026 07:00:00 +0000

While building AI agents locally using Google’s Agent Development Kit (ADK) is an excellent way to prototype, production-ready agents require a robust, scalable infrastructure. For developers looking to move beyond simple instances and into the world of managed container orchestration, Google Kubernetes Engine (GKE) Autopilot offers the perfect balance of flexibility and ease of use.

In this tutorial, I will walk you through building a technical agent with ADK and deploying it to GKE Autopilot. We will focus on utilizing Gemini on Vertex AI as the core model and ensure highest security standards by implementing Workload Identity for permission management.

Understanding the GKE ADK Architecture

Deploying an ADK agent on GKE Autopilot involves more than just running a container. We leverage GKE's native capabilities to handle scaling and security. Our architecture consists of an ADK-based Python application packaged as a Docker image and stored in Artifact Registry. This container runs as a Deployment on GKE Autopilot, where it communicates securely with Vertex AI using Workload Identity—mapping a Kubernetes Service Account to a Google Cloud IAM Service Account.

To expose the agent to the world, we use the Kubernetes Gateway API, the modern successor to Ingress, which provides a cleaner separation of concerns and native support for Google Cloud Load Balancing.

Prerequisites

Before we begin, ensure you have the following tools and accounts ready:

Python 3.10 or higher.
uv for package management.
Google Cloud SDK (gcloud) installed and configured.
A Google Cloud project with billing enabled.
kubectl command-line tool.
jq for parsing JSON responses.
The following APIs enabled: Kubernetes Engine, Artifact Registry, and Vertex AI.

Step 0: Configuring Google Cloud and Authentication

Before interacting with Google Cloud services, you must authenticate your environment and set the active project. This ensures that both the gcloud CLI and your local Python environment can access Vertex AI.

Login to Google Cloud SDK:
```
gcloud auth login
```
Set your active project:
```
gcloud config set project [PROJECT_ID]
```
Setup Application Default Credentials (ADC): This is crucial for the ADK library to authenticate with Vertex AI during local testing.
```
gcloud auth application-default login
```
Define Environment Variables: To ensure we can easily reuse our configuration in subsequent steps, let's export our project, region, and cluster name as environment variables.
```
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export CLUSTER_NAME=adk-cluster
```

Step 1: Provisioning GKE Autopilot

GKE Autopilot is the recommended way to run Kubernetes without managing nodes. It allows you to focus on your agent deployment while Google manages the infrastructure. Starting the cluster creation now allows it to provision in the background while we build the agent.

gcloud container clusters create-auto $CLUSTER_NAME --region $REGION

While the cluster is provisioning, we can move on to building our agent.

Step 2: Building the Agent with ADK

First, let's create our agent. Start by creating a folder for the agent code:

mkdir adk-agent
cd adk-agent

Initialize a new Python project with uv:

uv init

Add dependencies

uv add google-adk

Create a new agent using the adk cli

uv run adk create weather_agent

You will be asked to choose a model for the root agent. Choose gemini-2.5-flash (Number 1). Next you will be asked to choose a backend. Choose Vertex AI (Number 2). Next you will be asked to enter your Google Cloud project ID. Enter your project ID. Next you will be asked to enter your Google Cloud region. Choose a region of your choice. Example: us-central1.

The previous command scaffolded a new directory weather_agent with the following structure:

weather_agent/
├── .env
├── __init__.py
└── agent.py

ADK requires the agent code to be in agent.py file. Let's edit the agent.py file to add a simple tool for the agent.

 from google.adk import Agent
# Define a simple tool for the agent
def get_weather(city: str) -> str:
    """Returns the current weather in a city."""
    return f"The weather in {city} is 90 degrees Fahrenheit and sunny."
# Initialize the agent with Vertex AI and Gemini
root_agent = Agent(
    name="weather_agent",
    model="gemini-2.5-pro",
    tools=[get_weather]
)

The agent.py file is the entry point for the agent. It is used to define the agent and its tools. The get_weather function is a simple tool that returns the current weather in a city. For the purpose of this tutorial, we are using a hardcoded value for the weather. In a real-world scenario, you would use an API to get the current weather.

Step 3: Testing the Agent Locally

Before deploying the agent to GKE Autopilot, we need to test it locally to ensure it works as expected. Run the following command to start the agent in debug mode with the web UI:

uv run adk web

Open http://localhost:8000 in your browser and you should see the ADK web UI. You can then interact with your agent by typing messages in the chat interface.

If the agent returns a message like "The weather in [CITY] is 90 degrees Fahrenheit and sunny." Congratulations! your ADK agent is working. Now you can proceed to the next step.

Step 4: Preparing for GKE Autopilot

The ADK cli has a built-in command to deploy the agent to GKE Autopilot. However the default settings are not suitable for a production environment. For example, the default settings do not use Workload Identity for authentication with Vertex AI and to expose the Web UI via a Load Balancer on port 80.

We will instead manage the lifecycle of the container ourselves. First we need to containerize the agent.

Create a .dockerignore file in the adk-agent directory to prevent your local virtual environment from being copied into the image:

.venv
.adk
__pycache__
*.pyc
.env

Create a Dockerfile for your agent in the adk-agent directory. We will use a multi-stage build to keep the final production image lightweight and secure:

# Stage 1: Build the virtual environment
FROM python:3.10-slim AS builder

# Install uv
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/

# Set working directory
WORKDIR /app

# Force uv to use the system Python and use copy instead of symlinks
ENV UV_PYTHON_PREFERENCE=only-system
ENV UV_LINK_MODE=copy
ENV UV_COMPILE_BYTECODE=1
ENV UV_PYTHON=/usr/local/bin/python3

# Install dependencies
# We copy only files needed for installation to maximize cache
COPY pyproject.toml uv.lock ./
# Note: We don't use --frozen yet as the host lock file might be slightly out of sync
# but sync will update it in the builder stage.
RUN uv sync --no-install-project --no-dev --no-cache

# Copy the agent code
COPY . .
# Sync the project itself
RUN uv sync --no-dev --no-cache

# Stage 2: Runtime image
FROM python:3.10-slim

WORKDIR /app

# Copy the pre-built environment from the builder
COPY --from=builder /app/.venv /app/.venv
# Copy the application code (including weather_agent folder)
COPY . .

# Add the environment to the PATH
ENV PATH="/app/.venv/bin:$PATH"
ENV PYTHONUNBUFFERED=1

# Run the ADK API server
# We point to the weather_agent folder
CMD ["adk", "api_server", ".", "--host", "0.0.0.0", "--port", "8080"]

Build and push the image to Artifact Registry:

# Create repository
gcloud artifacts repositories create adk-repo --repository-format=docker --location=$REGION

# Build and push
gcloud builds submit --tag $REGION-docker.pkg.dev/$PROJECT_ID/adk-repo/gke-agent:latest

Step 5: Implementing Workload Identity for Security

Security is paramount. Instead of hardcoding API keys, we use Workload Identity to grant the GKE pod permission to access Vertex AI.

1. Create an IAM Service Account:

gcloud iam service-accounts create adk-gke-sa

2. Grant Vertex AI permissions:

gcloud projects add-iam-policy-binding $PROJECT_ID \

    --member="serviceAccount:adk-gke-sa@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

3. Allow the Kubernetes Service Account to impersonate the IAM SA:

gcloud iam service-accounts add-iam-policy-binding adk-gke-sa@$PROJECT_ID.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:$PROJECT_ID.svc.id.goog[default/adk-ksa]"

Step 6: Deploying the Agent to GKE

Now, we define the Kubernetes resources. Create a deployment.yaml that includes the Service Account annotation for Workload Identity. Replace $PROJECT_ID and $REGION with your actual project ID and region.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: adk-ksa
  annotations:
    iam.gke.io/gcp-service-account: adk-gke-sa@$PROJECT_ID.iam.gserviceaccount.com
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: adk-agent
spec:
  replicas: 2
  selector:
    matchLabels:
      app: adk-agent
  template:
    metadata:
      labels:
        app: adk-agent
    spec:
      serviceAccountName: adk-ksa
      containers:
      - name: adk-agent
        image: $REGION-docker.pkg.dev/$PROJECT_ID/adk-repo/gke-agent:latest
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits: 
            cpu: "1"
            memory: "1Gi"
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: adk-service
spec:
  selector:
    app: adk-agent
  ports:
  - port: 80
    targetPort: 8080

Apply the configuration:

kubectl apply -f deployment.yaml

Check the status of the deployment:

kubectl get pods -w

Once the pods are running, you can use kubectl port-forward to access the agent locally:

kubectl port-forward svc/adk-service 8080:80

Since we deployed the agent without Web UI, we can't access it at http://localhost:8080. However, we can still interact with it using the API and curl.

In a new terminal, run the following commands:

# Create a new session
curl -X POST http://localhost:8080/apps/weather_agent/users/u_123/sessions/s_123

# Run a message
curl -s -X POST http://localhost:8080/run \
-H "Content-Type: application/json" \
-d '{
"appName": "weather_agent",
"userId": "u_123",
"sessionId": "s_123",
"newMessage": {
    "role": "user",
    "parts": [{
    "text": "Hey whats the weather in new york today"
    }]
}
}' | jq .

The curl command will return the response in JSON format. The jq command is used to parse the JSON response and display it in a more readable format. . You should see a response like:

{
    "sessionId": "s_123",
    "messages": [
        {
            "role": "assistant",
            "parts": [
                {
                    "text": "The weather in New York today is sunny with a high of 90 degrees Fahrenheit."
                }
            ]
        }
    ]
}

(Optional) Step 7: Exposing via Gateway API and HTTPS load balancer

Finally, we expose the agent using the GKE Gateway API with a Google-managed TLS certificate. This is the recommended, production-grade approach — Google will automatically provision and renew the certificate for your domain.

NB: GKE supports other options to provision certificates. You can use Let's Encrypt with cert-manager, pre-shared certificates, or any other certificate authority. You can check the GKE documentation for more details.

First, reserve a static IP address for your load balancer:

gcloud compute addresses create adk-agent-ip --global
export AGENT_IP=$(gcloud compute addresses describe adk-agent-ip --global --format="value(address)")
echo "Your IP: $AGENT_IP"

Point your domain's DNS A record at $AGENT_IP. Example: adk.mydomain.com

Create a Google-Managed Certificate. Replace adk.yourdomain.com with your actual domain::

gcloud compute ssl-certificates create adk-cert --domains adk.yourdomain.com --global

Create a gateway.yaml with the following content:

# Gateway: HTTPS load balancer with the managed certificate and static IP
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: adk-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: adk-cert
  addresses:
  - type: NamedAddress
    value: adk-agent-ip
---
# HTTPRoute: forward traffic to the ADK service
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: adk-route
spec:
  parentRefs:
  - name: adk-gateway
  hostnames:
  - "api.yourdomain.com"
  rules:
  - backendRefs:
    - name: adk-service
      port: 80
---
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: adk-health
  namespace: default
spec:
  default:
    checkIntervalSec: 15
    timeoutSec: 5
    healthyThreshold: 1
    unhealthyThreshold: 2
    logConfig:
      enabled: false
    config:
      type: HTTP
      httpHealthCheck:
        port: 8080
        requestPath: /health
  targetRef:
    group: ""
    kind: Service
    name: adk-service

Apply the configuration:

kubectl apply -f gateway.yaml

Certificate provisioning can take up to 20 minutes. Monitor the status with:

gcloud compute ssl-certificates describe adk-cert --global

Once the status shows Active, your agent is live at https://api.yourdomain.com. You can test it with:

# Create a new session
curl -X POST https://api.yourdomain.com/apps/weather_agent/users/u_124/sessions/s_124

# Run a message
curl -s -X POST https://api.yourdomain.com/run \
-H "Content-Type: application/json" \
-d '{
"appName": "weather_agent",
"userId": "u_124",
"sessionId": "s_124",
"newMessage": {
    "role": "user",
    "parts": [{
    "text": "Hey whats the weather in new york today"
    }]
}
}' | jq .

Conclusion & Looking Ahead

By following these steps, you have successfully deployed a production-ready AI agent built with ADK onto GKE Autopilot that invokes Gemini on Vertex AI with Workload Identity for authentication. This setup ensures that your agent can scale horizontally to meet demand while maintaining a high security posture.

As you look ahead, consider integrating more complex tools or leveraging GKE's multi-cluster capabilities for even greater resilience. For more details on the technologies used here, explore the official GKE documentation and the ADK repository.

To avoid ongoing charges, remember to delete the GKE cluster and the Artifact Registry repository when finished:

kubectl delete -f gateway.yaml
kubectl delete -f deployment.yaml
gcloud compute addresses delete adk-agent-ip --global
gcloud compute ssl-certificates delete adk-cert --global
gcloud container clusters delete $CLUSTER_NAME --region $REGION
gcloud artifacts repositories delete adk-repo --location $REGION

Connecting AI agents with unstructured data using Google Cloud Storage MCP Servers

Tue, 02 Jun 2026 17:00:00 +0000

Google Cloud Storage (GCS) is a foundational component of the modern agentic tech stack and the preferred home for unstructured data at scale. As enterprises deploy agents in production, the critical focus has shifted to turning data into context and building secure, standardized integrations to access context. This is the core of smart storage: making unstructured data inherently agent-ready by turning passive objects into rich context for reasoning. Whether it’s automating complex financial workflows or diagnosing system failures in seconds, AI success now depends on how seamlessly agents can leverage this intelligence to make smart, high-stakes decisions.

In this blog, we will share three examples of agents built by customers using GCS, and then share how you can securely and reliably connect your agents to GCS using Model Context Protocol (MCP). Combined with smart storage features like auto annotations and object contexts, GCS MCP server makes the whole agent deployment process easy and simple.

Real-world agent success on Google Cloud Storage

We are seeing incredible innovation from customers leveraging MCP and Google’s agentic tech stack to solve complex business problems:

Palo Alto Networks built the Strata Co-Pilot agent, a screen-aware AI assistant that guides network security administrators through complex configuration flows—either by highlighting steps or executing them directly. The agent is powered by the Gemini Live API, with GCS serving as its “historical memory” connected via the GCS MCP server.
Airwallex developed an AI Assistant that understands user context, answers questions, and executes workflows on their behalf. For example, it can smartly analyze expense policy documents and generate detailed approval workflows - a task that would normally take hours to do manually. GCS and GCS metadata are used by the agent to store documents and the extracted information, respectively.

Snap's Job Optimization Agent analyzes Flink and Spark job specs, metadata, and historical metrics stored on GCS across thousands of jobs to find optimization opportunities, generate cost estimates, and tune configurations. Using this agent, Snap is already seeing investigation time reduced from 30 minutes to 30 seconds!

In all these three agents, the GCS MCP server handles data operations as well as enforces standard RBAC and access policies.

Connecting agents to GCS using MCP

MCP has rapidly emerged as the universal standard for connecting agents to data sources, but building custom servers from scratch is often a slow, distracting process that diverts focus from innovation. This path introduces significant development overhead and risk, as it forces you to manage everything from authentication and error handling to keeping pace with GCS’s evolving capabilities. To solve this, GCS offers two powerful MCP server options — Remote and Local — allowing you to offload the foundational plumbing and focus on creating value.

1. Remote MCP server: Fully-managed
Connecting your agents to the Cloud Storage MCP server requires zero infrastructure deployment. By simply pointing your agent configuration to the managed endpoint, you gain immediate access to your unstructured data on GCS, allowing you to scale your agentic workloads effortlessly without the burden of operational overhead.

Because the Cloud Storage MCP server follows the open MCP standard, it works seamlessly with major agentic frameworks like ADK and is compatible with MCP clients. You can easily connect clients like Google Antigravity and Anthropic’s Claude by adding a Custom Connector in the settings. Simply point it to your Cloud Storage MCP endpoint, and you are ready to start building — no complex configuration files required.

Connecting an agent to storage requires robust security and governance. GCS MCP server is built on Google Cloud's standard identity, observability, and security frameworks:

Identity-first security: Authentication is handled entirely through Identity and Access Management (IAM) rather than shared keys. This ensures agents can only access data (buckets and objects) explicitly authorized by the user.
Full observability: To track agent activity, every request and action taken via these MCP servers is logged in Cloud Audit Logs. This provides security teams with a record of every interaction, maintaining visibility alongside ease of access.
MCP security - content scanning: You can optionally configure the MCP endpoint with Google’s content security service, Google Cloud Model Armor. This allows you to implement security controls against common MCP attack vectors—such as direct and indirect prompt injection attacks, MCP Tool poisoning attacks, and malicious URL/SQL injections—as well as prevent the leakage of sensitive data.

Cloud Storage MCP servers are perfect for most production use cases; however, as with all remote servers, you lose the capability to fully customize your MCP tools.

2. Local MCP Server: Self-managed for controlled customization
While the Remote server handles standard data access, Local MCP is the right choice when you need to build custom tools specific to your business logic. For example, if your agent needs to perform specialized data transformations—such as redacting PII or adding context from another internal system—whenever it reads a file from GCS, a Local MCP server allows you to define those unique capabilities

The GCS Local MCP server is an open-source GitHub repository of Google-maintained tools that provides you with a reliable bridge to your data. Here are a few tips to keep in mind while designing custom tools:

Provide precise, clear descriptions to minimize incorrect invocations by the models
Implement model-friendly error handling for models to understand their mistakes and self-correct

The GCS Local MCP is now also a part of the MCP Toolbox for Databases, a single open-source repository containing connectors for major data services such as GCS, BigQuery, AlloyDB, Spanner, and Cloud SQL, making it easier to monitor and manage your data ecosystem. The Toolbox offers simplified development with reduced boilerplate code, enhanced security through OAuth2 and OIDC, and end-to-end observability with OpenTelemetry integration.

Get started

Whether you are optimizing an existing process like Snap or automating workflow creations like Airwallex, your unstructured data is one of your agent's greatest assets.

Explore the generally available GCS Remote MCP Server.
Check out our GCS Local MCP GitHub repository to start building custom tools today, or use it as part of MCP Toolbox for Databases.
Reach out to us to discuss your Agent use case with GCS data.

Experimenting with TPUs, GKE Managed DRANET, and Multi-cluster Inference Gateway

Tue, 02 Jun 2026 07:00:00 +0000

What happens when your workload fails in one region but you need access to service? This is a common case for availability and uptime. With recent enhancement to the Kubernetes ecosystem and capabilities like Dynamic Resource Allocation (DRA) and Inference Gateway. I decided to experiment with these capabilities in Google Cloud for a simple test using an AI inference workload.

In this blog, we will explore this setup and you can also jump straight into the detailed configs in this codelab Build multi-cluster GKE Inference Gateway, with TPUs , Cloud Storage FUSE and managed DRANET.

Building blocks

To build out this experiment, use the following products, features, and tools:

Google Kubernetes Engine (GKE) managed DRANET: This is a managed feature that lets you request and share resources among Pods. This supports GPUs, and TPUs. In this test TPUs were used in two different regions with networking assigned using managed DRANET.
Multi-cluster GKE Inference gateway: Load balances your AI/ML inference workloads across multiple GKE clusters. This works in a failover situation which is what my experiment intended to test. The type which supports this is the Multi-cluster Cross-region internal Application Load Balancer gke-l7-cross-regional-internal-managed-mc
Cloud Storage FUSE: Provides a way to store data, models, checkpoints, and logs directly in Cloud Storage. To speed up the deployment, an open source gemma model was downloaded to this storage for retrieval.
Virtual private Cloud (VPC): The foundational global network providing isolated, secure communication for the internal load balancers and compute nodes
GKE Fleets: Fleets group the separate regional clusters under a unified management control plane
TPU v6e: Google's custom AI accelerators that provide the high-performance compute required to serve the model. The VM family type used was the ct6e-standard-4t in a 2x2 Slice

Design pattern example

The aim is to deploy a LLM model (Gemma 3) onto 2 GKE clusters in different regions. Each cluster will use 4 TPU v6e chips. The model should be stored in Cloud Storage. The workload is served using GKE Inference Gateway which supports multi-clusters. The traffic should be routed to the region closest to the user and failover to the other region if one region fails.

Putting it together

To get access to the TPUs for your project in two regions you have to ensure you have the necessary quota in those regions.

Begin: Set up the environment.

Create a standard VPC, with firewall rules and subnet in the same zone as the reservation.
Create a proxy-only subnet this will be used with the Internal regional application load balancer attached to the GKE inference gateway
Set up firewall rules allowing traffic and health checks.
Reserve static internal IP addresses in both regions for the Gateway.
Provision a Cloud Storage FUSE bucket and configure a dedicated IAM Service Account. Bind this to a Kubernetes Workload Identity so your pods can securely mount the bucket and read the model weights directly.

Next: Create standard GKE clusters and node pools.

Deploy two separate GKE clusters in your chosen regions configured.
Enable the Gateway API (--gateway-api=standard) and the Cloud Storage FUSE CSI driver (--addons GcsFuseCsiDriver) during cluster creation.
Create dedicated TPU v6e node pools (ct6e-standard-4t) for both clusters.
Enable managed DRANET on these TPU node pools by setting the flags ---accelerator-network-profile=auto, and --node-labels=cloud.google.com/gke-networking-dra-driver=true

Next: Establish the global mesh via Fleet Registration.

Register both GKE clusters to a unified GKE Fleet by following the fleet creation and registration setup.
Enable Multi-Cluster Service Discovery and Multi-Cluster Ingress on your fleet.
Designate your primary region as the configuration hub to act as the control plane for routing rules across both regions.

Next: Deploy the AI workload.

Use a temporary Kubernetes job to download the Gemma 3 (gemma-3-27b-it) model weights directly into your Cloud Storage bucket.
Define a ResourceClaimTemplate that explicitly requests the managed DRANET device class (deviceClassName: netdev.google.com ) with the allocation mode set to "All".

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-netdev\r\n namespace: default\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-netdev\r\n exactly:\r\n deviceClassName: netdev.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a74250>)])]>

Deploy your inference server (e.g. vLLM) on the TPU nodes in both regions. Ensure the pod spec utilizes node selectors for the 2x2 TPU topology, requests exactly 4 TPUs, and mounts the netdev claim. This guarantees your pods utilize the dedicated accelerator networking alongside standard Ethernet.

Next: Configure the Multi-Cluster Inference Gateway.

Install the necessary Custom Resource Definitions (CRDs) so Kubernetes can process specialized routing objects like the InferenceObjective.
Deploy an AutoscalingMetric to track hardware utilization, such as KV cache usage.
Use Helm to group the independent AI deployments from both regions into a single, logical InferencePool.
Deploy the Cross-Region Gateway and its associated HTTPRoute to manage incoming global traffic.
Apply health checks and backend policies to the pool to ensure load balancing relies on your custom hardware metrics.

Configure an InferenceObjective to instruct the gateway to route prompts to the region with the highest availability, avoiding overloaded TPUs.

code_block: <ListValue: [StructValue([('code', 'apiVersion: gateway.networking.k8s.io/v1\r\nkind: Gateway\r\nmetadata:\r\n name: cross-region-gateway\r\n namespace: default\r\nspec:\r\n gatewayClassName: gke-l7-cross-regional-internal-managed-mc\r\n addresses:\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/europe-west4/addresses/gemma-gateway-ip-europe-west4"\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/us-east5/addresses/gemma-gateway-ip-us-east5"\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n---\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: gemma-route\r\n namespace: default\r\nspec:\r\n parentRefs:\r\n - name: cross-region-gateway\r\n kind: Gateway\r\n rules:\r\n - backendRefs:\r\n - group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: HealthCheckPolicy\r\nmetadata:\r\n name: gemma-health-check\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n config:\r\n type: HTTP\r\n httpHealthCheck:\r\n requestPath: /health\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: GCPBackendPolicy\r\nmetadata:\r\n name: gemma-backend-policy\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n timeoutSec: 100\r\n balancingMode: CUSTOM_METRICS\r\n trafficDuration: LONG\r\n customMetrics:\r\n - name: gke.named_metrics.tpu-cache\r\n dryRun: false\r\n maxUtilizationPercent: 60\r\n---\r\napiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: tpu-cache\r\n namespace: default\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: gemma-server\r\n endpoints:\r\n - port: 8000\r\n path: /metrics\r\n metrics:\r\n - name: vllm:kv_cache_usage_perc\r\n exportName: tpu-cache\r\n---\r\napiVersion: inference.networking.x-k8s.io/v1alpha2\r\nkind: InferenceObjective\r\nmetadata:\r\n name: gemma-objective\r\n namespace: default\r\nspec:\r\n priority: 10\r\n poolRef:\r\n name: gemma-pool\r\n group: "inference.networking.k8s.io"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a74130>)])]>

Testing the Failover

Verify the highly available architecture by simulating a primary region outage. Once the primary deployment is taken offline, the Gateway automatically detects the failure and seamlessly reroutes all subsequent user requests to the active secondary cluster, ensuring continuous availability without dropping traffic.

Next Steps

Take a deeper dive into a hands-on codelab and more information on these features review the following.

Hands-on Codelab: Build multi-cluster GKE Inference Gateway, with TPUs , Cloud Storage FUSE and managed DRANET
Document set: DRANET
Documentation: AI Hypercomputer

Want to ask a question, find out more or share a thought? Please connect with me on Linkedin.

Developer's guide to Gemini Enterprise and A2UI integration

Fri, 29 May 2026 16:00:00 +0000

If you've built a chatbot, you know this conversation:

User: "Book a table for two tomorrow at 7pm." Agent: "Okay, for what day?" User: "Tomorrow." Agent: "What time?"

A date picker would have ended this in one tap. But until recently, agents had no standard way to render a date picker — or a map, or a multi-select list — inside the chat surface they live in. They could only return text or markdown for generic usage.

Today, we're walking through how to fix that with A2UI, an open protocol for agent-driven user interfaces, and how to integrate an A2UI-enabled agent with Gemini Enterprise (GE) so your agent renders rich and interactive UI natively in the GE chat surface — and in your own custom frontend if you want one. We'll use a working restaurant-finder agent — built with the Google Agent Development Kit (ADK), the A2A protocol, and Gemini — as the reference. The full source is on GitHub and there's a 2-minute demo video.

The problem: agents speak text, but users want UI

Most agent frameworks today return strings. That's fine for short answers, but it breaks down quickly:

Multi-turn slot filling (date, time, party size) burns turns and patience.
Choices among options (which restaurant? which insurance plan?) become long bulleted lists the user has to copy-paste back.
Spatial information (locations, routes, floor plans) is reduced to addresses.

Developers have tried to patch this by sending HTML or JavaScript fragments, but that introduces real risks: cross-site scripting, UI injection from a remote agent you don't fully control, and visual drift from the host app's design system. What's needed is a way to transmit UI that's safe like data and expressive like code.

What A2UI is

A2UI is an open protocol, introduced by Google and co-developed with the Flutter team and product teams behind Gemini Enterprise. Instead of returning text or HTML, an agent returns a JSON payload that describes a UI: a tree of components (Card, Text, Button, ChoicePicker, Image, …) and a separate data model holding the values those components display.

Three properties make this useful in practice:

Declarative, not executable. The payload is data. The client only renders components from a pre-approved catalog, so a remote agent can't inject arbitrary code or steal credentials through a UI widget.
Streaming-friendly. The format is a flat list of small JSON messages, so the LLM can emit them incrementally and the client can paint as they arrive.
Framework-agnostic. The same agent response renders through Lit, Angular, Flutter, or native mobile. The agent doesn't know — or care — what's on the other end.

A2UI is also transport-agnostic. The messages ride inside whatever pipe you already use: A2A JSON-RPC, AG-UI, WebSockets, SSE. In our reference implementation, A2UI rides inside the A2A protocol as DataPart objects with the MIME type application/json+a2ui.

Where A2UI sits in the stack

A2UI is one piece of a four-layer stack. Confusion usually comes from conflating these layers — they're each doing a different job:

Layer	Owns	Examples
App experience	Client shell and conversation state — chat window, input box, message history	CopilotKit, AG-UI
Pixel drawing	Turning component descriptions into actual rendered UI	Lit, Flutter, Angular
Conversation pipeline	Client–server transport — sending messages, receiving responses	A2A Protocol
Cargo (data format)	The thing flowing through the pipeline that describes the UI	A2UI

Read top to bottom: CopilotKit/AG-UI owns the app experience. Lit/Flutter/Angular own the rendering. While CopilotKit and AG-UI provide valuable abstractions, they remain strictly optional for implementing A2UI. In this architecture, A2A serves as the underlying conversation pipeline, while A2UI represents the structured cargo that actually traverses that pipe.

That separation is why the same A2UI payload renders identically in three very different deployment shapes:

Bespoke web app — a custom client shell (like the reference repo's Lit frontend/) plus a custom A2UI renderer.
CopilotKit / AG-UI app — CopilotKit owns the chat shell, an A2UI renderer is registered inside it for rich cards.
Gemini Enterprise — GE is the shell, the renderer, and the transport client. You only build the agent.

So for the GE path, the stack collapses to two layers you control: the A2A endpoint (your agent) and the A2UI cargo it emits. The other two layers are GE's responsibility. CopilotKit and AG-UI are great if you're building a standalone product UI elsewhere — they're just out of scope for embedding an agent inside Gemini Enterprise.

Pattern revisions

The protocol evolves quickly, and different clients support different revisions. Two patterns are common today:

Inline pattern — the agent sends a component tree with the data baked into each component (the pattern Gemini Enterprise renders today).
Decoupled pattern — the agent sends the component tree and the data model as separate messages, so subsequent turns can update one without re-sending the other. This reduces tokens and latency for long-running conversations and is the direction the protocol is heading.

The reference repo serves both patterns from one backend, picking which to emit per request based on the client's X-A2A-Extensions header. As new revisions ship, you add another catalog and the same negotiation pattern keeps working.

How A2UI works inside Gemini Enterprise

Gemini Enterprise ships with a built-in A2UI renderer. For the developer, that means the integration story is short:

Build your A2A agent, embedding an A2UI catalog and example payloads alongside the regular tool definitions.
Register the agent with Gemini Enterprise as an A2A endpoint. (Use make register-gemini-enterprise in the reference repo.)
A GE admin shares the agent with employees, just like any other agent in the GE catalog.

At runtime, the flow looks like this:

The user types a request in the GE chat. GE calls your agent's A2A endpoint and sends along GE's own A2UI catalog — the list of UI components GE knows how to render.
Your agent decides whether a UI widget is the right response. If yes, it emits an A2UI JSON message (e.g., a ChoicePicker of restaurant options). If no, it falls back to text. Both can coexist in the same response.
GE receives the JSON, validates it against its catalog, and renders the widget natively in GE's own design language — so it visually matches the rest of the chat surface.
When the user interacts with the widget (selects three options, picks a date), GE serializes the interaction back into JSON and sends it to your agent as the next turn. Your agent processes structured input, not free-form text.

One thing worth flagging: because your agent doesn't ship its own renderer for GE, you don't need to choose a frontend framework to start. Your A2A endpoint can run anywhere — Cloud Run, GKE, on-prem — and GE handles the rendering.

High-level architecture example

The reference implementation is an ADK backend on Cloud Run designed to plug seamlessly into Gemini Enterprise.

Gemini Enterprise connects directly to your agent using standard A2A JSON-RPC calls.
The agent serves the inline message pattern expected by the Gemini Enterprise managed UI.
Custom components like GoogleMap render via Google Maps Embed iframes, with the API key injected server-side so the LLM never sees it.

The following demonstration illustrates how Google Maps functions as a live, interactive component within Gemini Enterprise rather than a static image. Leveraging A2UI's streaming-friendly architecture, the agent updates the map view in real-time—dropping pins and adjusting coordinates incrementally as results arrive from the Maps API.

See it running, then build your own

Detailed implementation guide here.
Demo video (2 minutes, end-to-end with both the Lit shell and Gemini Enterprise): https://youtu.be/_5AaYwyqVio
A2UI spec and component reference: a2ui.org
Gemini Enterprise updates, including the A2UI renderer: What's new in Gemini Enterprise
A2UI generative UI announcement: Introducing A2UI generative UI

If you're already building agents on Google Cloud, the fastest path is to clone the reference repo, run make local-backend for a local smoke test, and then make register-gemini-enterprise to wire it into GE. From there, swap in your own catalog, your own tools, and your own domain. The next time a user asks your agent for "a table for two tomorrow at 7pm," the answer can be a date picker instead of another question.

A Guide to AI Cold Starts on Cloud Run

Wed, 27 May 2026 17:23:00 +0000

I saw a developer asking on Reddit if there was any “sane way” to manage Cloud Run cold starts for AI across multiple regions. They were experiencing startup latencies of up to 20 seconds, a frustrating gap where the infrastructure is spinning up while the user waits for a response.

The discussion was full of developers who had almost given up on serverless GPUs, with some even migrating back to GKE just to escape the latency. I decided it was time to dive deep into the Mechanics of AI Cold Starts and see if we could find that "sane way."

During my research into hosting models like Gemma 4 on Cloud Run, I had the privilege of co-presenting at Google Cloud Next '26 with Oded Shahar (Senior Engineering Manager for Cloud Run) and our guest speaker Ajay Nair (Global VP of Platform at Elastic).

In our session, "Build AI architectures with custom models on Cloud Run," Ajay shared the production-hardened strategies that allow Elastic to serve millions of daily requests across 17+ model variants, all while maintaining the 'scale-to-zero' efficiency of Cloud Run.

Build AI architectures with custom models on Cloud Run

Ajay showed us that the secret isn't just in the model, but in treating GPUs as fungible compute rather than infrastructure to manage.

I realized then that minimizing cold start latency isn't just about the model, it's about the infrastructure patterns and architectural decisions that keep it fast, scalable, and secure.

The anatomy of an AI cold start

As the official Google Cloud GPU best practices explain, an AI cold start is a shift from standard web microservices. You aren't just booting code, you're moving gigabytes of weights into a specialized physical accelerator.

Think of it as a four-phase race. If you don't optimize each step, you're going to lose your users.

Phase 1: Infrastructure Provisioning (~5s)

Cloud Run allocates the physical GPU and injects pre-installed NVIDIA drivers. Since Google manages the drivers for you, you don't have to bloat your Dockerfile.

Phase 2: Block-Level Container Image Streaming (1-2s)

Cloud Run uses "image streaming," meaning it pulls only the blocks needed to boot. Your 15GB CUDA image can actually start as fast as a tiny Node.js app!

Phase 3: Engine Initialization (5-15s)

This is where your inference engine (vLLM, Ollama) warms up. This is a massive CPU-heavy task, and it's where most people get throttled without realizing it.

Phase 4: Model Loading & VRAM Transfer

This is the final hurdle - moving those model weights from storage into the GPU memory. Unlike standard web apps where CPU is king, GPU memory is your primary constraint here. If your model’s weights don’t fit entirely within the GPU memory, performance degrades significantly as it swaps to slower system RAM.

Best practices to handling AI cold starts

To build a "sane" production environment, here are a few crucial levers you can pull, informed by the official Google Cloud documentation on AI inference with GPUs.

Optimize Phase 4

Pick the Right Deployment Option

Phase 4 is the "final hurdle" where you move gigabytes of weights from storage into GPU memory. Your choice of storage determines how fast this transfer happens:

Cloud Storage (Concurrent Download) - Fastest: Using the Google Cloud CLI (gcloud storage cp) allows you to download model files in parallel. This is the recommended method for massive weights because it maximizes network throughput and drastically reduces transfer time.
Cloud Storage (FUSE) - Easiest: This provides "zero-code" changes by mounting a bucket as a local file system. However, because it does not parallelize the initial download, it is significantly slower for large model weights
Container Image - Best for <10GB: Baking weights into your image is efficient for smaller models thanks to Cloud Run's Image Streaming. For models over 10GB, however, the import and streaming overhead can become a bottleneck.
Internet: Avoid this. It is the slowest and least predictable path for production inference.

Model Format & Size

Optimizing your model's format and size is a direct "hack" to shorten Phase 4 (Model Loading & VRAM Transfer). Because this phase is constrained by how fast you can move gigabytes of data into VRAM, smaller and more efficient files are critical.

4-bit Quantization: This is the ultimate cold start hack. Smaller weights mean fewer gigabytes to pull from storage, which directly accelerates the download and transfer portion of Phase 4,
Fast Formats: Pick a model format with fast load times like GGUF to minimize startup time. For the fastest performance, move away from Python "pickle" files and use Safetensors for zero-copy loading.
Ensure VRAM Fit: Use quantized models to ensure the weights fit entirely within the GPU memory. If the model exceeds VRAM, Phase 4 will stall as the system swaps to significantly slower RAM.

Optimize Phases 3 & 4: Infrastructure & Network Levers

These infrastructure settings provide the necessary resources to accelerate the most demanding parts of the startup process.

Startup CPU Boost (Accelerates Phase 3)

This feature temporarily doubles your CPU power during startup. A 1 vCPU instance boosts to 2 vCPUs for the duration of startup and the first 10 seconds of serving. It is essential for Phase 3, as engine initialization is a massive CPU-heavy task.

Direct VPC Egress & PGA (Accelerates Phase 4)

Utilizing Direct VPC Egress with Private Google Access (PGA) ensures your model weight traffic stays on Google’s internal high-speed backbone. This optimizes the network path to shorten the time spent moving gigabytes of weights into VRAM.

Concurrency Tuning (Cold Start Avoidance):

In Cloud Run, "concurrency" refers to the maximum number of requests a single instance can handle before the platform scales out to start a new one. For AI workloads, you must tune this setting in tandem with your model engine's internal parallelism flags (e.g., --max-num-seqs for vLLM or OLLAMA_NUM_PARALLEL for Ollama).

Use the official Google Cloud formula to find your ideal Cloud Run concurrency:

(Number of model instances∗parallel queries per model)+(number of model instances∗ideal batch size)

Example: If your instance loads 3 model instances onto the GPU, and each model instance can handle 4 parallel queries with an ideal batch size of 4, you would set your Cloud Run maximum concurrent requests to 24: (3×4)+(3×4)

How the math works: The goal is to keep the GPU fully saturated while ensuring users aren't stuck in a long queue. In this example, the total of 24 concurrent requests is split into two functional groups:

Active Processing (12 requests): Calculated as (3 instances×4 queries), this represents the total number of requests the GPU can actively process at any given moment.
The "Next Batch" Buffer (12 requests): Calculated as (3 instances×4 batch size), these are the requests waiting "on deck" inside the container. As soon as the GPU finishes the first batch, it immediately picks up these waiting requests.

By tuning this value as high as your VRAM allows (usually 10-20 users), one warm instance can serve many requests without triggering a new scale-out event and the cold start that comes with it.

Scaling Controls (Tuning the Threshold)

While the formula above defines your maximum capacity, you can also tune when Cloud Run decides to start the next instance. Cloud Run's autoscaler typically targets 60% utilization, but for long-running AI cold starts, you can increase this threshold to 80% or 90% via Scaling Controls.

Concurrency Target: Increasing this allows you to "pack" more requests into a single warm instance before triggering a scale-out.
CPU Target: Increasing the CPU target prevents the platform from starting a new instance just because initialization or high-intensity inference spiked the CPU utilization.

Scaling & Reliability Strategies

Sometimes the best way to handle a cold start is to avoid it entirely or manage it proactively.

The Single-Region "Always-On" Tradeoff

If you are deploying globally, the cost of keeping minimum instances set to 1 in every region adds up. Instead, consider an 'always-on' service in just one region. A 100ms global network delay is a much better user experience than a 20s local cold start.

The 15-Minute Grace Period: A common question is 'How long will my instance stay warm after a request?' Cloud Run generally keeps instances alive for 15 minutes after they become idle (processing zero requests). If your traffic is predictable and comes in every 10–12 minutes, you might not even need an 'always-on' service, the platform’s default shutdown policy will keep a warm instance ready for your next user.

Note: While this idle time is "free" for standard request-based services, remember that GPU services require instance-based billing, so you will be billed for the duration the instance remains warm between requests.

The "Wake-Up Call" Strategy

Sometimes the best way to handle a cold start is to proactively mask it. If your UI can predict an upcoming request, for example, when a user clicks "New Chat" or begins hovering over a text area, you can send a lightweight health check to your service immediately. By the time the user finishes typing their prompt, the first two phases of the cold start (Infrastructure Provisioning and Container Image Streaming) are already finished in the background.

Pro-Tip: Use Non-Inference Endpoints To make this "wake-up call" as fast as possible, always use a non-inference endpoint rather than sending a dummy prompt like "hi".

Why it’s faster: Non-inference endpoints (like /v1/models for vLLM or /api/tags for Ollama) are handled by the container’s web server the moment it starts. They don’t have to wait for the slow "Phase 4" model loading and VRAM transfer to complete before sending a success response.
No Chat Pollution: Because these endpoints don't trigger the model's completion logic, they won't interfere with the user's actual chat history or accidentally trigger session creation in your backend.

Recommended Endpoints:

vLLM: GET /health or GET GET /v1/models
Ollama: GET /api/tags or GET /api/version

Tune Startup Probes for VRAM

AI models take significant time to move gigabytes of weights from storage into GPU memory (Phase 4). If your startup check fails too many times, Cloud Run will assume your container is broken and kill it.

To prevent this:

Increase the Failure Threshold: Use a high failureThreshold (e.g., 60 or more). Since the total allowed startup time is the product of failureThreshold \times periodSeconds, a threshold of 60 with a 5-second period gives your model a healthy 5-minute window to load.
Utilize the 30-Minute Maximum: While standard services are limited to 4 minutes, Cloud Run supports a total startup time of up to 30 minutes (1,800 seconds) for intensive workloads.
Avoid False Positives (The Ollama Fix): Be careful with engines like Ollama, which may open a TCP port as soon as the service starts, but before the model is actually in VRAM. Always ensure you are preloading models during the container's entrypoint script to ensure the startup probe only passes once the model is truly ready for inference.

Lessons from Elastic’s strategy

In our NEXT ‘26 session, Ajay Nair highlighted three architectural decisions that allowed Elastic to treat GPUs as fungible compute, rather than infrastructure to manage:

Bypass the Compilation Tax: By setting enforce_eager=True in vLLM, they traded a tiny bit of throughput for cold starts that finish in less than a minute rather than multiple minutes.
Standalone Checkpoints: They avoided the latency of runtime adapter-switching by pre-merging each LoRA variant into a standalone checkpoint.
One Workload, One Service: Each independently-scalable workload — defined by model, task adapter, and traffic shape — is deployed as its own Cloud Run service. This produces 30+ services across ~15 model families, with some models split by task (e.g., v5 retrieval vs. clustering) or by query/passage role.

Ready to get started?

Optimizing the cold start process is the difference between a hobby project and a production-ready application. The best part? Cloud Run handles the NVIDIA driver and CUDA installation for you, starting the instance in about 5 seconds.

For a deeper dive, the official documentation is your best friend:

For the full technical breakdown, I highly recommend watching the recording of the session from Google Cloud Next '26. It provides the most comprehensive blueprint for hosting high-performance open models on serverless infrastructure."

Happy building!

Special thanks to Sara Ford and Shane Ouchi from the Cloud Run team and to Zac Li from Elastic for the helpful review and feedback on this article.

Shipping features to production just got easier with new feature flags in AppLifecycle Manager

Thu, 21 May 2026 16:00:00 +0000

Many development teams are familiar with the hesitation that comes right before pushing a new feature live. As AI helps developers write code faster, the gap between rapid code generation and safe production deployment continues to grow.

Feature flags offer a practical way to manage this risk by separating the act of deploying code from the act of releasing a feature to users. Instead of a single, high-risk launch event that affects all users simultaneously, teams can ship code to production with new features hidden by default in a controlled manner.

To help teams adopt this workflow, we are announcing the public preview of AppLifecycle Manager Feature Flags (ALM FF). This service provides a rule-based solution to manage software behavior across Google Cloud, helping you support rapid development without sacrificing production stability.

Read on to learn four ways these feature flags will help accelerate your deployment.

1. Decouple for safety and velocity

The core mission of ALM FF is to increase development velocity by decoupling your feature releases from your code deployments. Traditionally, releasing a feature requires a binary deployment — a high-risk event that affected all users simultaneously.

With ALM FF, you can ship code to production with new features disabled by default. This allows your team to move faster, deploying code continuously while choosing the exact moment to enable a feature via a toggle. If an issue is detected, the flag acts as an instant kill switch, disabling the problematic feature immediately without the need for a full, time-consuming code rollback.

2. Gradual enablement with precise targeting

Safety is about precision. ALM FF leverages the Common Expression Language (CEL) to implement sophisticated logic for gradual feature enablement.

Percentage feature enablement: Instead of a global launch, you can ramp up a feature to 1%, 5%, or 50% of your traffic. This allows you to monitor system health and performance metrics incrementally, ensuring stability before reaching your entire user base.
Precise allowlisting: You can target specific internal teams, beta testers, or early-access customers by allowlisting their identifiers. This ensures that only the intended audience sees a feature during its initial validation phase.

3. Dynamic configuration for the AI era

Beyond simple toggles, ALM FF offers a dynamic way to inject configuration into your applications. By using string-type flags, you can update application behavior — such as system prompts for LLM integrations—in real-time. This allows product managers and business owners to tweak AI responses and application logic without requiring any code changes or infrastructure rollouts.

4. Built on open standards

We believe safety should not mean lock-in. ALM FF is built on the OpenFeature standard, utilizing industry-standard SDKs and the flagd evaluation engine. This ensures your feature management patterns are portable and follow best practices without adding Google-specific dependencies to your core application code.

Get started

ALM FF is now in public preview. To take control of your releases, you can:

Review the docs: Public Documentation
Onboard today: Quickstart Guide
Give us feedback: Help us shape the future of feature management

Securing Your Gemini and Google API Keys

Thu, 21 May 2026 10:19:00 +0000

Today, AI services rely heavily on API keys. To run AI agents, users provide API keys that signify paid tokens, subscriptions, or paid accounts. While API keys are easy to use, it is just as easy to use them unsafely. The result of a hijacked key is a compromised environment that is misused or abused by perpetrators.

I decided to write this blog post after seeing a thread in the r/googlecloud subreddit asking for a tutorial so users can go and protect themselves. In this post, you will find a few simple steps you can take to reduce your risks and improve the security of API keys created by Google.

You use Google API keys to access Gemini and other AI Google products as well as Google Cloud APIs. In fact, a Gemini API key is actually a standard Google API key behind the scenes. While I will be focusing on Google API key security, you can apply some of these recommendations to API keys and product tokens created elsewhere.

Step 1: Generate a New API Key

Regardless of where you start, you end up creating a new API key in one of Google Cloud projects. You probably will use Credentials under the "APIs & Services" menu in the Cloud console.

Or you may use gcloud services api-keys create command instead. Or there is some other interface which will create a new Google Cloud API key. Regardless of the path and the interface, you need to do the following:

Create the key in a stand alone project that is not used for any other purpose.
Restrict API access and client applications for the new API key.

These steps limit the potential reach of the key and greatly simplify troubleshooting activities if something goes wrong.

API Restrictions

API restrictions define exactly which services can be accessed using a specific API key. To keep your environment secure, always limit this list to the absolute minimum set of services required. While the Google Cloud console now prevents the creation of entirely unrestricted keys, it can still be tempting to add extra APIs to "future-proof" or speed up development. However, we strongly advise against this. By strictly adhering to the principle of least privilege, you significantly reduce the potential damage (or "blast radius") if a key is ever accidentally exposed or hijacked.

It is also important to audit keys generated automatically through integrated developer tools. For example, creating an API key in Firebase restricts the use to 24 APIs including Datastore, Firestore, Cloud SQL Admin and others.

If you use Firebase to store your website you probably will not use most of them. When you create an API key to use with AI Studio, restrict it to only "Gemini API".

Attention points:

If you search for an API that you want to select but it is missing, this API is probably not enabled in the Google Cloud project that you use. Go to the API Library in your Cloud console, find the API by name and enable it first.
You can do all actions using the Cloud console or gcloud CLI. Other interfaces (e.g. Firebase) may not provide you with access to all parameters of the API keys

Application Restrictions

Similar to API restrictions that limit what services your key can be used for, Application Restrictions limit the applications which can use the key. For example, if you create an API key only for use with Google AI Studio, setting up the application restrictions to the website "https://aistudio.google.com/" will prevent using your key by automations that utilize Gemini and consume a high volume of tokens at scale.

You can set up one or more restrictions of one of the following types:

Website/Web application using the list of URLs
Services using the list of IPv4 or IPv6 address or a subnet masks
iOS applications using the list of Bundle IDs
Android applications using the list of pairs of the package name and certificate fingerprint

Note that you can restrict the key to a single application type only. Create a designated API key for each application type. Having a key per application type helps when observing the key usage and investigating potentially compromised keys.

Step 2: Store API key

I want to reiterate that the API key is not paired with your identity. ANYONE can use it. So, storing the key securely is as important as restricting the key use in Step 1.

The rule is simple: NEVER EVER store the key where it can be easily seen.

If you use an API key in your application, store it in Secret Manager or a similar secret management service. Secret Manager allows you to inject your API key into Cloud Run and GKE environments easily. However, to elevate the key protection you may want to read the key in your code instead. See documentation for an example.

If you use an API key with an external application that asks you to type in the key, take extra steps to explore how the application manages your key. You would need to find out how the key is stored and how it is used in the requests. For Web applications, you may use browser developer tools to inspect application traffic and ensure that the key is never sent in an unencrypted communication channel. For example, Google AI Studio uses encrypted local storage and sends the key via a TLS-encrypted channel.

If Something Goes Wrong

What to do if you suspect that your key is compromised? The straightforward action is the same as with a credit card. First thing ‒ delete the key. You can do it in the Cloud console or using gcloud services api-keys delete command. If you find out that it was a false alarm, you can undelete during the next 30 days.

What if you do not know which key is compromised? In that case you need to do a two-step investigation:

Find out all API keys in your organization or project(s)
Check the graph of API consumption for APIs this key allowing to access

Find out all your API keys

There is more than one way to find your API key resources. You can use Asset Inventory in the Cloud console and filter the dashboard by the Resource type to check apikeys.Key. If you do not see this resource type, find and click on "View more…" to expand the resource type list. Note that the list shows deleted API keys as well.

If you favor CLI, and you know specific project(s) you can use the gcloud services api-keys list command.

To see all active keys in your organization, you will need to use the gcloud asset search-all-resources command and query its JSON output to filter out deleted keys:

code_block: <ListValue: [StructValue([('code', 'gcloud asset search-all-resources \\\r\n --scope=\'organizations/123456789012\' \\\r\n --asset-types=\'apikeys.googleapis.com/Key\' \\\r\n --read-mask="name,displayName,versionedResources" \\\r\n --format=json \\\r\n --order-by=\'createTime\' \\\r\n| jq \'.[] | select(.versionedResources | all(.resource.data.deleteTime == null))\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5acbf70>)])]>

Find out API consumption

There is a way to track the usage of the API key. You can do it using the Cloud Monitoring metric serviceruntime.googleapis.com/api/request_count. This metric shows a number of times different services have been invoked. To see the number of service requests for a particular API key you will need to use the metric's label credential_id and filter it by the API key unique ID. You can see the metric data using Metrics explorer or use the Monitoring API with the following PromQL expression:

code_block: <ListValue: [StructValue([('code', 'sum(\r\n rate({\r\n "__name__"="serviceruntime.googleapis.com/api/request_count",\r\n "monitored_resource"="consumed_api",\r\n "credential_id"="apikey:00000000-0000-0000-0000-000000000000"\r\n }[${__interval}])\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5acbc70>)])]>

You can further filter this metric by service_name label using API name (e.g. mapstools.googleapis.com).

In order to find out the API key ID you will need to use one of the following methods:

Using the Cloud console, open the Credentials page and select the API key that you want. Inspect URL of the API key page in the browser which will look like: https://console.cloud.google.com/apis/credentials/key/[KEY_ID]?project=[PROJECT_ID]. Copy the [KEY_ID] part.
Using gcloud CLI, run the gcloud services api-keys list --format='value(displayName,uid)'command and find the key by its display name. Copy the UID next to the display name.

Abnormally high level of API invocations usually indicates that the API key was compromised and used to access API by a malicious party.

Step 3: API key management hygiene

Whether you are an engineer, an experienced cloud user or just came to experiment, keeping proper API key hygiene is important to avoid your environment being hijacked from you.

If you already use Google API keys do the following right now:

Find out all API keys that you have
Delete all keys that you no longer use or do not recognize (do not worry, you can restore them during next 30 days)
Restrict API keys to only APIs that you intend to use. Narrow the list of clients that can use the APIs if you can
If you administer your Google Cloud projects or organization, consider setting up the apikeys.googleapis.com/Key org policy to minimize wrangling API keys
Consider periodically rotating (refreshing) your API keys by replacing them with newly created ones that share the exact same restrictions. Just be careful to track down and update all places where your existing key is used before deleting it to prevent unexpectedly breaking your application or abruptly losing access to one.

Wrapping up

Securing API keys is a vital step in protecting your cloud ecosystem. Implementing strict API and application restrictions, utilizing secure storage, and proactively monitoring consumption are highly effective ways to prevent unauthorized access. These practices safeguard your development environment from exploitation and prevent unexpected billing charges.

To help you implement these practices, here are a few practical tools and resources you can explore next:

Check more about APIs: Review Best practices for managing API keys and practice Search for and use Google APIs.
Watch a quick tutorial: Check out this great Google Cloud Tech video on Manage your Cloud Run secrets securely with Secret Manager to see secure storage concepts in action.
Get hands-on with a Codelab: Practice fetching credentials safely in a guided environment by trying Secret Manager with Python or with Spring Boot codelabs.

Dive deeper into the docs: Learn about how to select metrics, create charts and set up alerts to observe your API consumption.

What Google I/O '26 means for developing agents on Google Cloud

Tue, 19 May 2026 17:45:00 +0000

At Google I/O, we introduced a unified development toolkit featuring Antigravity 2.0 and the Managed Agents API, giving developers better ways to build locally and deploy securely to the cloud on a shared protocol layer. In this blog, we’re going to show you how Gemini Enterprise Agent Platform and the new developer tools shared at I/O fit together, unpack the spectrum of choice for building, and share what we’d actually try first.

Following the evolution of Vertex AI into the Gemini Enterprise Agent Platform – a comprehensive platform to build, scale, govern, and optimize agents with new features like session memory and centralized governance – we are now extending these capabilities directly into your local development tools. Our goal is to bridge the gap between high-speed prototyping and secure, compliant corporate deployment, offering a modular approach where you can choose between quick-start workflows or full production control to fit your stack's specific needs.

Here’s how those pieces now lay out across the entire spectrum of choice.

The four rungs: The spectrum of how to build agents

We like to think of the agent development ecosystem as four rungs on a ladder, designed to give you a clear slider between out-of-the-box configuration and complete code-first control. They're deliberately additive, meaning that starting fast on the lower rungs above never locks you out of graduating to the deeper customization of the rungs above.

Underneath all four rungs is the A2A protocol. This interoperability ensures that an agent built on the first rung can be called as a sub-agent on the fourth rung, allowing your entire architecture to scale seamlessly on the same infrastructure.

Rung one: Agent Studio (low code)

A visual workspace inside Agent Platform. You discover models in Model Garden, engineer prompts, wire up tools, and ship an agent without writing code. Best for business-facing teams and rapid prototyping. The agent you build here runs on the exact same runtime as everything below it.

Rung two: Managed Agents API

New at I/O, the Managed Agents API is for technical teams who want to “manage the mission, not the machine." It allows you to define agentic behavior and let Google Cloud handle the heavy lifting, acting as an agent-as-a-service with nothing to manage.

You use the Managed Agents API to configure your agent, and the Interactions API to invoke it. You package your instructions, skills, and tools, POST them, and Gemini builds and runs the agent.

What makes this deployable is the Google Cloud sandbox, which is secure by design. The agent harness runs on our servers, and each agent has its own ephemeral sandbox provisioned with your skills, Model Context Protocol (MCP) servers, and server-side tools. Full integration with A2A and Agent Platform governance and security are coming soon.

Rung three: Antigravity and friends

Antigravity is our primary solution for developers looking to leverage AI for coding tasks and agent orchestration, enabling teams to transform how apps are built and deployed. We've consolidated our developer-facing coding strategy into this single, powerful harness shared across multiple surfaces.

It’s co-optimized with the Gemini family of models, offering high efficiency to speed up development cycles and reduce costs. Skills you develop with Antigravity are intended to be portable across different surfaces.

This is for development teams who want to utilize Google's advanced reasoning capabilities within their coding workflows, implement custom development loops, and transform how they build, deploy, and manage applications.

Today, we are expanding this with new tools:

Antigravity 2.0: A new standalone desktop application providing a centralized workspace to steer, customize, and orchestrate coding agents. Developers can use this to manage complex tasks, such as orchestrating agents to refactor code, generate unit tests, or even scaffold new service components based on a specification. Agents can spin subagents from a single prompt, while multi-agent orchestration allows tasks to run in parallel.
Antigravity CLI: This brings the full Antigravity experience to the command line: same harness, same agent, same quality of intelligence as Antigravity 2.0, with a product experience tailored for the terminal. It's optimized for speed and lower overhead, and adapts entirely to you. The CLI is tightly integrated with the desktop app, sharing authentication, context, skills, and configurations, providing a consistent experience across both interfaces. Use the Antigravity SDK to build your own runtime.
Enterprise security and compliance: Google Cloud customers can now use Antigravity 2.0 and Antigravity CLI with their Gemini Enterprise Agent Platform project. All you have to do is to log in with Cloud OAuth, set your Agent Platform Project ID and region. This ensures that all agent inference runs via Agent Platform models within your secure cloud boundary, inheriting Google Cloud’s standard data privacy protections and Terms of Service. This ensures your customer data is in your control , and you can utilize regional model endpoints.

Integrating other coding agents

While Antigravity is our recommended agentic coding solution, Google Cloud is designed to work well with any coding agent you choose. Our platform is open, and we provide tools to ensure flexibility:

The Agent CLI and Agent Development Kit (ADK) allow you to build and interact with agents from various sources, including tools like Claude Code. This means developers can often keep their preferred interfaces while running the underlying AI inference on Google Cloud. This approach ensures your workflows benefit from Google Cloud's security, compliance, and infrastructure.
Our Skills for Google products, launched at Next, are designed to be compatible with multiple coding tools, enabling you to enhance different agents with a consistent set of capabilities.

This flexibility allows teams to integrate their existing favorite tools and models, ensuring seamless and compliant operation within their established workflows.

Rung four: Agent Development Kit (ADK 2.0)

Code-first, low floor, high ceiling. If Managed Agents are configuration-first, ADK is engineering-first. This is for software engineers who want to build custom agent meshes from the ground up - any architecture, any model, unconstrained.

ADK enhancements launched at Google Cloud Next are now available for everyone. It introduces a unified graph-based engine that gives you a slider from dynamic, model-led reasoning to strict, deterministic workflows. The framework handles the heavy lifting of multi-agent coordination, managing how sub-agents, tools, and data pass between one another.

Collaborative workflows (Python v2.0.0): Previously called the Task-based Agent Collaboration API, this is how you build self-managing agent teams. A coordinator delegates to subagents using explicit operating modes:
- chat: Full user interaction, manual return to parent, this is “handoff conversation to sub-agents”.
- task: User interaction for clarifications, automatic return to parent, this is a new “collaborate for this assignment” which is the best of both other options.
- single-turn: No user interaction, parallel execution, automatic return, this is “agent as tool”.
Dynamic workflows: Dynamic workflows in ADK allow you to put aside graph-based path structures and use the full power of your chosen programming language to build workflows. With Dynamic workflows, you can create workflows with simple decorators, invoke workflow nodes as functions, and build complex routing logic.
ADK Kotlin (Beta): "ADK for Android." Kotlin support joins Python, Go, and Java, increasing language coverage so your on-device mobile agents can seamlessly coordinate with your backend Python agents.

Finally, the Agents CLI packages Google's expert skills for ADK, eval, deploy, observability, and publishing - turning any AI coding agent (like Antigravity, Gemini CLI, Claude Code, or Cursor) into an expert at agent app building as well as agent ops. It gives your AI Agent skills to understand the Google Cloud agent stack, turning an expansive ecosystem into a seamless assembly line for developers hillclimbing their agent builds.

What we'd actually try first

If we were starting today, here's the order we'd reach for things:

Start with the Antigravity 2.0 desktop app: Explore the interface, add a pre-built agent, and interact with it to understand the core functionality. This provides a more intuitive entry point before diving into API specifics.
Build a mesh: Feel free to explore Managed Agents API through the Agents API skill and Interactions API skill. When you start hitting routing decisions you want to make explicit, or need complex multi-agent orchestration, port your logic to ADK 2.0. The graph model is worth the learning curve as soon as you have more than two branching paths. Don't worry about stringing together a bunch of separate pieces to make this happen - this is exactly where the Agents CLI shines.
Govern and reuse shared domain logic: Check out Skill Registry (public preview): A centralized catalog to govern and promote the reuse of packaged domain logic. Skills are accessible via the Managed Agents API, Agent Platform SDK, and ADK (via SkillToolset). Skill Registry will be part of Agent Registry shortly.
Evaluate: Use the Gemini Enterprise Agent Platform evaluation suite to move beyond basic text-matching vibe checks. Leverage synthetic user simulation to auto-generate multi-turn testing scenarios and safely mock API environments to pressure-test tool resilience. Finally, utilize its LLM-based autoraters and trace logging to evaluate complex logic, group failures, and continuously optimize your agent.
Secure the pipeline: Leverage Gemini Enterprise Agent Platform governance capabilities like Agent Identity, Agent Gateway, Agent Security, and Agent Registry to secure your deployment. Once CodeMender releases, add it to your CI/CD to proactively secure the code your human (and AI) developers are pushing.

Note: You can do this whole loop on a Google Cloud Starter Tier account without a billing account attached. First two app deployments are on us.

We’re excited and hope you are, too

The agent space is evolving rapidly. Agent Platform offers a secure and adaptable foundation. Core components like the Agent Gateway, identity management, and the Skill Registry work together to ensure a robust and controlled environment for your agents, enabling you to innovate flexibly without vendor lock-in.

Pick the rung that fits the project. Bring whatever coding agent your team prefers. The platform you graduate to is the same one either way, and the data stays inside your Cloud project the whole time.

If you only read one set of docs after this post, make it the Agents overview in the Agent Platform documentation. If you build something interesting, show us - the best examples will land in the next round of templates.

We can’t wait to see what you build!

Gemini Live Agent Challenge: Announcing the winners and highlights

Fri, 15 May 2026 16:00:00 +0000

The Gemini Live Agent Challenge is officially in the books! We challenged developers worldwide to break out of the traditional 'text box' paradigm by building next-generation AI agents. From our initial announcement to amassing 11,878 participants and 1,536 submitted projects from 151 countries, the results were nothing short of spectacular.

The mission was to seamlessly integrate multimodal capabilities—building agents that help you see, hear, speak, and create in real time — using the Gemini Live API, the Agent Development Kit (ADK), and the robust infrastructure of Google Cloud. Participants pushed the boundaries of interactive AI across three distinct categories: The Live Agent, The Creative Storyteller, and The UI Navigator.

Congratulations to the builders who took home the top prizes! These winning teams combined technical precision with bold imagination, completely redefining how users can interact with and experience agents. Two of these standout developers were even recognized in person at Google Cloud Next 2026. Here’s a look at their experience, alongside the complete list of winning agents.

Celebrating our category winners at Google Cloud Next ‘26

Category winners Jeremiah Somoine and Bryen Param were invited to attend Google Cloud Next 2026 in Las Vegas, where they shared their experiences and insights with the broader developer community. Both winners presented Lightning Talks at the Developer Theatre on the expo floor and sat down for exclusive interviews in the Creator Studio Pod at the GDE and Certified Lounge.

During his time at the event, Bryen discussed the core inspiration behind drone-copilot. He explained that his project was driven by the question of "what if a model could interact with the real world?", showcasing how multimodal capabilities can bridge the gap between AI and physical environments.

Jeremiah, currently a college student, reflected on the development process behind Sankofa, noting that "the best response to a technical limitation was a creative one." When asked what advice he would give to other students looking to build the next generation of AI applications, he emphasized the importance of jumping at any opportunity to get hands-on with the technology. "The best way to learn is by doing," he said, encouraging aspiring developers to simply dive in and start building.

Winners

Grand Prize winner: ORION - Operating Room Intelligent Orchestration Node
By: Aditya Shukla

ORION, or Operating Room Intelligent Orchestration Node, is a voice-directed surgical co-pilot for robotic surgery. Surgeons can speak naturally and instantly receive answers, live data on display, and real-time visual assistance - all without breaking scrub.

The Live Agent winner: drone-copilot
By: Bryen Param

Drone-copilot transforms how users interact with hardware by enabling natural, real-time conversations with a drone instead of using a joystick or complex menus. Simply by speaking, users can instruct the drone to navigate, perform autonomous visual inspections, or describe its surroundings, while the drone verbally responds and confirms its actions in real time.

Creative Storyteller winner: Sankofa
By: Jeremiah Somoine

Sankofa acts as a multimodal AI "griot"—a traditional West African storyteller—transforming fragmented family histories into deeply immersive narratives. Based on just a few user details, it weaves together rich voice narration, watercolor imagery, and ambient soundscapes into a historical story, allowing users to engage in a real-time voice conversation with the storyteller to explore their roots further.

UI Navigator winner: Moonwalk
By: Enaiho Uwas Paul and Aman Kumar Sah

Moonwalk is a conversational, hands-free desktop assistant that helps users intuitively navigate their computer and complete complex tasks using just their voice. By remembering personal preferences and past interactions, it acts as an intelligent co-pilot that can seamlessly control your mouse and keyboard to execute everyday workflows—like booking flights or managing spreadsheets—while you simply sit back and speak.

Best multimodal integration and user experience winner: Wand
By: David Li

Wand is a voice-first, pointer-aware browser assistant that helps you seamlessly navigate and interact with any website using a combination of natural speech and hand gestures. By simply pointing at your screen and speaking — like asking to "play this video" or "zoom in here"—this live agent helps you instantly execute clicks, searches, and commands without ever needing to touch a mouse or keyboard.

Best technical execution and agent architecture winner: JohnKeats.AI
By: Matthew Keats

JohnKeats.AI is a voice-first emotional companion designed to actively listen and hold space for users without rushing to offer solutions. By processing subtle vocal cues like pitch, pacing, and tone, it reacts naturally to a user's emotional state in real time to provide a deeply reflective and empathetic conversational experience.

Best innovation and thought leadership winner: Rayan Memory
By: Yusuf Elnady

Rayan Memory tackles the universal problem of forgetting by turning your daily learnings into a fully explorable 3D "memory palace." A background agent passively listens to your real-world audio to extract important ideas as physical artifacts, allowing you to walk through themed virtual rooms and converse with a dedicated AI companion to easily retrieve your exact memories.

Honorable mention: NagarDrishti
By: Nikita Dongre and Omkar Dongre

NagarDrishti tackles dangerous road conditions by allowing citizens to safely report potholes and waterlogging using a hands-free voice assistant while driving. These real-time reports instantly populate an interactive dashboard, where city officials can use natural language to easily identify hazard hotspots and manage critical repairs.

Honorable mention: Ekaette
By: Bassey John

Ekaette revolutionizes customer service by replacing frustrating hold queues with a conversational, multimodal AI assistant that operates across live phone calls and text messaging. Customers can speak naturally with the agent over a standard phone line while seamlessly sharing photos, reviewing product options, or completing payments via WhatsApp, c

Honorable mention: VibeCat
By: Sejun Kim and Michael Chang

VibeCat is a proactive macOS desktop companion that continuously watches your screen, understands your context, and suggests helpful actions before you even ask. Instead of waiting for a command, it speaks up first — like offering to fix a missing line of code or execute a terminal command — and completes the task only after receiving your permission.

Honorable mention: Call My Parts
By: Sugam Palav, Nikhil Lohar, Siddhant Panday, and Vishal Parekh

Call My Parts automates the tedious, time-consuming process of sourcing used vehicle parts by doing the research and vendor outreach for you. Users simply speak their part request, and the AI agent autonomously searches vendor websites, calls suppliers to check pricing and inventory, and compiles the best options into a ranked, easy-to-read dashboard.

Honorable mention: Relay
By: Faith Ogundimu

Relay is an interactive AI lab partner that uses your webcam to watch and guide your physical electronics projects in real time. It provides step-by-step voice instructions to help you build circuits, catches wiring mistakes before they happen, and reinforces your skills with a built-in 3D simulation sandbox and adaptive quizzes.

Keep the momentum going

Inspired by these incredible projects? Start building and stay connected with the community through our latest programs and events:

Join Gemini Enterprise Agent Ready (GEAR), designed to help developers and decision-makers build and deploy production-ready AI agents.
Catch up on Google Cloud Next 2026: We just wrapped up an amazing Google Cloud Next! If you weren't able to join us in person — or simply want to relive the energy — take a look at our social and livestream recaps to catch up on some of the exciting developer activations straight from the expo floor.
Tune in on Tuesdays: Want to be the first to hear about new tools, product updates, and upcoming hackathons? Join us for our weekly livestream every Tuesday 9:00 A.M. PDT / 12:00 P.M. EDT for the latest in all things Google Cloud.

Congratulations again to all of our winners and participants. We can't wait to see what you build next!

Ship code within minutes with the Gemini CLI DevOps Extension

Fri, 08 May 2026 19:00:00 +0000

With AI coding tools like Antigravity and Claude Code, I can build a working web app in record time. But deploying it? That's where I'd historically lose the rest of the afternoon to Dockerfiles, IAM bindings, and YAML. So I'd take the shortcut most developers take: I just wouldn't do it. The app would stay on my laptop, and my work would never ship.

This is the classic tension between the inner loop: the fast, local cycle of writing and testing code, and the outer loop: containerization, CI/CD pipelines, and production infrastructure. Most developers are productive in one but not the other, and the gap between them is where projects stall.

The Gemini CLI Extension for CI/CD bridges this gap. It handles both quick deployments and full pipeline generation from a single terminal interface. Let me show you how.

Building the Cosmic Guestbook App

To demonstrate this workflow, we need an app. Let's start from an empty directory and use our agent to "vibe code" a brand new project: the Cosmic Guestbook.

We want a full-stack architecture: a React frontend and a Node.js Express backend API. Instead of scaffolding this by hand, we can ask our agent to jumpstart the app:

code_block: <ListValue: [StructValue([('code', '"Build a \'Cosmic Guestbook\' web app. I need a dynamic Node.js Express backend and a React frontend utilizing Vite. Make the frontend look like a beautiful, glassmorphic sci-fi interface."'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d2b0>)])]>

Within moments, our agent scaffolds the backend/ directory with server.js and the frontend/ directory with a fully styled React app. We now have a functioning, two-tier web app sitting on our laptop.

Installing the Extension

But code on a laptop isn't shipping. To get this guestbook online, we need to equip our chosen environment with the CI/CD extension. Regardless of your setup, start by ensuring that you have the gcloud CLI installed and authenticate using Application Default Credentials: gcloud auth application-default login.

Now, install the extension in your preferred development environment:

For Gemini CLI

Run the following command directly in your terminal:

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/gemini-cli-extensions/cicd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d310>)])]>

For Claude Code

Add the marketplace and install the plugin directly from the terminal:

code_block: <ListValue: [StructValue([('code', '# 1. Add the Marketplace\r\nclaude plugin marketplace add https://github.com/gemini-cli-extensions/cicd.git\r\n\r\n# 2. Install the Plugin\r\nclaude plugin install cicd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d370>)])]>

For Antigravity and agents supported by npx skills

You can enable the extension's MCP Server as custom MCP and add skills to your workspace:

code_block: <ListValue: [StructValue([('code', '# Add the Skills\r\nnpx skills add https://github.com/gemini-cli-extensions/cicd --global --all --agent antigravity'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d3d0>)])]>

How It Works

The CI/CD extension is a powerful three-tier system designed to translate your intent into secure, production-ready infrastructure in all these agent environments:

Skills: Specialized AI skills like google-cicd-deploy and google-cicd-pipeline-design are defined in the extension. These instruct your AI agent (Gemini CLI, Claude Code, or Antigravity) on how to think—helping it analyze your code, ask the right questions, and handle errors gracefully.
CI/CD MCP server: Running in the background is a specialized Go-based Model Context Protocol (MCP) server. This server provides a suite of tools that gives your agent the hands it needs to actually manipulate Google Cloud: everything from scanning for secrets to provisioning Cloud Run services.
Local knowledge base: To ensure the most accurate answers, the system includes a pre-indexed retrieval-augmented generation (RAG) database containing verified architecture patterns, which lets the agent ground its design decisions in the source of truth.

Your chosen AI assistant orchestrates these tools and patterns into a cohesive deployment lifecycle.

The Inner Loop

When you're building a prototype or testing a new feature, you don't need a massive, multi-environment CI/CD pipeline. You just need a public URL to test your webhook or show a stakeholder. This is the inner loop, and it needs to be fast.

The traditional approach involves manually writing a Dockerfile, authenticating with a container registry, building the image, pushing it, and finally deploying it. The CI/CD extension turns this into a single natural language prompt: gemini "Deploy this application to Google Cloud using the google-cicd-deploy skill". If you're using Claude Code, you can prompt it exactly the same way via claude -p "Deploy this application...", and in Antigravity, simply type your deployment request.

When you run this prompt, your AI agent analyzes your local workspace to figure out the best deployment approach.

Step 1: Pre-Deployment Security Scan

Leaked secrets are one of the most common and expensive security failures in software. GitGuardian's 2025 State of Secrets Sprawl report found 23.8 million new credentials exposed on public GitHub in a single year; 70% of secrets that were leaked in 2022 are still active today. It happens fast: you hardcode a database password during local testing, forget to remove it, and push.

The extension catches this before it becomes a problem. Before any code leaves your machine, it runs a secret check across your workspace. If it finds a Stripe API key or a database credential sitting in your source, the agent halts the deployment and warns you. No secrets ship to the cloud by accident.

If you accidentally commit a database password or a Stripe API key while hacking on localhost, your assistant catches it and prevents the deployment. This is what true shift-left security looks like in practice.

Step 2: Application Analysis & Containerization

Next, your agent checks your package.json or go.mod to figure out your framework. It automatically decides whether to use Google Cloud Storage (for static sites) or Cloud Run (for dynamic services).

If you're building a dynamic service that doesn't have a Dockerfile, the extension leverages Google Cloud's buildpacks to containerize it for you on the fly.

Step 3: Clarification and Deployment

Conversational agents don't blindly guess how you want your app configured. Before making any changes to your Google Cloud environment, the assistant pauses the flow to ask prioritizing questions based on what it found during its analysis.

For our Cosmic Guestbook, I didn't specify a region or whether the service should be public. The assistant paused and asked me about it:

"I have completed the analysis and prepared the application for a unified deployment to Cloud Run. Since the Node.js buildpack requires a single entry point, I created a root package.json with a custom build script that builds the React frontend and allows the Express backend to serve it statically.

Additionally, the secret scan completed successfully, and no sensitive credentials were found.

Before we deploy using the Cloud Run source deployment option (buildpacks), I need to clarify a few deployment parameters:

Region/Location: The gcloud defaults do not specify a location. Which Google Cloud region would you like to deploy to (e.g., us-central1, europe-west1)?
Access: Should this application be publicly accessible or private?
Service Name: I propose naming the service cosmic-guestbook. Does that sound good to you?"

This conversational pause ensures that even in the fast inner loop, you retain complete control over your cloud architecture. After you confirm the details, the agent pushes the code live and returns the public URL:

code_block: <ListValue: [StructValue([('code', '# Final Output:\r\nYour application is now live and publicly accessible at the following URL:\r\nhttps://cosmic-guestbook-xxxxxxxx-uc.a.run.app'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d430>)])]>

Behind the scenes, the deployment is handled automatically via cloudrun.deploy_to_cloud_run_from_source.

The Outer Loop

A scrappy deployment prompt is perfect for a Tuesday afternoon prototype, but you can't run a production system from your laptop. Eventually, you need the rigors of the outer loop: automated testing, source control integration, and formal continuous deployment.

Writing cloudbuild.yaml files and provisioning the necessary infrastructure (like Artifact Registry repositories or GitHub connections through Developer Connect) is notoriously tedious and error-prone. With the google-cicd-pipeline-design skill, your AI agent acts as your personal platform engineering consultant.

Instead of writing YAML from scratch, you have a conversation. Your agent will ask you about your testing strategy and where you want to deploy, and then it autonomously provisions the required Google Cloud infrastructure.

Step 1: Architectural Design & Feedback

You start the process directly in your conversational interface:

code_block: <ListValue: [StructValue([('code', '# Prompt your agent to kick off the design process:\r\ngemini "Design a CI/CD pipeline using the google-cicd-pipeline-design skill"\r\n# OR\r\nclaude -p "Design a CI/CD pipeline using the google-cicd-pipeline-design skill"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d490>)])]>

Your assistant doesn't work in a black box. It retrieves common CI/CD patterns from its knowledge base. With the most relevant knowledge in hand, it proposes a concrete plan in YAML for you to review.

Step 2: Infrastructure Provisioning

After you approve the plan, the assistant works sequentially through the required infrastructure steps. For example, it might first create a registry for your containers.

code_block: <ListValue: [StructValue([('code', '// Example MCP call to provision the registry\r\n{\r\n "name": "create_artifact_repository",\r\n "arguments": {\r\n "repository_id": "demo-app-repo",\r\n "location": "us-central1",\r\n "format": "DOCKER"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d4f0>)])]>

It might then set up a Git connection so that Cloud Build can read your source code.

Step 3: Pipeline Generation & Trigger

Finally, the agent generates the actual cloudbuild.yaml file that defines the pipeline stages (test, build, deploy). Here's a snippet of a generated configuration from the repository that highlights the initial build steps:

code_block: <ListValue: [StructValue([('code', 'steps:\r\n # Step 1: Install tools (like the linter) and clean the cache.\r\n - name: \'golang:1.24\'\r\n id: \'Install Tools\'\r\n entrypoint: \'sh\'\r\n args:\r\n - \'-c\'\r\n - |\r\n set -e\r\n export PATH=/workspace/bin:$$PATH\r\n echo "Installing golangci-lint..."\r\n go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.8\r\n echo "Cleaning module cache..."\r\n go clean -modcache\r\n env:\r\n - \'GOPATH=/workspace\'\r\n dir: \'devops-mcp-server\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d550>)])]>

With the pipeline defined, we need a way to execute it automatically. The agent finishes by creating a Cloud Build trigger. The trigger acts as the glue between your GitHub repository and Cloud Build, ensuring that every push to the main branch automatically fires off the cloudbuild.yaml steps.

code_block: <ListValue: [StructValue([('code', '// Example MCP call setting the trigger\r\n{\r\n "name": "create_build_trigger",\r\n "arguments": {\r\n "trigger_name": "main-branch-deploy",\r\n "filename": "cloudbuild.yaml",\r\n "branch_pattern": "^main$"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb5c5a0d5b0>)])]>

Security And Control

AI-assisted infrastructure generation sounds incredible, but it's reasonable to ask: is it safe?

The extension operates strictly within the permissions of your local Application Default Credentials (ADC). It can't do anything that you can't do. Because it uses the Model Context Protocol (MCP), every action that it takes, from creating an Artifact Registry to modifying a Cloud Build trigger, runs through strongly typed, verifiable tools.

If you don't like a step in the proposed pipeline, you tell your agent to change it. You're always the "Editor-in-Chief" of your infrastructure. We strongly recommend that you adhere to the principle of least privilege for both your local ADC and any service accounts that are used by the generated pipelines.

When Dev and Ops Converge

The friction between wanting to write code and needing to ship it is finally dissolving. We're moving past the era where deep expertise in YAML formatting was a prerequisite for putting an app on the internet.

By handling the boilerplate of both the scrappy inner loop and the automated outer loop, conversational AI lets developers focus on the business logic that actually matters.

Next Steps

If you want to experience this convergence yourself, here are your immediate next steps:

Get the tools: Install the CI/CD Extension for Gemini CLI.
Deploy the inner loop: Take an existing side project (or ask your chosen agent to scaffold a new one like our Cosmic Guestbook) and prompt it to deploy to Google Cloud to instantly see it live on Cloud Run or Cloud Storage.
Automate the outer loop: Run a design command against a repository that you're ready to productionize, and watch your agent generate your cloudbuild.yaml and provision your infrastructure.

Stop wrestling with configuration files and start shipping. Let me know what you build by reaching out on LinkedIn, X, or Bluesky!

How BASF manages thousands of supply chain decisions with AlphaEvolve’s agentic algorithms

Thu, 07 May 2026 16:00:00 +0000

The agricultural and crop protection supply chain is one of the most intricate networks in the world. It takes up to two years to turn active ingredients into the final products farmers need, and a single change in weather or regulations can disrupt everything. Planners at BASF Agricultural Solutions navigate this reality daily across 180 production sites. To understand how local decisions ripple across their entire global network, BASF turned to AlphaEvolve on Google Cloud to build a digital twin of their supply chain.

Planning across a two-year lead time

BASF Agricultural Solutions manages a network with over 5,000 distinct value chains. Creating a single end product requires a bill of materials that can be over 30 levels deep, moving across different production sites and regions.

Currently, human planners make thousands of local decisions every day. They decide what to produce, when to produce it, and how much safety stock to hold. Because the network is so large, a planner can’t easily see how a localized decision affects the rest of the global supply chain.

This scale can lead to additional working capital and inventory and or cause production imbalances. Traditional mathematical models struggle to capture the dynamic reality of the network that planners navigate based on years of experience.

Building a foundation for decision support

AlphaEvolve is an evolutionary coding agent that generates and refines algorithms autonomously. In collaboration with Google Cloud and prognostica GmbH, BASF’s objective was not to replace human decision-making, but to establish a new model for decision support that helps planners handle the real-world complexity of the production network.

The team gave AlphaEvolve a foundational "seed" program. This initial code established a standard planning logic that translated demand forecasts into production schedules, serving as a functional baseline before introducing dynamic, network-wide coordination. From there, they fed the model three years of historical data, including inventory levels, market demand, and actual production outputs. AlphaEvolve then generated variations of the code, mutating the logic to see if it could simulate a supply chain that matched the real-world historical data.

Measuring what good looks like in initial tests

For AlphaEvolve to improve, it needed a specific goal. The evaluation function scored every new piece of generated code on one primary metric: how closely the simulated inventory levels and production decisions matched the actual historical reality recorded by BASF.

The latest AlphaEvolve runs delivered more than 80% relative improvement in accuracy compared to the initial seed model. With further adjustments, the team expects to push performance even higher — bringing the model to a level of accuracy not achieved with other approaches and making it actionable for operational use.

The results

The evolved planning logic delivered immediate, measurable improvements over the initial seed model. The final algorithm successfully mirrored the actual historical performance of the supply chain, significantly reducing the error rate compared to the initial seed.

“We had several attempts to build a digital twin for our complex supply network using deterministic models, and all of them failed,” said Dr. Goetz Krabbe, vice president for global supply chain at BASF. “By using AlphaEvolve, we cannot only map the complex network based on system data, but at the same time understand and copy the human decisions that drive our daily operations. This gives us a highly accurate and easy to maintain data driven digital twin of the entire network. Using it we can optimize our inventory levels and respond to market volatility with confidence while avoiding stockouts."

What the evolved algorithm actually does

By running thousands of experiments, AlphaEvolve developed a clear, human-readable algorithm that explains how the BASF network truly operates. It automatically discovered factually correct, domain-specific supply chain rules that explain the observed production outputs and inventory levels for the tested product value chain:

Production consolidation: The algorithm learned to group production amounts together, accurately mapping how planners optimize plant time.
Dynamic safety stocks: It introduced safety stock parameters to handle volatile and seasonal demand patterns, helping to strictly manage capital costs while preventing out-of-stock situations.
Network-wide coordination: The model successfully mapped the dependencies between different production tiers, providing a clear foundation for optimizing asset utilization globally.

What's next

The initial simulations showed that evolutionary AI can accurately model large-scale, dynamic supply chains. BASF’s objective is to create a digital twin of their entire global production network as a new foundation for simulation, decision support, scenario forecasting and optimization. This will allow the team to continuously simulate operations, identify hidden bottlenecks before they affect throughput, and optimize asset utilization across all global facilities.

_{This project was a collaboration between the BASF SE team including: Benjamin Priese, Michael Arlt, Debora Morgenstern and Tobias Hausen as well as Manuel Doerr and Thomas Christ from Prognostica GmbH Würzburg, and the AI for Science team at Google Cloud including (but not limited to): Kartik Sanu, Laurynas Tamulevičius, Nicolas Stroppa, Chris Page, Srikanth Soma, John Semerdjian, Skandar Hannachi, Vishal Agarwal and Anant Nawalgaria as well as Christoph Tittelbach from the Google account team and partners at Google DeepMind}

Pioneering AI-assisted code migration: How Google achieved 6x faster migration from TensorFlow to JAX

Wed, 06 May 2026 16:00:00 +0000

AI coding agents are rapidly becoming ubiquitous across the software industry, fundamentally changing how developers write, test, and debug daily code. While these tools excel at localized, self-contained tasks, applying them to massive, systemic codebase migrations requires an entirely new approach.

Google is already addressing this challenge by incorporating AI into many migration workflows: x86 to ARM (enabling workloads on Google Axion processors); int32 to int64 identifiers (to avoid running out of ids); JUnit3 to JUnit4 (for testing); and Joda-Time to java.time (a modern time library). However, AI model migration represents a whole new level of complexity that requires even more advanced methods for AI-assisted migration.

Translating a production-grade machine learning model from one framework to another, for example, from TensorFlow (TF) to JAX, is not a simple syntax update. It is a long-horizon task that requires untangling thousands of lines of code, managing complex states across multiple files, and preserving precise mathematical equivalence. Generic, single-agent coding assistants typically struggle under this weight — they frequently lose context over long workflows, hallucinate APIs, or fail to produce buildable code across an entire repository.

Google’s AI and Infrastructure team has pioneered a new approach to this industry-wide problem. The result is 6x faster model migration, a milestone Sundar highlighted in the recent Google Cloud Next keynote. In this post, we share how we deployed specialized, multi-agent AI systems to migrate some of Google’s largest-scale production models from TF to JAX.

Accelerating the transition from TF to JAX

For many teams at Google — and across the industry — the future of scalable machine learning is being built on JAX. Designed around a functional, stateless paradigm, JAX is heavily optimized for modern Tensor Processing Unit (TPU) infrastructure and XLA compilation, making it the bedrock of the modern AI stack.

Evolving to this future presents a monumental challenge. Thousands of production models are built on TensorFlow, a framework characterized by object-oriented, stateful layer initialization and static execution graphs. Manually migrating these models to JAX requires a fundamental rethinking of how layers interact, and how state is explicitly managed. Across large organizations, this type of migration alone represents hundreds (if not thousands) of software engineering (SWE) years — time better spent on researching new architectures and driving product innovation.

Overcoming this challenge with AI started as an ambitious experiment within Google’s AI and Infrastructure team, but has evolved into a repeatable blueprint for addressing complex engineering problems across the company.

Moving beyond single-agent coding

Our early experiments with agentic code translation showed promise for simple models. However, when faced with the realities of a Google-scale migration — complex, production-grade models spanning multiple files and thousands of lines of code — generic, single-agent setups struggled. They could not balance high-level structural rules with low-level execution details, resulting in a variety of failures, such as overwriting critical files or skipping necessary functionality. To overcome these common challenges inherent to enterprise migrations, we developed a highly specialized multi-agent architecture that consists of:

The Planner agent: Using deterministic, compiler-based static analysis, the Planner maps out the codebase's entire dependency tree. It then works alongside other agents to break the migration down into a discrete, step-by-step plan, helping ensure the migration happens logically from the "leaf nodes" (layers without unmigrated dependencies) upward.
The Orchestrator agent: This agent acts as the project manager. It dynamically groups plan steps into manageable chunks to keep the context window focused, injects the necessary domain knowledge, and handles failure recovery if a step doesn't build.
The Coder agent: Built as a reasoning and acting agent, the Coder is the workhorse. Integrated directly into our internal IDE tools, it has the ability to read files, write code, run builds, and execute unit tests. Crucially, it operates in a "test-and-fix" loop, self-correcting until it produces a compilable, verifiable component in the target language.

Figure: Multi-agent AI system for complex code migrations. Process diagram describing the multi-agent system used to migrate legacy model code to JAX. Image generated with Gemini Nano Banana 2.

Scalable validation and dynamic Playbooks

Generative AI models are only as good as the context they are provided. Because source and target architectures rarely map 1-to-1, we engineered a scalable, hierarchical system of Playbooks.

These Playbooks range from general repository instructions to highly specific "golden examples" distilled from successful manual migrations. By feeding the Orchestrator a client-specific Playbook (for instance, one tailored to YouTube's unique ranking model infrastructure), the system avoids generic hallucinations and strictly adheres to internal coding standards. This Playbook architecture is framework-agnostic, meaning it can be adapted to guide migrations between any two programming languages or frameworks.

Furthermore, we instituted rigorous quality metrics to ensure the generated code is actually production-ready:

Quantitative verification: For each unit of code, we verify correctness mathematically. In the case of the TF-to-JAX migration, the system utilizes algorithmic gradient ascent to find the maximum error between the original TF layer and the new JAX layer, mathematically verifying functional equivalence.
Qualitative evaluation: We also evaluate the migrated code against a set of qualitative standards. In the case of the TF-to-JAX migration, we deploy a blind-audit LLM Judge that scores the migrated code against a framework-agnostic architectural checklist, so that critical, domain-specific logic is completely captured.

Redefining migration velocity

By deploying this multi-agent system, we dramatically alter the economics of software migration.

In our evaluations on real-world, highly complex YouTube models (featuring thousands of lines of code, hundreds of layers, and deep metric dependencies), the multi-agent system achieved a 6.4x to 8x speedup over performing the migration manually. What traditionally took several SWE-months can now be reduced to only a few weeks of AI-assisted code generation, followed by expert human review.

The system effectively handles the boilerplate, identifies target idioms, maps the dependencies, and generates the unit tests, allowing engineers to act as reviewers and architects rather than manual translators.

Looking ahead into the AI-assisted era

AI is transforming the pace of technological innovation. Without using AI to accelerate our ability to conduct large-scale migrations, it will become increasingly difficult for organizations to adopt the latest breakthroughs and maintain the security, reliability, and performance of their systems.

Our work migrating machine learning implementations from one ML framework to another demonstrates that by combining deterministic static analysis, strict testing loops, and specialized multi-agent architectures, we can safely automate some of the most complex software engineering challenges in the industry. A detailed description of the process is published in our technical paper.

_{This work is the result of collaboration across Google. We thank key contributors: Stoyan Nikolov, Niyati Parameswaran, Bernhard Konrad, Moritz Gronbach, Niket Kumar, Ann Yan, Varun Singh, Yaning Liang, Antoine Baudoux, Xevi Miró Bruix, Daniele Codecasa, Madhura Dudhgaonkar, Elian Dumitru, Alex Ivanov, Christopher Milne-O’Grady, Ahmed Omran, Ivan Petrychenko, Assaf Raman, Stefan Schnabl, Yurun Shen, Maxim Tabachnyk, Niranjan Tulpule, Amin Vahdat, and Jeff Zhou.}

Five must-have guides to move agents into production with Gemini Enterprise Agent Platform

Tue, 05 May 2026 16:00:00 +0000

Building AI agents that work well in a demo is one thing, but running them in production requires serious infrastructure.

At Google Cloud Next '26, we introduced Gemini Enterprise Agent Platform to help developers build, deploy, scale, govern, and optimize autonomous AI agents. From managing long-running state and enforcing security with the Agent Governance Stack, to orchestrating complex workflows using Agent Development Kit, these tools help you treat your agent fleet with the same rigor as your engineering organization. Here is a look back at our five-part series covering the architecture patterns and best practices you need to move your agents into production.

1. Agent design patterns for long-running AI agents

Developers spend weeks perfecting prompt engineering, tool calling, and response latency. But none of that matters when your agent loses its reasoning chain over a five-day task. At Next 26, we announced that Agent Runtime now supports long-running agents that maintain state for up to seven days.

In this article, we’ll share five essential agent design patterns for building long-running agents with Agent Runtime. You’ll learn how to implement checkpoint-and-resume mechanisms to recover from failures without starting over. We also cover how to build delegated approval workflows where the agent pauses for human review while consuming zero compute resources.

Read the full guide on long-running agents here.

2. The agent governance stack

A misconfigured SaaS tool leaks data passively, but a misconfigured agent takes bad actions actively. The pattern we saw with shadow IT in 2015 is repeating itself with AI agents.

To manage this risk, we explain why you must treat your agent fleet with the same rigor as your engineering organization. We outline a five-layer governance stack designed to provide your r security team with precise visibility and control. The foundation begins with Agent Identity, assigning every agent a unique cryptographic badge to isolate access. From there, we explore how to use Agent Registry for centralized tool governance and Agent Gateway to enforce natural language security policies across your fleet. The stack concludes with behavioral anomaly detection and a unified security dashboard to monitor your overall risk.

Read the full guide on the agent governance stack here.

3. Must-have multi-agent orchestration patterns in ADK

Building a single AI skill is relatively straightforward, but orchestrating multiple skills across different agents is notoriously difficult. With the new updates to Agent Development Kit (ADK), we introduced graph-based workflows, collaborative agents, and a formalized skills framework to solve these orchestration failures.

Our third guide details five multi-agent orchestration patterns you can use to build reliable systems. You will find code examples for building hybrid graphs that combine hard-coded business rules with flexible AI reasoning. We also show how to use the coordinator-specialist pattern to avoid building monolithic, unpredictable agents. The guide concludes with deep dives into skill composition, cross-language pipelines, and secure sandboxed executors for running arbitrary code.

Read the full guide on ADK multi-agent patterns here.

4. Deep dive: How A2A and MCP work together

Organizations will rarely build every AI agent they need entirely from scratch. The real value comes when agents built by different teams, in different languages, and across different organizations can securely discover and collaborate with each other.

In our final guide, we explore five integration patterns using the Agent-to-Agent (A2A) and Model Context Protocol (MCP) standards. You will see how Agent Cards allow agents to publish their capabilities so coordinator agents can find them through the Agent Registry. We also show how MCP acts as a universal tool bridge to connect your agents to databases and enterprise systems without custom integration code. The article finishes with strategies for cross-organization federation that involves agents from different organizations collaborating on shared tasks using the Agent Gallery in Gemini Enterprise and building ambient event meshes for agents that react to events continuously in the background, without waiting for user requests.

Read the full guide on agent interoperability here.

5. Atomic agent blueprints on Google Cloud’s Agent Garden

Building multi-agent systems from scratch presents complex design challenges, including finding the optimized design pattern for your use-case, orchestration failures and evaluation loops. You can spend weeks reinventing the wheel, trying to get your agents to be ready for production - or you can start with architectures that already work, with our new Atomic Agents in Agent Garden.

Read the full guide to learn about pre-built Agent Blueprints in Agent Garden

Watch the complete Agent Platform explainer

To see these architectural patterns in practice, watch this technical walkthrough of the Gemini Enterprise Agent Platform. This deep dive covers the complete agent lifecycle, showing you exactly how to move from initial code to a secure, scalable AI Agents in production.

Dive into the code with Agent Platform samples on GitHub

Access our curated repository of code samples and tutorials for the Gemini Enterprise Agent Platform. This GitHub repository provides practical examples for the entire agent lifecycle, giving you the exact code needed to build, scale, govern, and optimize your autonomous fleets.

Get started with Gemini Enterprise Agent Platform

Moving agents into production requires both robust infrastructure and the flexibility to choose the right reasoning engine for the task. The Gemini Enterprise Agent Platform bridges this gap, allowing you to build, govern, and scale autonomous workflows with complete enterprise control.

Through first-class integration with Model Garden, your agent fleet has direct access to more than 200 leading models. You can route tasks to the best available option, whether that is a first-party model like Gemini 3.1 Pro or Lyria 3, an open model like Gemma 4, or third-party models like Anthropic’s Claude, Opus, Sonnet or Haiku.

Visit Agent Platform in the Google Cloud console to explore new features and start building today.

Cloud Engineer’s AI Toolkit: Sign up Now for a Developer Workshop Near You!

Tue, 05 May 2026 15:00:00 +0000

The world of AI is rapidly shifting from experimental Large Language Models to an era of Agentic AI. In the agentic era, autonomous software agents act on behalf of employees and consumers—driving a fundamental change in commerce and business operations. This transition presents a critical new challenge: how to securely build, deploy, and govern agents at enterprise scale.

That’s why we’re hitting the road across North America for a series of hands-on workshops designed to move you past the theory and into production. This isn't a sit-and-listen lecture; it’s a "bring your laptop and build" session. You will gain hands-on experience for the exact skills required to transition your organization into this new agentic era. Whether you're looking to harden your Kubernetes clusters for AI or transform your data warehouse into a powerful engine for autonomous agents, this program will equip you with the practical toolkit used by leading enterprises.

Who should attend

This program is designed for Platform and Security Engineers, as well as Data Practitioners.

For Platform and Security Engineers

If you’re a Platform, Security, or DevOps Engineer, this is your toolkit for securing and scaling the next generation of workloads.

What you need: Foundational knowledge of GKE and containerization.
What you’ll do: Master defense-in-depth strategies, secure inference endpoints, and automate cluster operations using natural language.

For the Data Practitioners

Calling all Data Engineers, Analysts, and Scientists. If you’re ready to bridge the gap between traditional analytics and Agentic AI, this track is for you.

What you need: Some cloud experience and basic SQL. A little Python knowledge goes a long way, but we’ll guide you through the rest!
What you’ll do: Build governed pipelines, unlock multimodal insights from unstructured data, and deploy autonomous agents that turn dashboards into action.

What you’ll build

The labs are designed to take you from raw infrastructure to a full-stack agentic application.

Track 1: Agents & GKE

AI-Augmented Ops: Use Gemini and MCP servers to manage clusters with natural language instead of manual slogging.
Secure Sandboxing: Deploy AI agents in isolated environments to safely execute AI-generated code.
Data at Scale: Use GKE to process massive datasets and create complex knowledge graphs.

Track 2: Data Engineering & Analytics

Governed Ingestion: Use Spark and Knowledge Catalog to build a unified, governed data layer for business-ready insights.
Conversational Analytics: Integrate vector search and multimodal data (images/logs) to create a "talk to your data" experience.
Graph-Powered Agents: Use BigQuery Graph, Knowledge Catalog and the Agent Development Kit (ADK) to build agents that understand complex relationships.

Note: These sessions are interactive. You must bring your own laptop and power cable to participate.

Ready to build?

While theoretical knowledge is valuable, nothing beats hands-on experience guided by Google experts. Registration is officially open for the upcoming sessions listed below. Come build with us! Note that different dates host different tracks.

Track	Location	Date	Registration
Agents & GKE	New York, NY	May 26, 2026	Register Now
Agents & GKE	Austin, TX	June 2, 2026	Register Now
Agents & GKE	Sunnyvale, CA	June 9, 2026	Register Now
Agents & GKE	Seattle, WA	June 11, 2026	Register Now
Agents & GKE	Toronto, ON	June 24, 2026	Register Now
Data Engineering & Analytics	Toronto, ON	June 25, 2026	Register Now
Data Engineering & Analytics	Chicago, IL	June 30, 2026	Register Now

Agent Factory Recap: How Gemma 4 Taught Itself Physics

Tue, 05 May 2026 11:54:00 +0000

In this episode of The Agent Factory, Vlad Kolesnikov and I sat down with Omar Sanseviero from the Developer Experience team at Google DeepMind. We explored the groundbreaking release of Gemma 4: a new family of open models designed to bring high-level intelligence and agentic capabilities directly to consumer hardware and mobile devices. Since the launch last month, Gemma 4 had over 50 million downloads!

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

Gemma 4 - What is it?

Gemma 4 is the latest generation of open models from Google DeepMind, built on the same foundational research as Gemini 3. The family is designed to deliver exceptional "intelligence per parameter" across a range of deployment scenarios, from mobile phones to powerful workstations.The Gemma 4 model family now spans three distinct architectures:

Small Sizes (E2B & E4B): Optimized for ultra-mobile, edge, and browser deployment (such as Pixel or Chrome).
Dense (31B): A powerful 31-billion parameter model that provides server-grade performance for local execution on consumer GPUs.
Mixture-of-Experts (26B MoE): A highly efficient architecture designed for high-throughput tasks and advanced reasoning.

With the shift to an Apache 2 license, these models provide developers and startups with the flexibility to build, modify, and commercialize applications while maintaining full control over their infrastructure.

Omar Sanseviero on how Gemma 4 changes the landscape for agent developers

Timestamp: 1:40

Omar highlighted that Gemma 4 brings "very high intelligence per parameter," making it possible to run agentic workflows entirely offline. We saw examples of multiple Gemma instances running locally to generate SVGs (1:53) and an Android-based agent picking specific skills, like playing the piano, to complete tasks (2:45). As Omar noted, "This means that you can run very powerful things with very little hardware overhead...even in the phone that you have in your pocket."

The Factory Floor

Building a Local Food Tour Agent

Timestamp: 5:29

We showcased a food tour agent powered by Gemma 4 using the Agent Development Kit (ADK) and a Google Maps MCP server. We demonstrated how a local model can handle complex, multi-step reasoning tasks.

The agent identified the best ramen spots in Seattle under a $30 budget.
It verified that the locations were within walking distance of each other.
It processed search results to provide specific tips on what to order and what to avoid.

Autonomous Python Code Execution

Timestamp: 8:03

In this demo, we pushed Gemma 4’s coding capabilities to the limit by asking it to express itself through animation. Using a sandbox execution environment, the model performed the following:

Wrote Python code using the Matplotlib library.
Attempted to build a physics engine to simulate a bouncing ball.
Self-corrected when the initial execution environment lacked certain CPU features, finding an alternative path to successfully generate the animation.
Demonstrated a deep understanding of real-world physics and gravity through code.

The Shift to Apache 2 Licensing

Timestamp: 4:05

A major theme of the conversation was the community-driven decision to move Gemma 4 to an Apache 2 license. This change provides developers and startups with maximum flexibility to build, modify, and commercialize applications. Omar emphasized that this was a direct response to developer feedback, aiming to unlock a new wave of innovation in the open models ecosystem.

Developer Q&A

Architectural Decisions and Mixture of Experts (MoE)

Timestamp: 17:23

Omar explained the technical shifts that make Gemma 4 so efficient. For the first time, the Gemma family includes a Mixture of Experts (MoE) architecture, which optimizes for extremely low latency in production. Additionally, the smaller E2B and E4B models utilize per-layer embeddings to remain "cheap" to run on GPUs. For vision tasks, the model now supports variable aspect ratios, allowing it to understand images of various sizes more accurately than previous fixed-resolution versions.

Comparing Gemma to Gemini

Timestamp: 19:51

When asked how Gemma stacks up against its larger sibling, Gemini, Omar clarified that they serve different purposes. While Gemini excels at massive-scale tasks and deep "world knowledge" due to its size, Gemma is the "best open model that can run on a single consumer GPU." It is specifically optimized for instruction following, coding, and agentic use cases where local deployment or fine-tuning is required.

Fine-Tuning for Specialized Industries

Timestamp: 21:10

The conversation touched on the importance of "Sovereign AI" and privacy. Because Gemma is an open model, developers in regulated industries, like healthcare or finance, can fine-tune the model on their private data and deploy it within their own air-gapped infrastructure. This gives developers full control over their data and the model's specialized expertise.

Conclusion

Gemma 4 marks a turning point for agentic development, proving that you don't always need a massive cloud cluster to build something smart. Whether it's running a physics simulation on a laptop or a travel guide on a phone, the barrier to entry for high-performance AI has never been lower. We are entering an era where the "conductor" of the AI orchestra can be any developer with a single GPU and a great idea.

Your turn to build

Now that you've seen what Gemma 4 can do, it's time to start building. Check out the resources in our show notes, the food tour agent, the coding agent, explore the ADK support, and try running Gemma 4 on your local machine or on Cloud Run. We can't wait to see what agents you create!

Watch more of The Agent Factory → Reinforcement learning & fine-tuning on TP...

Subscribe to Google Cloud Tech → https://goo.gle/GoogleCloudTech

Connect with us

Shir Meir Lador → LinkedIn , X
Vlad Kolesnikov → Linkedin, X
Omar Sanseviero → Linkedin, X

Next '26 Hands-On: 10 Codelabs to Build Featured Tech

Wed, 22 Apr 2026 13:00:00 +0000

Significant contributors to this article include Megan O'Keefe, Senior Staff Developer Advocate, and Karl Weinmeister, Director of Developer Relations.

Whether you are joining us in person in Las Vegas or tuning in virtually from around the world, Google Cloud Next '26 offers a deep look into the practical evolution of AI. With 89% of sessions this year dedicated to artificial intelligence, the focus has shifted from high-level concepts to the "Day 2" reality of building and maintaining agentic systems.

We've assembled 55+ new codelabs across Cloud at Next, and we want to share 10 highlights with you. The following curated list of codelabs is designed to help you translate the announcements from the talks and demos into functional code. These labs provide a structured way to explore the latest in multi-agent orchestration, data grounding, and enterprise security for your own workflows.

Dive into Codelabs!

1—Build Rich Agent Experiences (ADK + A2UI) | Codelab

Improve user interaction through intuitive, high-quality interfaces that allow users to interact with agentic systems seamlessly.

2—Building a Multi-Agent System | Codelab

Build the architecture required to make multiple agents work together to achieve a shared goal.

3—Beyond the Simple SELECT: AlloyDB NL2SQL | Codelab

Democratize data access by building systems that allow users to query complex databases using natural language, supported by high-speed vector search.

4—Beat Fraud with an AI Shield (Spanner & BigQuery Graph) | Codelab

Implement real-time reasoning with Spanner and BigQuery Graph databases. Analyze complex relationships in your data to prevent fraud at the point of transaction.

5—Building Secure Agents: Protecting Access and Data | Codelab

Protect the reasoning engine with Model Armor and Identity and Access Management (IAM) to manage agent access and ensure that sensitive data remains protected during execution.

6—Ground Agents with Google Maps Platform | Codelab

Use Geo-intelligent logistics to ground your agents in real-world location data to optimize field operations and logistics in real-time.

7—Deploy and Scale Agents on Agent Engine | Codelab

Deploy agents as containerized microservices that scale dynamically with your workload.

8—The Ultimate Guide to Cloud Run: From Zero to Production | Codelab

Achieve rapid deployment using this lab as a blueprint for moving from a local prototype to a production-ready, auto-scaling platform on Cloud Run.

9—Developer Keynote: Building Agents with Skills | Codelab

Learn the ins and outs of AI agent development including Agent Development Kit (ADK), prompting, Agent Skill usage, and MCP.

10—General Keynote: Forecasting with AI Agents | Codelab

Transform unstructured chaos into actionable business intelligence in seconds.

Start Building Today

These codelabs will connect you to the heart of the conference. You'll be able to bridge the high-level announcements, talks, and demos into the reality of the technology featured at Next '26. Whether you're here in person or attending virtually, these labs provide the concrete skills to drive real-world value during the conference and long after the conference ends.

And there's more!

Go to the Codelab landing page to find the Cloud Next '26 tag and access more than 75 total codelabs that support the featured tech at this year's conference.

Level Up Your Agents: Announcing Google's Official Skills Repository

Wed, 22 Apr 2026 13:00:00 +0000

As AI models improve, technical practitioners are increasingly turning to agentic AI tools to build with Google Cloud products, from Firebase and the Gemini API, to BigQuery and GKE. But how can you ensure that the model is equipped with accurate, up-to-date information about these technologies?

One way to do this is to plug your AI agent into a grounded, real-time information source. For instance, Google offers a Model Context Protocol (MCP) server for its developer documentation. But heavily using MCP servers can cause a problem called “context bloat,” where huge amounts of context are loaded into the context window, confusing the model and racking up token costs.

We need a way to equip agents with additional, condensed expertise — and we can do this with Agent Skills.

Skills are “a simple, open format for giving agents new capabilities and expertise.” Think of a skill as compact, agent-first documentation for a specific technology or task. Skills are written in Markdown and can contain reference files, code snippets, and other assets. Agents load in skill information only as-needed, reducing the risk of context bloat.

Today, on Day 1 of Google Cloud Next 2026, we’re excited to announce the launch of Google’s official Agent Skills repository:

github.com/google/skills

This repository is starting off with thirteen skills, focused on Google Cloud technologies:

A selection of products: AlloyDB, BigQuery, Cloud Run, Cloud SQL, Firebase, Gemini API, and Google Kubernetes Engine (GKE).
Three Well-Architected Pillar skills: Security, Reliability, and Cost Optimization
“Recipe” skills for Google Cloud Onboarding, Authentication, and Network Observability.

Use npx skills install github.com/google/skills to install these skills to your agents of choice, including Antigravity, Gemini CLI, and third-party agents.

Stay tuned as we launch additional skills in this repo in the coming weeks and months!

Now get building!

What’s new with the Cross-Cloud Network at Next ‘26

Wed, 22 Apr 2026 12:00:00 +0000

While generative AI sparked a revolution, the true paradigm shift is the rapid evolution from standalone AI models to multi-agent autonomous systems. In this new era, the network transcends basic connectivity to become the critical integration layer for your agentic enterprise.

As AI agents and services surge, your core applications remain as vital as ever. To thrive in this rapidly evolving landscape, you need a planet-scale network to connect, protect, govern, deliver, and secure all your users, data, agents, AI services, and core applications across clouds and on-premises.

Google Cloud's Cross-Cloud Network provides this unified foundation, and is now used by 65% of the Fortune 100 and handles up to 27 exabytes of data per month. At Google Cloud Next, we are introducing networking innovations to accelerate your AI infrastructure, strengthen security, and simplify operations.

Optimized networking infrastructure for AI

As we move toward an agentic world, the network must support massive-scale inference paired with reinforcement learning. At Google, we’ve spent years refining this cycle to power our own global AI services. Today, we’re announcing AI infrastructure network innovations that bring this same architecture directly to your workloads, across agents, inference, training, and beyond.

Networking for agents

The Gemini Enterprise Agent Platform is a comprehensive enterprise environment designed to build, scale, govern, and optimize the next generation of autonomous agents. Key innovations being announced in preview include:

Agent Gateway: Air-traffic control for agentic traffic

Agent Gateway understands MCP and A2A agentic protocols and provides an open, extensible, scalable way to enforce centralized governance policies to securely connect agents, models, and tools across runtimes.

Ambient networking: A seismic shift in service-to-service connectivity

Ambient networking, a new integrated data plane for Google Kubernetes Engine (GKE) and Cloud Run, provides service discovery, zero-trust access, and traffic management without the need for complex and resource-heavy sidecar proxies. It reduces operational overhead and enables up to a 10x reduction in GKE resource usage for layer 4 (L4) mesh capabilities

Ambient networking underpins two new capabilities:

Service bindings automatically establish service-to-service connectivity, allowing developers to move faster to build and scale their agentic applications and services.
Network Services Monitoring bridges application and network observability gaps resulting in faster root-cause analysis and simplified troubleshooting.

Rich partner integrations and customizations

With the help of Service Extensions, we are developing solutions for identity, governance, and AI security for agent-to-anywhere traffic. Coming soon in preview to Agent Gateway are:

Identity and governance administration: Offering delegated authorization to Cloud IAM and partner services from Okta, Ping, Saviynt, and Silverfort to enforce real-time, contextual governance policies based on application and business context.
Runtime security: As a universal enforcement point by integrating with Google Cloud’s Model Armor and partner solutions from Broadcom, Check Point, Cisco, CrowdStrike, Exabeam, F5, Netskope, Palo Alto Networks, Thales, and Zscaler. Together, these can help to secure agentic communications against emerging AI attack vectors.

These innovations are built on an open foundation including Envoy and Kubernetes, providing strong, integrated governance in multicloud environments using standard Kubernetes Gateway APIs.

Networking for inference

At Google we run inference at scale with optimized use of distributed GPU and TPU resources, automatic failover between regions for high availability, and optimized global request routing for fast end-user performance. GKE Inference Gateway delivers these capabilities to our cloud customers including the following new innovations:

Multi-region support allows scaling inference services across regions, enabling cross-regional failover, optimized utilization, and reduced global latency (preview).
Predictive latency boost improves utilization with intelligent request routing based on predefined performance targets (preview).
Disaggregated serving leverages llm-d’s SGLang support, offering the flexibility to choose between vLLM and SGLang for model serving (GA).

Gemini Enterprise Agent Platform reduced Time to First Token (TTFT) latency by over 35% for Qwen3-Coder by using GKE Inference Gateway.

“Before GKE Inference Gateway, managing our inference stack with Ray Serve created a complex, dual-orchestration layer that was a significant burden on our small operations team. Moving to the Inference Gateway and native Kubernetes deployments was the 'North Star' architecture we needed to simplify management and achieve robust production stability with a GKE-native batteries-included solution.” - Mikhail Lubinets, Lead HPC Engineer, Technology Innovation Institute

Networking for training

At Google, we build and run the largest AI models in the world — and we built a network to support that. Some of the new enhancements are:

Massive scale with Virgo Network

This new non-blocking data center fabric removes latency barriers:

Virgo can link up-to 134,000 chips with 47 Petabits/sec of non-blocking bi-sectional bandwidth to deliver 1.7K Exaflops of compute.
With enhancements in Pathways and JAX, you can further connect these Virgo fabrics to scale to over 1 million TPU chips in a single training cluster.
We are also making Virgo Network available on NVIDIA Vera Rubin NVL72, supporting up to 960,000 GPUs.

For more on Virgo Network, check out this blog.

Accelerator network profiles

It’s easier than ever to handle the complex networking prerequisites for accelerator-equipped GKE node pools with DRANET, which improves bandwidth for distributed AI/ML workloads by up to 60% (GA).

AI-native Cloud Interconnect

SLA-backed, and optimized for efficiency, Cloud Interconnect supports petabit-scale data transfers and is available with a fixed price option. Cloud Interconnect now supports:

400 Gbps circuits with up to 3.2 Tbps in a single connection (GA)
Partner Cross-Cloud Interconnect for AWS (GA), CoreWeave (in preview soon), and Lumen (in preview soon)

Cross-Cloud Network for AI and core applications

The Cross-Cloud Network helps ensure you can securely connect users, data, locations, applications, services, and infrastructure anywhere in the world, at planetary scale. We designed our global multi-shard network to scale horizontally to meet the demands of the AI era and enable us to accommodate our 10x WAN traffic growth from 2020 to 2025.

These are some of the improvements we’re making to the Cross-Cloud Network:

Ultra Low Latency Solution for financial exchanges

In partnership with CME Group, we are bringing the world's leading derivatives marketplace to Google Cloud. To support CME Group’s performance requirements, we developed an ultra low latency (ULL) networking and compute solution. This fully managed cloud environment will allow CME Group and its clients to migrate its core trading systems to Google Cloud.

Now in preview, the solution is designed to meet the unique and exacting requirements of running financial exchanges in the cloud. It includes several new technologies:

Deterministic high-performance compute powered by ULL networking, with bare metal and VM form factors, delivers a comprehensive portfolio for your trading compute needs.
Scalable multicast data distribution with hardware-based ultra-low latency enables reliable one-to-many market data sharing.
Nanosecond-level clock sync enabled by Firefly, a novel clock synchronization system. Firefly achieves sub-10ns NIC-to-NIC synchronization to support high-frequency trading.
Advanced network observability with 64-bit nanosecond timestamps, support for multiple traffic-mirroring destinations and multicast traffic, and support for auditing and regulatory requirements.
Low-latency inference allowing exchange participants to connect their AI-driven services to the exchange’s infrastructure.

“The Google Cloud Ultra Low Latency Solution provides the level of performance necessary for CME Group futures and options markets to run in the cloud, expanding access to clients worldwide.” - Sunil Cutinho, CIO, CME Group

Cross-cloud observability for networks, applications, and agents

Whether you’re running core applications or new AI agents, you need visibility into your network infrastructure. Cloud Network Insights, now in preview, offers network performance monitoring (NPM) and digital experience monitoring (DEM) to dramatically reduce the mean time to detect and mitigate network-related agent, application, and API issues.

Cloud Network Insights is enabled by technologies from Broadcom’s AppNeta and powered by AI-enabling natural language queries through Gemini Cloud Assist.

"In an environment as complex and high-scale as Sabre’s, total visibility isn't just a luxury — it's a requirement for operational resilience. Cloud Network Insights will enable us to further shift our posture from reactive troubleshooting to proactive optimization. By providing granular, real-time telemetry across our global cloud footprint, it helps eliminate the traditional 'black box' of the network, allowing our teams to resolve bottlenecks before they impact the traveler experience." - Alfredo Rodriguez, VP Cloud Platform Infrastructure, Sabre Corporation

“Cloud Network Insights closes the 'visibility gap' between the private corporate network and the public cloud, empowering our joint customers to pinpoint performance bottlenecks in seconds rather than hours.” - Alan Davidson, CIO, Broadcom

Cross-Cloud Network for distributed applications

Multicloud and hybrid networks require secure, reliable, and high-performance connectivity. New enhancements for our foundational networking services and tools include:

Private Service Connect

Private Service Connect traffic volume grew 4x in 2025 and it now supports 40+ Google and third-party published services, enabling secure private global access to your managed services.
Private Service Connect endpoint-based security allows for granular authorization policies for producer-to-consumer service communications (preview).
Gemini Cloud Assist for Private Service Connect provides for automated troubleshooting (preview).

Cloud-native IP address management (IPAM)

Cloud Number Registry is an IPAM solution powered by agentic technologies. Network admins can easily find free IP ranges, track utilization, and allocate resources (preview). It also integrates with Infoblox Universal DDI for Cross-Cloud Network IPAM discovery and enforcement.
Hybrid Subnets allow you to migrate legacy workloads from on-premises to a VPC without needing to change hard-coded IP addresses (GA).
Cloud NAT allows you to connect your IPv6-only workloads to private IPv4 destinations using the combined power of DNS64 and private NAT64 (in preview soon).

Network Connectivity Center (NCC)

Partner Cross-Cloud Interconnect for AWS is available as a connectivity type in NCC (preview).
Support for static routes using an internal load balancer as the next hop allows the integration of Secure Web Proxy and third-party network security virtual appliances (GA).
Support for privately used public IP (PUPI) allows the exchange of PUPI IPv4 addresses with VPC spokes and producer VPC spokes (GA).

Granular networking charge visibility

Cost Explorer and the new App Optimize API now provide attribution of associated Data Transfer costs to the originating resources for Google Cloud products (in preview soon).

Cross-Cloud Network for internet-facing services

As part of Cross-Cloud Network, the Global Front End simplifies how you deliver, scale, and protect web, API, and AI workloads. New capabilities include:

Global Front End Enterprise delivers simplified consumption by combining capabilities from global Cloud Load Balancing, Google Cloud Armor, Cloud CDN, and Service Extensions with up to 15% lower TCO (in preview soon).
Post quantum cryptography (PQC) helps secure your workloads with industry-standard algorithms that provide a layered defense against both classical and quantum adversaries.
Google tag gateway, enabling advertisers to serve tags from their own domain, which can significantly improve the accuracy and resilience of measurement signals (GA soon).

In addition, Cloud CDN, an important part of the Global Front End, now offers:

Built-in image optimization to help you deliver content that best fits your end users’ screens and saves on bandwidth costs (in preview soon).
GKE Gateway support so you can enable and manage caching services using GKE APIs (GA).

Cross-Cloud Network’s Cloud WAN for global enterprises

Cloud WAN is a fully managed, reliable global backbone to connect your enterprise. New capabilities include:

Expanded geographic reach: Our network spans more than 10 million kilometers of terrestrial and subsea fiber, and Network Connectivity Center’s site-to-site data transfer is now available in over 25 countries.
NCC Gateway enables third-party secure service edge (SSE) integrations from Palo Alto Networks (GA soon) and Symantec (preview).
The Verified Peering Provider program, which offers highly reliable internet connectivity to Google, now has dramatically expanded availability through 175+ providers worldwide.
Last mile connectivity: Provision site-to-cloud private connectivity in minutes with preferred partners from the Google Cloud console (in preview soon).

“Cloud WAN enables Dun & Bradstreet to evolve our global network via composable, cloud-native constructs. Leveraging NCC, we’ve built a resilient, high-performance platform that simplifies operations and optimizes costs. This foundation supports continued modernization and AI-driven workloads. We expect to extend this architecture as new patterns emerge, maintaining our blueprints-first approach.” - Josh Barry, VP, Network Engineering, Dun & Bradstreet

AI-powered security against evolving threats

The threat landscape is evolving faster than ever, with AI-driven attacks. Staying ahead requires the latest defenses. Cross-Cloud Network relies on Cloud NGFW and Cloud Armor for advanced security capabilities. Here’s the latest on those offerings.

Cloud NGFW

Advanced malware sandbox uses AI models trained on data from 70k+ customers to stop 99% of known and unknown malware, including evasive zero-days. Advanced malware sandbox is powered by Palo Alto Networks Advanced Wildfire (in preview soon).
Internal Application and proxy Network Load Balancer support helps to enforce consistent, service-centric security for abstracted services like GKE, Cloud Run, and Private Service Connect traffic (preview).
Project-level policies allow for creating and managing Cloud NGFW endpoints, security profiles, and security profile groups at the project level (in preview soon).

Cloud Armor

Managed rules, built-in rulesets across 15 threat categories, deliver automated threat protection against a broad set of attacks and zero-day CVEs. This is powered by Thales Imperva based on visibility to 1.5 trillion web requests each month (in preview soon).
Google Cloud Fraud Defense integration helps to discern the legitimacy and authorization of bots, humans, and agents. Fraud Defense is the evolution of reCAPTCHA, which protects over 14 million domains from fraud and abuse.
Adaptive protection for Network Load Balancers & VMs brings advanced machine learning to L3/L4 traffic, to detect and mitigate volumetric DDoS attacks (in preview soon).
A simplified user experience with a visual rule builder makes custom rule creation easier (in preview soon).

AI-powered network operations

Finally, new AI-powered technologies in Gemini Cloud Assist can help automate manual tasks, ease troubleshooting, predict reliability issues, improve security, and help optimize your network to reduce toil and improve reliability with new specialist agents. These include:

A network security agent that streamlines network security operations by assisting with policy generation, recommendations, and impact analysis (in preview soon).
A network agent that optimizes workload placement for performance and reliability, and also provides advanced cost estimation for observability services (in preview soon).

Additionally, to enable customers and partners to build their own agents, we are releasing Network observability MCP tools and agent skills. This will allow their agents to leverage connectivity tests, and allows for natural language querying of VPC Flow Logs (both in preview).

The network that scales with you

We built our Cross-Cloud Network on the same global infrastructure that powers Google’s largest AI and internet services. This provides you with a blazing-fast, planet-scale foundation that is both secure by design and open by principle, allowing you to integrate your trusted partners across any environment.

As we move into the agentic era, our flexible, future-proof solutions ensure you can quickly adopt the latest AI technologies while maintaining the reliability of your core applications.

Whatever comes next, we’ve built the network to help you lead it. Attend our networking sessions at Next ’26 to learn more, or learn more about the Cross-Cloud Network!

Introducing Gemini Enterprise Agent Platform, powering the next wave of agents

Wed, 22 Apr 2026 12:00:00 +0000

In the early days of generative AI, building safe and reliable business tools took massive engineering effort and a high tolerance for trial and error. We helped solve that with Vertex AI, our trusted AI development platform. But today, we’re managing a different level of complexity, with agents interacting across multiple systems — and often without security and governance guardrails.

To move toward a truly autonomous enterprise, one where agents can act with the same independence and reliability as a member of your team, you need a foundation that can sustain that level of trust.

What’s new: Today, we’re launching Gemini Enterprise Agent Platform — our new, comprehensive platform to build, scale, govern, and optimize agents. It’s the evolution of Vertex AI, bringing the model selection, model building, and agent building capabilities that customers love, together with new features for agent integration, DevOps, orchestration, and security.

Agent Platform provides a single destination for your technical teams to build agents that can transform your products, services, and operations. These agents can be seamlessly delivered to your employees through the Gemini Enterprise app, all while remaining tightly integrated with your IT operations to help ensure control, governance, and security as you scale.

The platform also provides first-class access to more than 200 of the world’s leading models through Model Garden. This includes our latest first-party breakthroughs like Gemini 3.1 Pro, Gemini 3.1 Flash Image, and Lyria 3, alongside our open models like Gemma 4. And, of course, customers have full flexibility to use the best model for the job with support for third-party models like Anthropic’s Claude Opus, Sonnet and Haiku.

Moving forward, all Vertex AI services and roadmap evolutions will be delivered exclusively through the Agent Platform, rather than as a standalone service, to power the next generation of agent development.

Why Agent Platform matters for your business: Agent Platform helps you move from managing individual AI tasks to delegating business outcomes with total confidence. You can:

Build: Choose the right environment for the job — from the low-code, visual interface of the new Agent Studio, to the code-first logic of the upgraded Agent Development Kit (ADK). We’ve simplified the entire lifecycle with AI-native coding capabilities to help you ship production-grade agents faster.
Scale: Clear the path to production with the re-engineered Agent Runtime. This supports long-running agents that maintain state for days at a time and are backed by Memory Bank for persistent, long-term context.
Govern: Establish centralized control with Agent Identity, Agent Registry, and Agent Gateway. These capabilities help ensure every agent — whether built on Agent Platform or sourced from our partner ecosystem — has a trackable identity and operates within enterprise-grade guardrails.
Optimize: Guarantee quality with Agent Simulation, Agent Evaluation, and Agent Observability. These tools provide full execution traces and a real-time lens into agent reasoning to help ensure your agents always hit their goals.

Get started with Agent Platform: Visit Agent Platform in the Google Cloud console to explore new features and start building today.

Keep reading for a deeper look at our latest releases and how Agent Platform helps you deliver the production-ready agents you can trust at every stage of the journey.

How customers are achieving more with Gemini Enterprise Agent Platform

"Burns & McDonnell uses Agent Platform to transform how organizational knowledge is applied across the enterprise. Using ADK, we are building an AI agent that turns decades of project data into real-time, actionable intelligence. Agent Platform enables this innovation to scale responsibly by combining deterministic business rules with probabilistic reasoning — making AI a trusted operational capability, not just a productivity tool. With Agent Platform, we aren’t just managing knowledge; we are activating experience to drive faster, more confident decisions." – Matt Olson, Chief Innovation Officer, Burns & McDonnell

“Color Health uses Agent Platform to power our Virtual Cancer Clinic, delivering end-to-end care. By building our Color Assistant with the Agent Development Kit (ADK) and scaling it via Agent Runtime, we are helping more women get screened for breast cancer. The Color Assistant engages users to check screening eligibility, connects them to clinicians, and helps schedule appointments. The power of the agent lies in the scale it enables — helping us reach more people and respond to individual risk and eligibility in real time.” – Jayodita Sanghvi, PhD., Head of AI Platform, Color

“By rebuilding Comcast’s Xfinity Assistant with Agent Development Kit (ADK), we’ve moved beyond simple scripted automation to conversational generative intelligence that delivers personalized troubleshooting and self-service support to our customers. Agent Runtime has been a massive accelerator, allowing us to deploy a sophisticated multi-agent architecture that increases digital containment while ensuring secure, grounded interactions via Gemini. We aren't just reducing repeat interactions by solving customers’ issues the first time; we're redefining the customer experience at scale.” – Rick Rioboli, Chief Technical Officer, Connectivity & Platforms, Comcast

“Geotab uses Agent Platform to rapidly accelerate our AI Agent Center of Excellence. Google's Agent Development Kit (ADK) provides the flexibility to orchestrate various frameworks under a single, governable path to production, while offering an exceptional developer experience that dramatically speeds up our build-test-deploy cycle. For Geotab, ADK is the foundation that allows us to rapidly and safely scale our agentic AI solutions across the enterprise” – Mike Branch, Vice President, Data & Analytics, GeoTab

"Gurunavi uses Agent Platform to power 'UMAME!', an AI restaurant discovery app that leverages Memory Bank to achieve a deep understanding of user context. Unlike conventional prompt-based systems, our agent remembers a user's past actions and preferences to proactively present the best options. This eliminates the need for manual searches and creates a seamless experience that will improve user satisfaction by 30% or more. We view this memory function as a non-negotiable feature for the future of new culinary experiences.” – Toshiaki Iwamoto, CTO, Gurunavi

"At L'Oréal, Beauty Tech is not just a support function — it is a powerful catalyst to create the beauty that moves the world. To live up to that ambition, we decided to build our own proprietary Beauty Tech Agentic Platform, powered by Google Cloud. Leveraging Agent Development Kit (ADK), we are leading a fundamental shift: moving from deterministic workflow automation to autonomous, outcome-oriented agent orchestration. Our agents are not locked in a vacuum — through Model Context Protocol (MCP), they are securely connected to our single sources of truth, including our Beauty Tech Data Platform and core operational applications. Google Cloud gives us the resilience, the multi-LLM flexibility, and the enterprise-grade trust framework we need to scale this platform globally, while keeping human oversight at the center." – Etienne BERTIN, Group CIO, L'Oréal

“Payhawk uses Agent Platform to transform our AI agents from simple task executors into genuine financial assistants. By leveraging Memory Bank, we have moved from stateless interactions to long-term context retention. Our agents now act like dedicated team members, autonomously recalling user-specific constraints and history. For example, our Financial Controller Agent now remembers a user’s habits to auto-submit expenses, reducing submission time by over 50%. This shift allows our agents to anticipate needs based on past behavior rather than just reacting to prompts.” – Diyan Bogdanov, Principal Applied AI Engineer, Payhawk

"PayPal uses Agent Platform to rapidly build and deploy agents in production. Specifically, we use Agent Development Kit (ADK) and visual tools to inspect agent interactions, and manage multi-agent workflows. This provides the step-by-step visibility we need to visualize the flow of intent and payment mandates. Finally, Agent Payment Protocol (AP2) on Agent Platform provides the critical foundation for trusted agent payments. helping our ecosystem accelerate the shipping of secure agent-based commerce experiences." – Nitin Sharma, Principal Engineer, AI, PayPal

Build AI agents

Build agents quickly and easily by empowering your developers, business users and everyone in between to build and deploy agents at scale.

Build smarter agents, faster

A major upgrade to ADK: More than six trillion tokens are processed monthly on Gemini models through ADK. Unlock more powerful reasoning by organizing agents into a network of sub-agents. This new, graph-based framework allows you to define clear, reliable logic for how agents work together to solve complex problems.
Workspaces are secure-by-design: Give agents a hardened, sandboxed environment to run bash commands and manage files safely, isolated from your core systems.
Multimodal streaming: Bring human-like stability to real-time interactions with multimodal support for live audio and video cues.

Connect your agents to the enterprise

Securely access any system: Use plug-and-play architecture with Native Ecosystem Integrations to connect agents to your internal data and tools without custom coding.
Automate background operations: Activate your data in BigQuery and Pub/Sub with Batch & Event-driven agents. This way, you can run massive, asynchronous tasks like content evaluation or data analysis in the background.

Go from idea to production in hours

Enable AI-driven development: A programmatic interface for coding agents to access Google’s complete suite of agentic capabilities, allowing them to build, evaluate, and deploy production-ready agents on your behalf.
Bringing agent building directly to Agent Studio: Now, you can move seamlessly from building simple prompts to deploying complex agents in Agent Studio. Once you're ready for deep customization, export your logic directly into ADK to continue development in a full-code environment.
Get a head start with pre-built agents: Access a curated set of agent templates in Agent Garden — including code modernization, financial analysis, economic research, invoice processing, and more — that serve as immediate building blocks for your multi-agent systems.

Scale AI agents

To move from a proof-of-concept to a live environment, you need a platform that can handle the performance, state, and security requirements of real-world work.

Powering high-performance agent execution

The latest Agent Runtime: Our revamped Agent Runtime delivers sub-second cold starts and allows you to provision new agents in seconds.
Support for multi-day workflows: You can now deploy long-running agents that run autonomously for days at a time. This allows your agents to manage complex, multi-step workflows and deep reasoning tasks that require extended persistence, like managing a sales prospecting sequence.
Autonomous action with security-by-design environments: Agent Sandbox provides a hardened environment to safely execute model-generated code and perform computer use tasks like browser-based automation without risk to your host systems.
Agent-to-agent orchestration: Enables agents to seamlessly delegate tasks to one another, including support for complex, generative, and deterministic orchestration patterns. This ensures that for critical flows such as compliance, your agents follow well-specified paths every time.

Move beyond temporary session data to high-accuracy context

Personalize interactions: Agent Memory Bank dynamically generates and curates long-term memories from conversations. Using new Memory Profiles, agents can recall high-accuracy details with low latency, ensuring context is never lost.
Link AI interactions to your existing records: Store and manage history using Agent Sessions. With Custom Session IDs, you can use your own unique identifiers to track sessions and map them directly to your internal database and CRM records.
Enable real-time, human-like interactions: Using the WebSocket protocol for Bidirectional Streaming, you can help ensure your agents are highly responsive during live customer or employee interactions, processing audio and video without lag.

Govern AI agents

Govern with a secure-by-design architecture that applies enterprise rigor to every agent in your fleet – from the ones you build on Agent Platform to the ones you source from our partner ecosystem.

Manage all of your agents through a single source of truth for identity and access.

Assign every agent a verifiable identity: Agent Identity improves the security posture of your agents by ensuring every agent receives a unique cryptographic ID. This creates a clear, auditable trail for every action an agent takes, mapped back to defined authorization policies.
Maintain a central library of approved tools: Our new Agent Registry provides a single source of truth for your enterprise. It indexes every internal agent, tool, and skill, simplifying discovery and ensuring only governed, approved assets are available to your users.
Manage your agent fleet from one control point: Agent Gateway acts as the air traffic control for your agent ecosystem. It provides secure, unified connectivity between agents and tools across any environment, while enforcing consistent security policies and Model Armor protections to safeguard against prompt injection and data leakage.

Use AI-powered insights to detect hidden risks and suspicious behavior before they impact your business.

Detect suspicious behavior in real-time: Agent Anomaly Detection uses statistical models and an LLM-as-a-judge framework to flag unusual reasoning. This works alongside Agent Threat Detection to provide visibility into malicious activity, such as reverse shells or connections to known bad IP addresses.
Uncover vulnerabilities automatically: A new Agent Security dashboard, powered by Security Command Center, unifies threat detection and risk analysis. It allows your teams to map relationships between agents and models, automate asset discovery, and scan for vulnerabilities in the underlying operating system and language packages.

Optimize AI agents

Agent Platform gives you the visibility needed to understand how your AI is performing, making it easy to refine their logic and get smarter over time.

Test your agents before they ship

Simulate realistic conversations: Use Agent Simulation to test agents against human-like synthetic user interactions and virtualized tools in a controlled environment. Agents are automatically scored based on task success and safety across multi-step conversations.

Monitor and improve in production

Track live performance: Use Agent Evaluation to continuously score agents against live traffic using multi-turn autoraters that can evaluate the logic of an entire conversation, not just a single response. With turnkey dashboards and Agent Observability, you can visually trace complex reasoning to debug issues as they happen.
Automate agent refinement: Instead of manually digging through logs, Agent Optimizer automatically clusters real-world failures and suggests refined system instructions to improve accuracy.

Detailed technical guides and a full list of updates are available in our updated documentation and release notes. Agent Platform is the new standard for enterprise agent development, built to help you move from experimentation to production-scale impact, starting today.

Next ‘26: Redefining security for the AI era with Google Cloud and Wiz

Wed, 22 Apr 2026 12:00:00 +0000

aside_block: <ListValue: [StructValue([('title', 'Our news today from Next ‘26'), ('body', <wagtail.rich_text.RichText object at 0x7fb5c59b83a0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

The AI era demands a new security era. Organizations are facing the dual challenge of harnessing the potential of AI while defending against its malicious use, and Google Cloud can help you adapt and thrive.

The latest research from Google Cloud shows that adversaries are using AI to accelerate the speed, scale, and sophistication of attacks. Meanwhile, M-Trends 2026 also showed that increased threat actor coordination has driven down the time to hand-off from an initial access to a secondary threat actor from eight hours to 22 seconds in the last three years.

Today at Google Cloud Next, we are showcasing how Google Cloud can help you defend against increasingly sophisticated threats at machine speed, protect AI and multicloud environments, and secure cloud workloads at scale.

Delivering agentic defense

Our full-stack AI approach, from the chips to the models, gives you a competitive advantage with better integration and velocity to help protect customers. Not only can Google action insights from the world’s largest threat observatory and Mandiant frontline experts, but we also bring cutting-edge insights and breakthroughs from Google DeepMind, to help make your platforms more secure.

Today we are introducing three new agents in Google Security Operations to help you defend at the speed of AI.

Threat Hunting agent, now in preview, can help teams proactively hunt for novel attack patterns and stealthy adversary behaviors that bypass traditional defenses.
Detection Engineering agent, now in preview, can identify coverage gaps and create new detections for threat scenarios, reducing toil and transforming detection creation from a manual craft into an automated science.
Third-Party Context agent, coming soon to preview, can enrich your workflows with contextual data from third-party content.

Initiating a threat hunt with the Threat Hunting agent

Our Triage and Investigation agent processed over 5 million alerts in the last year, reducing a typical 30-minute manual analysis to 60 seconds with Gemini.

“Operational resilience and cybersecurity are the bedrock of customer trust at BBVA. By integrating advanced artificial intelligence, such as the Triage and Investigation agent, we are able to scale in new ways," said Diego Martinez Blanco, head of Security Technology, BBVA.

“It handles the initial heavy lifting and filters out false positives so we can prioritize issues that require human attention. The agent's transparent explanations allow our team to understand recommendations and ultimately dedicate our resources to more complex investigations,” he said.

You can build your own security agents with remote Google Cloud model context protocol (MCP) server support for Google Security Operations, now generally available. To make it even easier, you can also access the MCP server client directly from the Google Security Operations chat interface, available in preview.

Organizations leveraging an intelligence-led, AI-augmented approach to modern security operations with Google Cloud's agentic defense can realize a strong ROI. Christopher Kissel
Research Vice President, IDC

Findings report created by the Threat Hunting agent

Security teams can also automate response actions with agentic automation in Google Security Operations. To further move teams from manual triage to agentic defense, we introduced dark web intelligence in Google Threat Intelligence, now in preview. Internal tests show it can analyze millions of daily external events with 98% accuracy to elevate threats that truly matter.

"IDC found that organizations experienced measurable operational gains, including substantial reductions in mean time to detect and mean time to respond, fewer false positives, and higher analyst productivity with AI-powered context and automation. These operational improvements translate into significant business outcomes, such as shorter disruption periods, lower incident-related costs, and improved executive confidence in security posture and decision-making," said Christopher Kissel, research vice president, IDC. "Organizations leveraging an intelligence-led, AI-augmented approach to modern security operations with Google Cloud's agentic defense can realize a strong ROI."

New partner-supported workflows for Google Security Operations

Today, we are also announcing a robust cohort of new partner integrations for Google Security Operations. Designed to deliver high-fidelity security workflows right out of the box, our latest participating Google Cloud Security integration ecosystem partners include Darktrace, Gigamon, and SAP.

Protecting AI and cloud applications across any infrastructure

AI and cloud applications are built across multiple platforms and models. To protect them end-to-end, we want to make it easier and faster to mitigate risk, regardless of where and how you build. This support includes major cloud environments like Amazon Web Services, Google Cloud, Microsoft Azure, and Oracle Cloud; software-as-a-service (SaaS) environments like OpenAI; and even custom hosted environments.

Wiz, now a part of Google Cloud, expands and deepens our ability to protect the apps you build and run. Wiz empowers you to quickly and securely adopt AI, while also helping protect the AI development lifecycle.

Wiz announced its AI-Application Protection Platform (AI-APP) at the RSA Conference, providing deep visibility, risk posture, and runtime analysis for your AI applications. Wiz also announced Wiz Security Agents and Wiz Workflows, helping you identify and respond to risks and threats at machine speed.

Today, we’re taking our commitment to secure customers in any cloud, platform, and AI environment further. Wiz now supports Databricks as well as new agent studios like AWS Agentcore, Gemini Enterprise Agent Platform, Microsoft Azure Copilot Studio, and Salesforce Agentforce, so customers gain visibility however their teams choose to build.

In addition, Wiz continues to support security ecosystems with integrations to the outer layer of the cloud, including Google Cloud Apigee, Cloudflare AI Security for Apps, and the Vercel platform, further extending the power of the Wiz Security Graph. We’ve also updated how we integrate security detections from Wiz Defend with Google Security Operations and Mandiant Threat Defense to help analysts more easily configure automatic threat information forwarding.

Wiz is also announcing new capabilities designed to secure the AI-native development lifecycle, helping teams to innovate faster and more securely:

Secure vibe-coded applications: Wiz is announcing a new integration, generally available in May, that runs Wiz security scanning directly inside the Lovable platform so vulnerabilities, secrets, and misconfigurations caught by Wiz surface in Lovable's built-in security view, right where teams are already building.
Secure AI-generated code: Wiz removes risks from AI-generated code the moment it is created. Inline AI security hooks integrate directly into IDEs and agent workflows to evaluate prompts and scan AI-generated output instantly, injecting security guardrails before the code is ever committed.
Agent-based remediation: Wiz Skills equip coding agents and AI-native IDEs with full code-to-cloud context and validated attack surface findings from the Wiz Security Graph. These capabilities enable teams to trigger automated, agent-driven remediation workflows either locally from the developer's individual IDE or globally at the repository and pull request level within your version control system.
Eliminate shadow AI: Wiz’s dynamic AI-Bill of Materials (AI-BOM) automatically inventories all AI frameworks, models, and IDE extensions across your environment. This provides complete visibility into what is writing code across your stack, allowing you to track sanctioned corporate tools like Gemini Code Assist and GitHub Copilot while simultaneously uncovering unapproved shadow AI plugins.

You can learn more about the Wiz announcements here.

Securing your agents and the agentic web

In addition to securing your cloud and AI workloads, Google Cloud’s secure-by-design foundation can help you innovate at the speed of AI — from agents to fraud defense to the web.

Securing and governing agents with the Gemini Enterprise Agent Platform
To build, orchestrate, govern, and optimize agents, today we are announcing Gemini Enterprise Agent Platform including:

Agent Identity to enable access management and AI governance at scale. Our new capability provides agents unique identities to operate autonomously with specific authentication flows, and with scoped human delegation.
Agent Gateway, which enables policy enforcement for all agent-to-agent and agent-to-tool connections. It governs your enterprise agent traffic and understands agent protocols like MCP and Agent2Agent (A2A) to inspect and secure every agent interaction.
Model Armor, our runtime protection for model and agent interactions, now integrates with Agent Gateway, Agent Runtime, and Langchain available in preview, and Firebase, generally available, to help developers add inline enforcement and sanitization of agent traffic and interactions without the need to change code. These integrations expand Model Armor's protection against runtime risks such as prompt injections, tool poisoning, and sensitive data leakage across Google Cloud services and our AI portfolio.

Securing the agentic web with Google Cloud Fraud Defense and Chrome Enterprise
Today, we are evolving reCAPTCHA with the launch of Google Cloud Fraud Defense, generally available. This comprehensive platform is designed to discern the legitimacy and authorization of bots, humans, and agents. Using the same scale and signals that protect Google’s own ecosystem, Fraud Defense will soon offer in preview agent-specific capabilities for human users and AI agents that can help secure the digital commerce journey, from account creation and login to payment and checkout.

Our commitment to securing AI extends to the browser, a vital endpoint for interacting with AI. Chrome Enterprise provides comprehensive data protection for the AI era with the visibility and controls needed to embrace AI safely without compromising corporate data:

AI-aware extension threat detections, now in preview, can surface advanced extension telemetry that helps security teams detect and respond to anomalous AI agent activity.
New shadow AI reporting, generally available soon, can help you gain visibility into the shadow AI landscape by flagging employee use of unsanctioned web-based AI and SaaS applications.

What’s new in Trusted Cloud

We continue to offer new security controls and enhance capabilities across identity, data, and networking on our cloud platform to help you secure your environments. Today we’re announcing the following updates:

Simplifying permissions with modern IAM
To help achieve least privilege quickly and simply, we’ve streamlined our predefined roles catalog with easy-to-use administrator, editor, and viewer roles, such as the IAM role picker and the ability to re-authenticate sensitive actions.

Data security
We are announcing several new capabilities for our cloud platform data security portfolio to help protect your most sensitive data and accelerate AI transformation.

Confidential Computing: In partnership with NVIDIA, today we’re announcing Confidential Computing support for G4 VMs, featuring NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs on Google Compute Engine (GCE) Confidential G4 VMs, available in preview globally, to help strengthen confidentiality and integrity for a wide spectrum of sensitive AI workloads. In partnership with Intel, we’re also introducing the preview of C4 Confidential VMs, bringing Intel TDX to 6th Gen Xeon processors to help protect diverse AI and analytics workloads while providing industry-leading compute density and performance.
Cloud Key Management Services (KMS): We are announcing the new Confidential External Key Manager (cEKM) in preview, giving you the flexibility to host and protect external keys in any region and maintain verifiable control within a confidential environment.
Post-quantum cryptography (PQC): We are introducing KMS Quantum Safe Key Imports, available in preview, to help you bring your own keys with quantum-safe algorithms.
Secret Manager: To help prevent password leaks and mitigate prompt injection risks, we are announcing the general availability of the native integration of our Secret Manager with Agent Development Kit.

Network security
Google Cloud’s Cross-Cloud Network security products offer several new capabilities:

Cloud NGFW: We’re announcing the Cloud NGFW advanced malware sandbox, in preview later this year, to help defend against highly evasive zero-day threats. This capability is powered by Palo Alto Networks Advanced Wildfire, trained on data from more than 70,000 Palo Alto Networks customers to stop 99% of known and unknown malware.
Cloud Armor: We have released new Cloud Armor managed rules, powered by Thales Imperva and available in preview, to detect Layer 7 application attacks and zero-day CVEs (like React2Shell).

Advancing Google Cloud security with SCC
As our Google Cloud-native security solution, Security Command Center (SCC) establishes a cloud security baseline to protect both your traditional and AI applications on Google Cloud:

AI agents, models, and MCP servers are secured by providing continuous discovery and comprehensive risk analysis to identify threats, vulnerabilities, and misconfigurations.
SCC will add deep runtime visibility to uncover shadow AI for your Google Cloud workloads. Coming soon in preview, SCC will automatically discover unmanaged agentic workloads — including agents, MCP servers hosted on Cloud Run, GKE, and inference endpoints running on GKE, and surface those as posture findings in SCC.
Our enhanced Security Command Center Standard tier provides data security posture management, compliance, vulnerability management, and risk analysis to help any Google Cloud customer establish strong security, compliance and risk coverage from the start at no additional costs.

Take the next step

When you make Google part of your security team, you gain the power of an intelligence-driven, AI-native defense; the freedom of an open cloud that’s secure-by-design; and the industry's most-battle tested experts as an extension of your organization.

For more on these new innovations and how you can secure what’s next, tune in to watch our security spotlight. And be sure to check out the many great security breakout sessions — live and on-demand — to learn more about all of our Next ‘26 announcements.