Cloud Blog

Supercharging pgvector: 4x faster HNSW vector search with AlloyDB

Tue, 21 Jul 2026 16:00:00 +0000

AlloyDB is a fully managed, PostgreSQL-compatible database service built for your most demanding enterprise workloads. It combines the best of open source PostgreSQL with Google’s advanced technology, offering massive scalability, high availability, and native AI capabilities. It serves as a performant relational store, a unified backend for vector and full text search, and an analytics engine that is up to 100x faster than standard PostgreSQL.

Vector search is the foundation of modern AI and Retrieval Augmented Generation (RAG) applications. For developers using AlloyDB and other PostgreSQL databases, pgvector is a widely adopted extension for storing, indexing, and querying vector embeddings, and HNSW (Hierarchical Navigable Small World) is a highly efficient graph-based algorithm designed for approximate nearest neighbor search across multi-layered structures. With columnar engine accelerated HNSW in AlloyDB (now in preview), you can achieve up to 4x higher queries per second (QPS) for vector search compared to standard PostgreSQL HNSW.

Enterprise AI applications face a constant trade-off between speed and accuracy. When searching through millions or billions of vectors, maximizing Queries per Second (QPS) without sacrificing search quality (recall) is critical for scaling production workloads. The PostgreSQL pgvector extension offers HNSW as one of the indexes that can speed up Approximate Nearest Neighbor (ANN) searches. Let’s dive deep into how AlloyDB solves the speed vs. accuracy trade-off.

Note: While this post focuses on HNSW performance, it’s worth noting that HNSW is just one part of AlloyDB’s advanced vector toolkit. AlloyDB also features ScaNN—a cutting-edge index backed by over 14 years of Google Research—giving you the flexibility to choose the perfect index for your workload. Additionally, for use cases demanding absolute precision, standard k-nearest neighbor (KNN) search is always available for 100% recall. Check out our Choose a Vector Index Guide to see how they stack up.

aside_block: <ListValue: [StructValue([('title', 'Get started with a 30-day AlloyDB free trial instance'), ('body', <wagtail.rich_text.RichText object at 0x7f0cdf1d5070>), ('btn_text', 'Start building for free'), ('href', 'http://goo.gle/try_alloydb'), ('image', None)])]>

First, what is the AlloyDB columnar engine?

The AlloyDB columnar engine is a built-in, in-memory cache that automatically stores frequently queried data in a specialized, scan-optimized columnar format. It allows AlloyDB to handle heavy analytical queries up to 100x faster than standard PostgreSQL. Additionally, it accelerates ANN searches by storing the index in memory, using a vectorized memory layout for fast traversals, and bypassing standard PostgreSQL buffer manager overhead.

Performance visualization

To understand the real-world performance characteristics of columnar engine Accelerated HNSW, we plotted standard QPS vs Recall curves for the GloVe 100 Angular dataset by searching more than 1M records with a limit of 100.

Running this benchmark script yields the following visualization:

Note: These measurements were taken on an AlloyDB C4A 16vCPU machine. Due to the inherent randomness in HNSW graph building, results may slightly vary across runs.

The data reveals two transformative benefits:

Massive performance throughput gains: For any given target recall (e.g. 0.95), QPS is increased by approximately 4.2x to 4.9x. This allows you to handle significantly more concurrent vector searches on the same hardware.
Significant recall (accuracy) improvement: Conversely, at a fixed QPS level, columnar engine accelerated HNSW provides a substantial boost in recall. For example, we saw that at ~350 QPS (in the above chart), enabling the columnar engine improves recall from roughly 0.78 to over 0.94 – a 0.163 recall gain. This means your AI applications get much more accurate results without any latency impact.

It is important to note that the baseline (blue line) already represents the index being fully cached in the PostgreSQL shared buffer cache. The performance gains shown here are not the result of moving data from disk to RAM, but rather the result of a more efficient memory architecture.

How it works: Columnar engine Accelerated HNSW

In standard PostgreSQL architectures, index operations utilize the shared buffer cache. Even when data is fully in-memory, the database still incurs significant overhead from the buffer manager, which must handle operations such as page pinning and unpinning, lock acquisition, buffer table lookups, and Least Recently Used (LRU) management.

AlloyDB's columnar engine is a built-in, in-memory cache that stores data in a specialized, scan-optimized format.

With this release, AlloyDB can use columnar engine accelerated HNSW to:

Pin the index: The pgvector HNSW index is pinned (kept persistently in-memory to ensure fast access) directly into the columnar engine’s memory.
Vectorized access: It utilizes a memory layout specifically designed for the high-concurrency, pointer-heavy traversals required by HNSW graphs.
Bypass buffer overhead: By navigating the graph in a specialized memory space, AlloyDB avoids the standard buffer manager bottlenecks. This architectural shift is what enables the dramatic QPS and recall improvements shown above, even when comparing against a fully-cached standard index.

Why it Matters

For enterprise-scale applications, this isn't just about a faster database—it's about cost and quality:

Reduced infrastructure costs: Achieve the same performance with significantly lower compute resources.
Better AI accuracy: Reach higher recall and quality at speeds that were previously only possible for "draft" (high-speed, lower-accuracy results) quality search.
No application changes required: Because this is built into AlloyDB, you get these gains using the same standard pgvector SQL syntax.

Note that the columnar engine does utilize memory, but it is highly compressed and meticulously managed. Because the engine stores vector data in an efficient columnar format, the memory footprint is minimal compared to the massive performance gains—making it a highly favorable trade-off for enterprise workloads.

Quick Start Guide

To try out columnar engine accelerated HNSW in AlloyDB, follow these steps:

1. Enable the columnar engine and index caching

Ensure that both google_columnar_engine.enabled and google_columnar_engine.enable_index_caching flags are set to on for your AlloyDB instance.

2. Add the HNSW Index to columnar engine

Once your HNSW index is created via pgvector, execute the following SQL command to cache it in the columnar engine:

code_block: <ListValue: [StructValue([('code', "SELECT google_columnar_engine_add_index('<hnsw_index_name>');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee27e50>)])]>

3. Additional Resources

New to AlloyDB? Discover AlloyDB with a 30-day free trial.
Google Colab Notebook: An end-to-end Python script to ingest the GloVe dataset, create indexes, and plot Recall vs QPS curves.
Is HNSW the right vector index choice for your use case? Check our ‘Choose a vector index in AlloyDB AI’ guide.

Now in preview: Find and fix software vulnerabilities with CodeMender

Tue, 21 Jul 2026 15:00:00 +0000

As adversarial AI threats accelerate attacks on code, security teams must counter them with machine-speed defenses that can automate code remediation and fight AI with AI.

CodeMender is our managed code security agent, and starting today, we're bringing its code scanning and remediation capabilities directly to you in preview.

CodeMender offers access to our generally available models via Gemini Enterprise Agent Platform, or it can be deployed as a core component of AI Threat Defense.

CodeMender also aligns with our multi-model approach, so you can choose the right model to optimize for cost, speed, and deep scanning performance. It will support third-party frontier model options later this year.

Watch this overview of CodeMender in Gemini Enterprise Agent Platform.

CodeMender can help you advance from passive scanning to automated code remediation, and reduce zero-day risk. It examines and remediates existing code security issues without sacrificing development velocity by:

Deploying the best-fit model. You can choose from multiple models to optimize for costs, speed, deep scanning, and coding performance.
Automating machine-scale remediation. You can now eliminate remediation bottlenecks caused by manual verification and patching, while keeping developers in the loop.
Prioritizing fixes by exploitability. You can run proof-of-concept exploits and execute simulations to verify that vulnerabilities in the code are exploitable, and prioritize resources on fixing the most critical issues first.

Find and fix vulnerabilities with AI

Born from Google DeepMind's pioneering AI research, CodeMender transforms vulnerability management from a manual bottleneck into an autonomous, high-speed system. Your developers and security practitioners can automatically scan software for flaws, verify them with executable exploits, and remediate them with tested code fixes.

“At Salesforce, trust is our number one value, and protecting customer data means continually raising the bar for how we find, validate, and mitigate risks. CodeMender brings AI into a critical part of the security lifecycle by accelerating the path from validated vulnerability to tested fix. As AI reshapes the threat landscape, capabilities like this help strengthen resilience and give our customers the confidence to keep innovating,” said Iain Mulholland, CISO, Salesforce.

"CodeMender consistently identified critical vulnerabilities that our other AI-enabled tools completely missed. It doesn't just find theoretical flaws — it proves the immediate risk and delivers targeted, validated fixes that secure our environment without disrupting core business logic," said Scott Ponte, head, Security Operations, Robinhood.

"CodeMender is fast, comprehensive, and genuinely ambitious about closing the loop from detection to fix, enabling teams to secure their software supply chain without losing velocity," said Ashwin Kannan, principal AI engineer, Office of the CTO, Palo Alto Networks.

How the CodeMender agent works

We’ve fine-tuned CodeMender’s harness to be continuously updated with the latest Google DeepMind research, including the up-to-date agent skills, security tools, and system prompts.

Operating in the secure-by-design Agent Platform, CodeMender is protected by enterprise-grade, built-in governance and security guardrails, including secure traffic routing through your VPC, data isolation and encryption, and zero retention of source code data.

As an agent, it can integrate with existing continuous integration and continuous delivery (CI/CD) workflows, or run directly in local developer environments using a lightweight command-line interface (CLI) client.

You can also configure CodeMender to scan and analyze code in a sandbox that you manage. The agent connects to your code repositories and works with developer tools, such as VS Code and Antigravity, to safely analyze first-party, open-source, and third-party software.

Scan: Find hidden vulnerabilities with flexible model scanning

CodeMender scans for top vulnerability classes and understands the unique context, goals, and functionality of your software repositories and applications.

Scan: Discovered new vulnerabilities and categorized by severity and type.

CodeMender’s harness with security context helps you discover sophisticated vulnerabilities that static and model-only scanning miss. These scans look for hard-to-find vulnerabilities like memory corruption, injection, web security issues, cryptographic flaws, and insecure data handling. CodeMender supports common software languages including C/C++, Go, Java, Python, Ruby, Rust, and TypeScript.

Verify: Simulate and verify exploits to reduce noise

CodeMender can help cut alert fatigue and false positives by proving a vulnerability presents a legitimate risk before fixing it. The agent goes beyond static code-pattern analysis by simulating an attack with exploit code it builds and runs in an isolated, customer-managed sandbox.

Verify: Creates verification plan and builds and tests exploits in your sandbox environment.

The agent uses this proof-of-concept exploit to verify that the security flaw poses a legitimate risk. This critical verification phase allows your security practitioners and developers to prioritize validated risks by eliminating false positives.

Remediate: Automatically generate and test code fixes

Identifying risky security flaws is only half the battle. Once a vulnerability is verified, CodeMender automatically generates a secure patch to resolve the issue. The fix is delivered as a code difference directly in developer tools, so it can be integrated into existing development workflows.

Remediate: Generates and tests code fix with code diff for developer review and approval.

CodeMender further strengthens the fix by using LLM-as-a-judge to ensure it doesn’t disrupt existing application functionality. You can even provide context on your codebase's distinct coding conventions and styles so that CodeMender generates code that matches it. Developers remain in full control, manually reviewing and approving CodeMender's patches before any code is committed to the repository.

CodeMender in AI Threat Defense

When leveraged as part of AI Threat Defense, Wiz orchestrates agentic application security, analyzing applications to prioritize investigations. It calls CodeMender to scan code (coming soon), enrich findings within the Wiz Security Graph with deployment context, and trigger Wiz Red Agent for AI pentesting to prove exploitability, ensuring that teams focus on the highest-risk vulnerabilities.

Through Wiz, AI Threat Defense calls CodeMender to scan code, enrich findings, and trigger AI pentesting.

Wiz serves as a command center for governing and scaling remediation in AI Threat Defense. The Wiz Green Agent orchestrates this lifecycle by directing CodeMender to generate and test high-fidelity patches enriched with application context from the Security Graph. This workflow empowers teams to resolve complex vulnerabilities with unprecedented speed and precision.

How to get started with CodeMender

Consistent with our multi-model approach, CodeMender can help you optimize for cost, speed, and deep scanning performance.

You can use CodeMender with our generally available Gemini models via Agent Platform, or deploy it as a core component of AI Threat Defense.

Separately, CodeMender with Gemini 3.5 Flash Cyber will be exclusively available to a small set of governments and trusted partners. We plan to expand this access over time.

CodeMender is a critical step towards a continuous, self-healing agentic software development lifecycle, a future where code is autonomously secured, validated, and patched before it ever hits production.

You can learn more about CodeMender and review the documentation here.

Generosity Under Conditions: Hardening Google Cloud Access Management

Tue, 21 Jul 2026 11:19:00 +0000

In Google Cloud, Identity and Access Management (IAM) helps you maintain access control over your cloud resources and operations. While it includes other features, this is its primary purpose. If you ever tried to harden security over your application, you know the importance of the Principle of Least Privilege (PoLP) ‒ grant the absolute minimum permissions to your users and workloads to allow them to perform their tasks. You reach it through use of predefined roles and custom roles and setting up a combination of Allow and Deny IAM policies at project, folder, or organization level. Using a combination of Allow and Deny policies along the resource hierarchy is an effective way to control access. This approach lets you enforce PoLP across many different scenarios.

The existing flexible control can be insufficient when resources in the project are shared between multiple workloads or used by more than one team. In many such scenarios, it is possible to bind IAM policies to a specific resource in the project. For example, consider the difference between granting the role Artifact Registry Editor (roles/artifactregistry.editor) on a project vs. granting it on a specific repository in the project. In the former case, the access is granted to ANY repository in the project. In the latter case, users will have the editor access only to a specific repository. However, binding IAM policies to a resource or service level isn't always possible. This is when it is time to use IAM conditions. Let’s look at two distinct examples that demonstrate the power of conditions when hardening access management: one for traditional administrative roles, and one for modern AI integrations.

Use Case 1: Constraining the Power of Admins

This case demonstrates how to restrict the specific operations that broad IAM roles are authorized to perform. You can easily scope administrative privileges for managing specific resources in a project by granting a "resource creator" role at the project level and an editor role on a selected resource. It is far more challenging to constrain IAM Admin Roles that are intended to grant access to operations rather than specific resources. A representative example would be the IAM Admin role (roles/iam.admin). Users granted this role can grant themselves any other role or create a new one. It greatly exceeds practical needs. The first step is to narrow the access by using the Project IAM Admin role (roles/resourcemanager.projectIamAdmin) that provides administrative privileges only at the level of the project.

It is possible, however, to restrict the granted privileges even further. For example, suppose you grant the Project IAM Admin role to your builder service account that creates resources and deploys workloads. The workloads only need access to the BigQuery and Agent Platform APIs (formerly Vertex APIs) and permission to write logs and traces. For such a case you can use the following gcloud CLI command or its alternative in Terraform:

code_block: <ListValue: [StructValue([('code', 'gcloud projects add-iam-policy-binding "${PROJECT_ID}" \\\r\n --member="serviceAccount:${SA_MAIL}" \\\r\n --role="roles/resourcemanager.projectIamAdmin" \\\r\n --condition="^:^\\\r\ntitle=LimitedIAMAdmin:\\\r\nexpression=api.getAttribute(\'iam.googleapis.com/modifiedGrantsByRole\', [])\\\r\n.hasOnly([\\\r\n\'roles/aiplatform.user\',\\\r\n\'roles/bigquery.jobUser\',\\\r\n\'roles/bigquery.dataViewer\',\\\r\n\'roles/cloudtrace.agent\',\\\r\n\'roles/logging.logWriter\'\\\r\n])"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdf1bc340>)])]>

The value of the condition parameter is defined using Common Expression Language (CEL) syntax. First it customizes a field delimiter to be a colon instead of a comma and then describes the condition fields title and expression. The expression field uses functions for API attributes to identify which roles are being granted to allow granting only the roles in the comma delimited list. The same operation in Terraform will look very similar. Using input variables instead of environment variables, it will look like this:

code_block: <ListValue: [StructValue([('code', 'resource "google_project_iam_member" "limited_project_iam_admin" {\r\n project = var.project_id\r\n role = "roles/resourcemanager.projectIamAdmin"\r\n member = "serviceAccount:${var.sa_email}"\r\n condition {\r\n title = "LimitedIAMAdmin"\r\n expression = <<-EOT\r\n api.getAttribute(\'iam.googleapis.com/modifiedGrantsByRole\', []).hasOnly([\r\n \'roles/aiplatform.user\',\r\n \'roles/bigquery.jobUser\',\r\n \'roles/bigquery.dataViewer\',\r\n \'roles/cloudtrace.agent\',\r\n \'roles/logging.logWriter\'\r\n ])\r\n EOT\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdf1bc820>)])]>

Use Case 2: Control over MCP Server Access

This case is about hardening access to specific services behind a single set of permissions.

Google exposes access to a subset of cloud resources and services via MCP Servers that expose Model Context Protocol (MCP) endpoints. The access to these servers is granted using the predefined MCP Tool User (roles/mcp.toolUser) role. This role grants access to ALL available MCP servers (for a project where an IAM policy is set). Using conditions helps to narrow the access to a specific MCP server.

code_block: <ListValue: [StructValue([('code', 'gcloud projects add-iam-policy-binding $PROJECT_ID \\\r\n --member="serviceAccount:$SA_EMAIL" \\\r\n --role="roles/mcp.toolUser" \\\r\n --condition="^:^\\\r\ntitle=bigquery_mcp_server_only:\\\r\nexpression=resource.service == \'bigquery.googleapis.com\'"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdf1bc040>)])]>

Notice that the value compared to the resource.service attribute is not the MCP server endpoint (which is bigquery.googleapis.com/mcp) but the endpoint of the service. It is possible to narrow the access scope further to the level of the specific MCP tools. For this you will need to use API attributes again. The following expression limits the service account access to the level of only two BigQuery MCP tools.

code_block: <ListValue: [StructValue([('code', "expression=api.getAttribute('mcp.googleapis.com/tool.name', '') in [\\\r\n'mcp_bigquery-mcp_execute_sql',\\\r\n'mcp_bigquery-mcp_execute_sql_readonly'\\\r\n]"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdf1bc550>)])]>

Note that if you condition the IAM policy binding at the MCP tool level, you don't need to validate the resource.service attribute.

For experimenting with MCP server access you can use the Getting Started with Google MCP Servers codelab and modify its gcloud projects add-iam-policy-binding commands.

And Even More

Besides enforcing precise control when using predefined roles, IAM conditions let you craft access management based on the time of the request. For example, the following condition's expression allows access only during daytime on weekdays:

code_block: <ListValue: [StructValue([('code', "expression=request.time.getHours('Europe/Berlin') >= 9 &&\\\r\nrequest.time.getHours('Europe/Berlin') <= 17 &&\\\r\nrequest.time.getDayOfWeek('Europe/Berlin') >= 1 &&\\\r\nrequest.time.getDayOfWeek('Europe/Berlin') <= 5"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdf1bc130>)])]>

The expression limits access from 9 o'clock in the morning to 5 o'clock in the evening according to the "Europe/Berlin" timezone from Monday to Friday (days of the week range from 0 to 6, starting with Sunday).

IAM conditions allow controlling the identity of the actor using the principal attributes. However, it can easily become an anti-pattern. The recommended practice is to control the identity of actors allowed to use the policy through the list of the IAM policy's principals instead of using the conditions.

Conclusion and More Resources

While IAM conditions give you surgical precision over Allow policies, you can take your defense-in-depth strategy even further with IAM Deny policies. With Deny Policies you can grant access using the predefined IAM roles with Allow policies and remove excessive permissions of the role to enforce PoLP. See the following resources for additional information about Deny policies:

Identify the permissions that are supported in deny policies.
Get the format of principal identifiers in deny policies.
Find out how to troubleshoot access issues with deny policies.
Learn more about denying access to principals.
Read the blog post about Build defense in depth.

You can use Google Skills for hands-on experience with IAM policies.

Accelerating automotive innovation with C4A-metal and Panasonic Automotive vSkipGen

Mon, 20 Jul 2026 16:00:00 +0000

As the automotive landscape accelerates toward software-defined vehicles, Cockpit Domain Controllers (CDCs) are becoming the core of next-generation in-cabin experiences. The ability to rapidly develop, test, and validate CDC software in a flexible, hardware-independent environment is critical for innovation and time-to-market. However, physical hardware constraints and the requirement for high-performance graphics present significant challenges for global development teams.

Panasonic Automotive’s vSkipGen™ addresses these challenges as a next-generation CDC virtualization platform, now validated on Google Cloud’s C4A-metal, our Axion bare-metal offering. By integrating Panasonic Automotive’s advanced Unified HMI™ remote GPU offload technology with support for Android Automotive OS (AAOS) and Android SDV, vSkipGen delivers a robust, cloud-native solution for cockpit software development and validation — empowering teams to innovate without hardware limitations.

At Google Cloud, we provide workload-optimized infrastructure to help ensure the right resources for every task. Similar to the entire Axion virtual machine family, C4A-metal instances are built on Google Cloud’s custom Arm-based Axion architecture. C4A-metal offers 96 vCPUs, two DDR5 memory configurations (384GB and 768GB), and up to 100Gbps of networking bandwidth. It also provides full support for Google Cloud Hyperdisk, including Balanced, Extreme, Throughput, and ML types. And like the rest of the bare metal portfolio, C4A-metal is powered by Titanium, a key component for multi-tier offloads and security that is foundational to our infrastructure.

High performance for demanding workloads

C4A-metal is particularly well-suited for complex tasks such as creating digital twins of vehicle cockpits where performance must accurately mirror real-world behavior. Traditionally, the transition to software-defined vehicles has relied on expensive and scarce physical prototypes; C4A-metal overcomes this by offering the high performance and hardware-level access of bare metal with the scalability of the cloud.

Panasonic Automotive leverages C4A-metal to bypass traditional hardware bottlenecks, enabling their teams to execute complex virtualization tasks and accelerate the development of next-generation cockpit software.

"Google Cloud’s Axion Bare Metal has been a game-changer for our vSkipGen™ platform. By providing scalable, high-performance Arm-based infrastructure, C4A-metal allows our teams to develop and test production-intent software in the cloud with behavior that closely matches target automotive hardware. This cloud-to-car bit parity reduces dependence on costly physical prototypes, improves validation efficiency, increases test coverage and accelerates time-to-market for next-generation cockpit platforms.” - Andrew Poliak, CTO, Panasonic Automotive Systems America.

By leveraging vSkipGen and Unified HMI on C4A-metal, automotive manufacturers can now build, test, and validate full AAOS stacks in a hardware-independent, cloud-native environment, moving from physical dependency to scalable digital twins.

Figure 1: Unified HMI solution overview

How vSkipGen works: Virtualizing the cockpit with Cuttlefish

Panasonic Automotive’s vSkipGen acts as a digital twin for physical CDC hardware. To provide a hardware-agnostic environment for Android virtual machines, vSkipGen uses components of Android Cuttlefish. At its core, vSkipGen leverages a cloud-optimized Virtual Machine Monitor (VMM) built on crosvm (the open-source, security-focused VMM originally developed for Chrome OS) which utilizes Linux KVM (Kernel-based Virtual Machine) for hardware-assisted virtualization. The VMM backend is implemented in Rust for enhanced security, scalability, and performance. By running the full stack on C4A-metal (see Figure 2), Panasonic lets developers boot a full AAOS image in the cloud, which behaves exactly like the software running in a physical vehicle.

The platform virtualizes all essential peripherals, such as the audio, GPU, sensors, cameras, Controller Area Network (CAN), Bluetooth, and Wi-Fi, using the VirtIO standard. This VirtIO-native approach allows developers to interact with the virtual devices exactly as they would with the physical hardware. Furthermore, vSkipGen seamlessly connects with automotive simulators and software-in-the-loop (SiL) environments for comprehensive scenario and edge-case validation, enabling teams to conduct software validation and run automated test suites without needing early access to physical prototypes.

Figure 2: vSkipGen Cockpit virtualization architecture

Figure 3: Remote GPU rendering flow

Accelerating graphics on the go with Unified HMI

High-performance graphics is central to the modern driving experience, but rendering it in a virtual environment can be challenging. Panasonic’s Unified HMI solves this by decoupling HMI rendering from specific hardware. A lightweight Unified HMI component operates outside the VM to offload OpenGL ES commands (the specific data being rendered) from the Cuttlefish instance to GPU-equipped compute resources on Google Cloud, which handle the workloads with hardware acceleration. The rendered UI is then streamed to any standard browser using low-latency WebRTC. This helps ensure that global development teams can experience high-fidelity visuals in real time, regardless of their location.

Unified HMI establishes a unified virtual display layer across multiple Electronic Control Units (ECUs) and virtual machines, allowing applications to render to different displays from anywhere within the system.

Benefits for software-defined vehicle development

With C4A-metal and Panasonic Automotive’s vSkipGen, manufacturers building software-defined vehicles can:

Build and validate AAOS-based software in the cloud using Cuttlefish before physical hardware is available
Use industry-standard VirtIO to emulate critical CDC devices for robust, production-grade validation
Stream interactive cockpit experiences to any browser to support distributed engineering teams
Run multiple isolated CDC instances in parallel to support large-scale automated testing and CI/CD pipelines
Reduce cost and environmental impact by minimizing the need for expensive physical hardware prototypes, supporting sustainable development practices
Enjoy a future-ready architecture built on open standards, crosvm, and Rust for enhanced security, performance, and long-term adaptability

Get started

C4A-metal is generally available worldwide; please refer to the public documentation for additional information. Panasonic Automotive’s vSkipGen with Unified HMI for Google Cloud will soon be available for evaluation access. To explore how these solutions can help you speed up cockpit software development, contact the team at vSkipGenSupport@panasonicautomotive.com.

_{Disclaimer
All trademarks, tradenames, and service marks used herein are the property of their respective owners.}

Making highly available, multi-region Cloud Run services just got easier

Mon, 20 Jul 2026 16:00:00 +0000

Application downtime for mission-critical services can directly impact your reputation and bottom line. To avoid that, you need to be able to deploy regionally resilient workloads that detect and automatically recover from failures. But setting up multi-region, highly available deployments often involves complex configurations, and responding to incidents or outages is usually a manual process.

Multi-region services on Cloud Run provide a one-command approach to deploying the same service configuration across multiple regions. When deployed with a global external application load balancer, you can serve traffic from different regions.

Now, we’ve made it easier to detect regional service disruptions and automatically fail over to a healthy region within seconds with new capabilities:

Readiness probes provide instance-level health checks for your Cloud Run service to determine exactly when your containers are ready to serve traffic. You can also use these probes to monitor how many healthy or unhealthy instances exist for your service in each region.
Service health aggregates instance-level health checks from readiness probes to calculate the health of your service in each region. This aggregate health is exposed via serverless network endpoint groups (NEGs) in each region. When your service is connected to a global application load balancer, traffic automatically fails away from regions with unhealthy services. Service health can be used with both single and multi-region services.

Let’s take a closer look at some scenarios where these new capabilities can come in handy.

Use cases

To make your Cloud Run applications highly available, it is essential to minimize the downtime for each incident. In high availability scenarios, readiness probes can help you detect regional service failures and automatically fail over, minimizing service degradation or disruptions.

To achieve automated failover, one key thing to consider is whether you plan to support application traffic from the public internet or from within your private network (VPC).

Public internet applications: When you have a public-facing website or API, configure Cloud Run with a global external application load balancer for automatic detection and failover capabilities.
Private network applications: When you have private applications with internal traffic, configure Cloud Run with a cross-regional internal application load balancer for automatic detection and failover capabilities.

Design Considerations

Cloud Run’s new service health excels at quickly detecting and recovering outages in active-active configurations, where two or more regions are actively configured to serve traffic. Some things to consider when designing your multi-region setup:

Single points of failure: As you design your application, ensure that each layer of your application, including your database layer, has regional redundancies to avoid any single points of failure. For three-tiered applications on Cloud Run, consider setting up your web tier and application tier with distinct multi-region architectures to handle public internet and private networking respectively.
Data replication: When replicating data across regions and evaluating your recovery point objective (RPO), consider whether you require zero data loss. Cloud Run service health works best with read- and write-heavy applications that actively synchronize data across regions.
Data residency: Google Cloud offers several multi-region database configurations with managed multi-region solutions including Firestore, Spanner, Cloud Storage, and Cloud SQL. These all work great for multi-region architectures on Cloud Run that have strict data sovereignty requirements.

Get started

Cloud Run’s enhanced multi-region high availability services are currently available in all Cloud Run regions at no additional cost. You only pay for the standard CPU and memory required to run the readiness probes. To learn more, check out our documentation.

What’s new with Google Cloud

Fri, 17 Jul 2026 16:00:00 +0000

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

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

aside_block: <ListValue: []>

Jul 13 - Jul 17

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

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

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

Read more here.

Jul 6 - Jul 10

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

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

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

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

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

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

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

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

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

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

Watch the 60-minute teardown

Jun 29 - Jul 3

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

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

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

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

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

Register for the July 30 Portuguese Community TechTalk

Jun 22 - Jun 26

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

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

Jun 15 - Jun 19

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

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

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

Jun 8 - Jun 12

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

Get started for free today

Jun 1 - Jun 5

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

Register for the June 18 Spanish Community TechTalk

May 25 - May 29

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

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

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

Register for the June 11 Community TechTalk

May 18 - May 22

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

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

May 11 - May 15

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

Register for the May 21 Community TechTalk

Apr 27 - May 1

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

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

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

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

Apr 20 - Apr 24

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

See the 2026 Partner Award winners

Apr 13 - Apr 17

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

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

Explore the MCP overview

Apr 6 - Apr 10

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

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

Mar 30 - Apr 3

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

RSVP here.

Mar 23 - Mar 27

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

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

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

Read the full guide.

Mar 16 - Mar 20

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

Explore the full range of what the assistant can do.

Mar 9 - Mar 13

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

Mar 2 - Mar 6

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

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

Register for the TechTalk

Feb 23 - Feb 27

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

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

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

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

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

Feb 9 - Feb 13

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

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

Register now to reserve your spot.

Jan 26 - Jan 30

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

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

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

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

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

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

Watch the video.

Jan 19 - Jan 23

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

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

Learn more about Firestore pipeline operations.

Level Up Your Column-level Security: Using IAM Data Governance Tags in BigQuery

Fri, 17 Jul 2026 16:00:00 +0000

Many BigQuery customers rely on policy tags for protecting their sensitive information in BigQuery. Policy tags were the go-to solution for applying column-level access controls, allowing only users with the right permission to view sensitive columns like personally identifiable information (PII). It was a robust and effective system — for its time.

However, data ecosystems have grown in complexity, and the tools we use to help secure them need to evolve with them. New challenges include creating and managing a taxonomy that supports multiple tags across multiple regions and locations, enabling disaster recovery, and integrating with a broad centralized governance strategy.

To help you meet the needs of today’s data ecosystems, we're excited to introduce the preview of data governance tags in BigQuery. Built on Google Cloud's Identity and Access Manager’s (IAM) Resource Manager infrastructure, data governance tags provide a scalable, and robust method to help you manage access controls and protect your BigQuery column data.

What are IAM data governance tags?

Data governance tags are a special type of Resource Manager tags. You can create it by setting the purpose field to DATA_GOVERNANCE when creating a tag key in IAM, you designate it for use in BigQuery column-level security. You can create a hierarchical tree of data governance tags specifically for column-data governance purposes and apply them directly to your BigQuery columns.

Why use data governance tags for column-level security?

Global scope, regional enforcement: Unlike policy tags (which are regional-only), data governance tags are global. You can define a single tag key:value pair (like “data_sensitivity:high”) at the organization level and use it across any project or region in your organization.
Managed disaster recovery: Security policies should persist during a failover. Data governance tags and their associated data policies are automatically replicated to secondary regions. If you need to switch regions, your security posture moves with you automatically.
Hierarchical security: You can now build a tree of tags up to five levels deep. This allows for inheritance and more granular classification (such as PII > Financial > CreditCardNumber).
Decoupled governance: You can tag your data to organize and classify it before you decide to enforce security. Access control only kicks in once you define a data policy for that tag, giving your team more flexibility during data onboarding.

Three steps to column-level security

Step 1: Create the tag key and values

1. Create data governance tag key: First you create an IAM tag key in Console, gcloud CLI, or API. The magic happens when you specify the purpose field as --purpose=DATA_GOVERNANCE for the tag key. This key change tells Google Cloud that this tag will be used for column-level security in BigQuery.

code_block: <ListValue: [StructValue([('code', '# Example: Creating a Data Governance tag key named "data_class"\r\ngcloud resource-manager tags keys create data_class \\\r\n --parent=projects/my-governance-project \\\r\n --purpose=DATA_GOVERNANCE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11100>)])]>

2. Create tag values:

Once your data governance tag key has been created, you need to create specific tag values under the key that you will use to categorize/classify your column data. One of the useful features of data governance tags is the ability to build a hierarchical tree of tag values. The tag-values tree allows you to create broad categories and then drill down into specific categories based on data type. You can go up to five levels deep for granular access control.

code_block: <ListValue: [StructValue([('code', '# Level 1: Create a tag value called "pii"\r\ngcloud resource-manager tags values create pii \\\r\n --parent=my-governance-project/data_class\r\n\r\n\r\n# Level 2: Create a child value under "pii" for "private" data\r\ngcloud resource-manager tags values create private \\\r\n --parent=my-governance-project/data_class/pii\r\n\r\n\r\n# Level 3: Create another child tag value for "email" under "private"\r\n# You can go up to 5 levels deep for granular control\r\ngcloud resource-manager tags values create email \\\r\n --parent=my-governance-project/data_class/private'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11a90>)])]>

Step 2: Attach tags to your columns via JSON schema

1. Export your existing schema

For existing tables, the most efficient way to manage tags is by updating the table schema using a JSON file and using API or BQ CLI because it allows you to tag multiple columns at once.

code_block: <ListValue: [StructValue([('code', '# Save the current table schema to a local JSON file.\r\nbq show --schema --format=prettyjson my_project:my_dataset.my_table > schema.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11af0>)])]>

2. Add the dataGovernanceTags to your JSON file

Open schema.json and add the tag mapping to your sensitive columns. Note the use of the namespaced key and the short name for the value.

code_block: <ListValue: [StructValue([('code', '[\r\n {\r\n "name": "user_email",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "email" \r\n }\r\n }\r\n },\r\n {\r\n "name": "phone_number",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "private"\r\n }\r\n }\r\n },\r\n {\r\n "name": "government_id",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "pii"\r\n }\r\n }\r\n }\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11400>)])]>

3. Update the table:

Apply the schema to your BigQuery table.

code_block: <ListValue: [StructValue([('code', '# Overwrite the table schema with your newly tagged JSON file.\r\nbq update --project_id=my-data-project --schema=schema.json my_dataset.my_table'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11bb0>)])]>

Alternatively you can also use SQL to bind data governance tags to BigQuery table columns.

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE TABLE my_dataset.my_table(\r\n user_email STRING\r\n OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'email')]),\r\n );\r\nALTER TABLE my_dataset.my_table\r\nALTER COLUMN phone_number\r\n SET OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'private')]);\r\nALTER TABLE my_dataset.my_table\r\nADD COLUMN government_id\r\n STRING\r\n OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'pii')]);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11850>)])]>

You can also remove a column tag by setting it to [], for example:

code_block: <ListValue: [StructValue([('code', 'ALTER TABLE my_dataset.my_table\r\nALTER COLUMN phone_number\r\n SET OPTIONS (\r\n data_governance_tags = []\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee113d0>)])]>

You can use information_schema COLUMNS view to see the columns tags:

code_block: <ListValue: [StructValue([('code', "SELECT\r\n column_name,\r\n data_governance_tags[SAFE_OFFSET(0)].key AS tag_key,\r\n data_governance_tags[SAFE_OFFSET(0)].value AS tag_value,\r\nFROM `my_project.my_dataset.INFORMATION_SCHEMA.COLUMNS`\r\nWHERE table_name = 'my_table'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11310>)])]>

The result is similar to the following:

code_block: <ListValue: [StructValue([('code', '+---------------+----------------------------------+-----------+\r\n| column_name | tag_key | tag_value |\r\n+---------------+----------------------------------+-----------+\r\n| user_email | my-governance-project/data_class | email |\r\n| phone_number | my-governance-project/data_class | private |\r\n| government_id | NULL | NULL |\r\n+---------------+----------------------------------+-----------+'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11520>)])]>

Step 3: Create data policies

Finally, define a BigQuery data policy to govern access to these tagged columns. These policies explicitly reference the tag values you attached previously. Note that, while data governance tags are global, data policies are regional.

To protect your data, the policy must be created in the same region where your BigQuery table is located. Once the policy is defined, access is only granted to the specified grantees; all others will be denied access to the sensitive column data.

Also, keep in mind that security in BigQuery is layered. For a data policy to be effective, the users (grantees) must first possess base-level access to the table itself (typically via a role like roles/bigquery.dataViewer). Data policy then acts as a second security layer, determining whether they view the raw, sensitive column data or a masked, obfuscated version.

Masking policy for ‘pii’ tagged column-data (SHA256 Masking):

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "DATA_MASKING_POLICY",\r\n "dataMaskingPolicy": { "predefinedExpression": "SHA256" },\r\n "grantees": [ "principalSet://goog/group/grp-sales@corp.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "pii" }\r\n },\r\n "dataPolicyId": "masking_policy_for_data_class_pii"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11940>)])]>

Raw access policy for ‘pii’ tagged column-data

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "RAW_DATA_ACCESS_POLICY",\r\n "grantees": [ "principal://goog/subject/abc@xyz.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "pii" }\r\n },\r\n "dataPolicyId": "raw_access_policy_data_class_pii"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee115e0>)])]>

Masking policy for “private” tagged column data (NULL Masking):

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "DATA_MASKING_POLICY",\r\n "dataMaskingPolicy": { "predefinedExpression": "ALWAYS_NULL" },\r\n "grantees": [ "principal://goog/subject/abc@xyz.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "private" }\r\n },\r\n "dataPolicyId": "null_policy_data_class_private"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdee11280>)])]>

With these three steps, your column data is now protected. The next time a principal queries your BigQuery table, our authorization engine automatically evaluates their identity against your data policies. If the principal is part of the policy, they get to see the masked or raw data as per the policy; if they are not, then they will be denied access.

Get started today

Data governance tags are a powerful new tool to enhance your data security and governance strategy in BigQuery. We are continuously working to enhance data governance capabilities in BigQuery. Future updates include support for using SQL to create tags and tag based policies, ability to attach multiple tags to a single column, ability to define policies based on combinations of tags, and deeper integrations with services like Knowledge Catalog.

You can start tagging your columns and defining fine-grained access controls at scale. To learn more, dive into the Data Governance Tags documentation.

13 hands-on demos to build on Gemini Enterprise Agent Platform

Fri, 17 Jul 2026 16:00:00 +0000

Earlier this year, we introduced Gemini Enterprise Agent Platform, where you can build, scale, govern, and optimize agents. Today, we’re sharing 13 demos that walk you through what Agent Platform can do. Each one teaches a concept, a pattern, or an architecture you can put to work immediately.

The best part? You don't have to follow them step-by-step. Install Agents CLI into your favorite coding agent (Antigravity, Claude Code, Codex, whatever you use) and it instantly gets seven skills that make it an expert in ADK and Agent Platform. Describe what you want to build in plain English, and your coding agent scaffolds, evaluates, deploys, and monitors the agent for you. You’ll never have to leave your editor.

Let’s dive in!

Build AI agents

These demos are all built on the code-first ADK. They start at the foundation and work up.

1. Start here: build your first agent with ADK. The ADK Foundation codelab is your perfect on-ramp. You set up your environment, define a basic conversational agent powered by Gemini, configure its settings, and test it through both a command-line interface and a web UI. If you've never touched ADK before, do this one first.

2. Build an event-driven approval agent with human-in-the-loop. The ambient expense agent codelab is the most complete "Agent Platform in action" demo in the set. You build a corporate expense agent using ADK 2.0's graph-based workflow API. Expenses under a threshold get auto-approved in plain Python. Anything above goes through a pre-LLM security screen (PII redaction, prompt-injection defense), passes a Gemini compliance analysis, and pauses for a human-in-the-loop review before anything is finalized. You mount it behind FastAPI, trigger it from Pub/Sub events, and grade it with an LLM-as-judge eval. Keep this agent in mind – it comes back in the Scale and Govern sections.

3. Connect agents to your data with the Model Context Protocol. The MCP codelab shows you how to build reusable MCP tools that let Gemini query BigQuery, search files, and call APIs. MCP is an open protocol, so the tools you build work across different vendors and frameworks.

4. Build a dynamic frontend with Agent-to-UI (A2UI). The best user experiences are highly visual. The A2UI codelab shows you how to build an agent that renders real interface components (layouts, charts, interactive menus) that update dynamically in real time as the conversation flows. The agent literally assembles the UI the user needs, on the fly.

Scale AI agents

A prototype on your laptop is one thing. Handling production traffic, memory, and orchestration is what comes next.

5. Deploy a stateful data science agent to Agent Runtime (formerly known as Agent Engine). The Stateful Data Science Agent codelab walks you through building a BigQuery agent that remembers user preferences across sessions via Memory Bank, then deploying it directly to Agent Runtime. All of the underlying infrastructure, scaling, and session management are handled for you automatically.

6. Build long-running agents that pause, resume, and never lose context. Building an agent that responds to a single prompt is easy, but real enterprise workflows often take days or weeks to complete. This tutorial walks through building agents that run reliably for weeks. You'll learn three architectural patterns: durable state machines, event-driven idle time handling, and checkpoint-and-resume with persistent sessions. The example is an onboarding coordinator agent that survives container restarts and picks up exactly where it left off.

7. Deploy an ambient expense agent to Agent Runtime with the Agents CLI. Remember the expense agent from the Build section? The Deploy to Agent Runtime codelab picks up that agent and takes it to production. You scaffold your deployment config with the Agents CLI, preview it with a dry run, then deploy it live. Cloud Trace, Cloud Logging, and BigQuery Agent Analytics wire in automatically, and the agent auto-registers in Agent Registry, so it’s discoverable across your org the moment it goes live.

8. Give your production agent a real front end. The frontend codelab is where everything comes together. You build a manager dashboard on Cloud Run, connect it to Agent Runtime through an OIDC-authenticated Pub/Sub pipeline, and give managers the ability to resume paused human-in-the-loop sessions from the browser. It ties the expense agent and the deployment together into a complete end-to-end enterprise architecture.

Govern AI agents

Scaling agents across an organization requires a system of built-in guardrails to manage access, track endpoints, and filter traffic.

9. Secure your agent's lifecycle from the first commit. The Secure Agentic Coding codelab shows you how to build a shopping assistant test-first with test-driven development (TDD), wire in a custom STRIDE threat model, set up a Semgrep pre-commit hook, and configure a PreToolUse gate that blocks risky actions before execution. You deliberately plant a hardcoded API key, and the agent catches and fixes it the moment the hook fires.

10. Control agent access with Agent Gateway. The Agent Gateway codelab covers runtime governance. You deploy a multi-tool ADK agent on Agent Runtime that calls MCP servers on Cloud Run through Agent Gateway. Each agent gets a unique identity with end-to-end mTLS. Every outbound call goes through IAP authentication and IAM authorization. On top of that, Model Armor inspects all content for prompt injection and data leakage. It’s a complete, production-grade governance stack in one demo.

Optimize AI agents

Shipping an agent is the start. The hard part is knowing whether your next prompt tweak actually makes it better or quietly breaks ten other things. Agent Platform gives you the tools to close that loop.

11. Drive the agent quality flywheel from your coding agent. You tweaked a prompt. It looks better on three examples, but did you just break ten others? This tutorial introduces a five-stage evaluation flywheel you run directly from your coding agent: prepare data (from OTel traces, hand-crafted cases, or synthesized scenarios), run inference, grade with Google's adaptive AutoRaters, analyze failure clusters, and execute targeted optimizations. The AutoRaters are built on the same principles Google uses to evaluate its own models and first-party agents, developed in partnership with DeepMind. Describe what you want measured in plain language. Your coding agent picks up the rest.

12. Build a cross-language multi-agent pipeline with A2A. In a large enterprise, different teams will inevitably build agents in different languages. This tutorial walks through a contract compliance pipeline where a Python-based agent extracts terms using Gemini and a Go-based agent validates them against corporate policy. The two services connect via the Agent-to-Agent (A2A) protocol and are orchestrated by ADK. You'll learn how RemoteA2aAgent turns any A2A-compliant service into a local sub-agent with a few lines of code.

13. Scale agents across frameworks with CrewAI, LangGraph, A2A, and ADK. Most production teams don't standardize on one agent framework. The codelab shows you how to orchestrate across all of them: an ADK control room delegates planning to a LangGraph state machine, which dispatches tasks to a CrewAI execution crew, all connected via the A2A protocol. If one step fails, the control room re-plans automatically.

Get started

If you want to see the full agent development lifecycle in under 10 minutes, watch this walkthrough. Otherwise, install Agents CLI, open up your coding agent, and start building today.

Guide to AI Tokenomics: Eleven Principles for Token Efficient Software Engineering

Fri, 17 Jul 2026 09:14:00 +0000

Optimizing token consumption is key to keeping AI coding assistants fast and accurate. You might not be writing every line of code any more, but now you’re responsible for directing those coding assistants to focus on getting the most out of each token. Context bloat increases latency and causes models to forget instructions or hallucinate, it also costs money and drives human attention away from the problems that actually matter. Structured habits help you maintain a fast, precise, and productive feedback loop.

1. Start with a balanced model

When you are unsure, start with the default Gemini 3.5 Flash (Medium reasoning). Gauge complexity as you go. Scale up to larger models or higher reasoning if a task fails, seems to take too many hops, or needs complex design.

2. Use skills from the beginning

Avoid explaining your workflow, testing rules, or environment in every prompt. Ask around, find online, or package your own reusable skills with SKILL.md files and scripts. The agent triggers them automatically, keeping prompts clean and avoiding unnecessarily searching for online docs or inspecting local code and environment.

3. Automate with scripts and CLI tools

For repetitive chores like formatting many files or extracting log data, have the agent create simple local tools. Use official CLI tools for setup, linting, and testing. Run read-only commands to research the codebase before writing code, avoiding long trial-and-error loops.

4. Delegate output-heavy tasks

Delegate output-heavy tasks, like deep research or separating frontend and backend work, to sub-agents. Once their work is done, you only reconcile the final results, rather than the full trajectory.

5. Divide and conquer

David Rensin wrote “Elephants, Goldfish and the New Golden Age of Software Engineering” that explains how to use high-reasoning, long-context sessions ("Elephant") to generate a detailed execution plan (the "Goldfish"). Execute that plan in a clean, low-token session. Checkpoint your progress often with commits or artifacts so you can restart from a clean state when context fills up.

6. Shift verification left

Automate testing early. Run local builds and unit and functional tests before doing UI testing. Tell the agent to perform the expensive smoke-test in the browser right before handoff. Save expensive verification loops for the very end of the milestone.

7. Undo when adrift

If the agent drifts and you know the fix, use the Undo button in the trajectory thread or revert your files. Do not pile corrective prompts on top of a broken state, which poisons the context.

8. Be specific with context

Be specific rather than micro-managing. A clear instruction with a few spelling errors is better than a grammatically accurate broad request. Similarly, pointing the agent to the exact file, section, or error you care about (with an obvious // SHOULD BE X, NOT Y, FIX THIS annotation) instead of sending it on an open-ended search in a 10k log quest goes a long way. Whenever possible, use inline comments, so the agent knows exactly where you want the fix.

9. Iterate on rules

If you keep correcting the agent's behavior, update your global rules in AGENTS.md or edit the skill. Fix the instructions instead of prompting the agent repeatedly, so the change persists.

10. Avoid uncontrolled loops

Supervisor loops that scan projects for pending work can find optimizations, but they can easily burn your entire token budget. If you run loops, set strict limits and stop conditions. High autonomy requires tighter guardrails and better evaluations. Do not let agents poll status in a loop; use event-driven wakeups.

11. Start new sessions for each new topic

If you are continuing on the same topic, using the same chat can allow the agent to reuse the existing context, but if you are changing the topic, start a new chat. The agent will be able to provide better answers with fewer tokens if it only pulls in the context that it needs.

Prioritize and spend wisely

Tokens aren’t infinite. Behind every LLM call is a real, physical machine doing work to produce output for you. Prioritize the projects and features you care about.

Token optimization is about directing the AI's attention. By using a tiered approach you keep development fast and output sharp, while optimizing spending. We hope these 11 principles will inspire you to find the right balance between steering and automation in your AI sessions.

Google is a Leader and positioned furthest in Vision and highest in Execution in the 2026 Gartner® Magic Quadrant™ for Conversational AI Platforms

Thu, 16 Jul 2026 19:00:00 +0000

For the second consecutive year, Google has been named a Leader in the Gartner® Magic Quadrant™ for Conversational AI Platforms. Google received the furthest and highest in positioning on the "Vision" and "Execution" axes and is now ranked #1 in three out of four Critical Capabilities Use Cases. We believe this recognition reflects our continued investment in frontier AI research, enterprise infrastructure, and helping customers move AI from experimentation into production at scale.

More importantly, we believe it reflects the success of the organizations building with Gemini Enterprise for Customer Experience every day.

Figure 1: Magic Quadrant for Conversational AI Platforms (Image of the Gartner Magic Quadrant for Conversational AI Platforms, showing Google positioned in the "Leaders" quadrant.)

Download the complimentary 2026 Gartner Magic Quadrant for Conversational AI Platforms.

Building the next generation of customer experiences with Gemini Enterprise for Customer Experience

Enterprise customer experiences are entering a new era. Organizations are moving beyond traditional chatbots toward AI agents that can understand customer intent, reason across enterprise knowledge, and take action across business systems.

As these experiences move into production, enterprises need more than powerful models. They need an AI platform that combines frontier research with enterprise security, governance, operational reliability, and the ability to scale globally.

Today, Gemini Enterprise for Customer Experience brings these capabilities together to give your customers a frictionless experience. Organizations can deploy agents that eliminate disjointed interactions across voice and digital channels, allowing customers to discover, purchase, and get help across every touchpoint without starting over. This connected journey drives revenue growth, deeper loyalty, and lower operational costs.

Built for production AI

At the center of Gemini Enterprise for Customer Experience is CX Agent Studio, Google’s platform for building intelligent customer experience agents. By coupling our newest models, unified product capabilities, and updated deployment best practices, we abstract technical complexities so enterprise teams can build at an unprecedented speed and derive true business value.

Organizations can use CX Agent Studio to:

Build multimodal AI agents and deploy them across voice and chat channels,
Assist human support and service representatives in real time,
Analyze customer conversations to improve business outcomes,
And, accelerate deployment with pre-built agents for industries including retail, food ordering, and automotive.

Modern customer experiences demand more than answering questions. They require AI that can understand complex requests, retrieve trusted information, reason through multiple steps, and take action across enterprise systems. For example, The Home Depot is already using these capabilities for customer support - helping customers reach solutions up to 4x faster than traditional phone menus when calling into a store. AI voice agents built with CX Agent Studio understand why a customer is calling in fewer than 10 seconds to help customers complete purchases, initiate service requests, or seamlessly transition to a human associate when needed.

“AI does a tremendous job at recognizing customer intent and taking direct action to help complete a purchase or even start a service request. And of course, if they need to speak with an associate, we’ll quickly connect them.” - Jordan Broggi, EVP of Customer Experience and President of Online, The Home Depot

CX Agent Studio combines native multimodal capabilities, agent orchestration, enterprise retrieval, and integrated developer tooling to help organizations move quickly from experimentation to production.

Whether deploying pre-built industry agents or building custom experiences, organizations maintain enterprise-grade security, governance, and operational controls while retaining complete ownership of their customer experience.

Powered by Google’s AI optimized stack

Gemini Enterprise for Customer Experience is built on Gemini models developed by Google DeepMind. But having access to Google DeepMind's world-leading research and frontier models is the starting line. A brilliant model is only as powerful as the foundation it runs on. To put human-grade customer experience agents into production - where milliseconds of latency matter for voice interactions and hallucinations pose real business risks - you need a platform engineered for performance.

This is why Gemini Enterprise for Customer Experience and CX Agent Studio run natively on Google Cloud’s complete, first-party AI stack. Spanning from our custom-built AI infrastructure (AI Hypercomputer) and the Agentic Data Cloud that grounds your models in real-time truth, up to the autonomous protection of Agentic Defense, every layer is co-designed to function as a single, unified system on a foundation of uncompromising security.

For enterprise CX leaders, this is your structural edge. Because your agents are built on this unified stack, they automatically benefit from our continuous advancements - absorbing every new DeepMind capability and hardware efficiency we achieve. This deep integration delivers the speed, safety, and cost-efficiency you need, freeing your teams to focus on building the next generation of customer experiences.

Looking ahead

The next generation of customer experiences won’t simply answer questions. They’ll understand context, reason across enterprise knowledge, collaborate with people, and take meaningful action on behalf of customers.

Our vision is to help organizations build AI agents that are proactive, personalized, and continuously improving across every customer touchpoint.

To download the full 2026 Gartner® Magic Quadrant™ for Conversational AI Platforms report, click here. For more information on CX Agent Studio and Gemini Enterprise for Customer Experience, visit our website.

_{Gartner, Magic Quadrant for Conversational AI Platforms, Gabriele Rigon, Justin Tung, Arup Roy, Adrian Lee, Uma Challa, July 7, 2026}

_{Gartner, Critical Capabilities for Conversational AI Platforms, Justin Tung, Uma Challa, Adrian Lee, Gabriele Rigon, Arup Roy, July 7, 2026}

_{Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Google.}

_{GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.}

Cloud CISO Perspectives: How AI leverages deep context as the defender’s advantage

Thu, 16 Jul 2026 16:00:00 +0000

Welcome to the first Cloud CISO Perspectives for July 2026. Today, Francis deSouza, COO, Google Cloud and President, Security Products, explains the crucial role that deep context plays in creating an AI advantage for defenders.

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

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

How AI leverages deep context as the defender’s advantage

By Francis deSouza, COO, Google Cloud and President, Security Products

Francis deSouza, COO, Google Cloud and President, Security Products

Attackers are making headlines with AI, but defenders have a distinct and powerful advantage.

AI is rapidly transforming the cyberthreat landscape, driving unprecedented shifts in the scale, speed, and sophistication of attacks. Just recently, Google Threat Intelligence Group documented a critical milestone: the first known case of a zero-day exploit built entirely with AI. While we successfully disrupted their plans and got the vulnerability patched before launch, it highlights exactly what we are up against.

With AI agents, attacks are accelerating at machine speed. Last year, the handoff time between the first and second stage of an attack was eight hours; today, it takes just 22 seconds.

There’s an old saying in cybersecurity that adversaries only have to be right once, but defenders have to be right every time. That is the attacker’s advantage.

But AI is rewriting those rules, delivering a decisive defender's advantage built on deep context.

The AI Era: Attacker’s Profile vs. Defender’s Advantage

Aspect	Attacker's Profile	Defender's Advantage
Visibility	Limited to outside-in probing; little enterprise context upon entry.	Complete inside-out context; knows exact asset locations, application behavior, and team ownership.
Operational Speed	Executes multi-agent handoffs in 22 seconds.	Machine-speed defense; proactive mitigation in seconds (such as Morgan Stanley's 90-second resolution.)
Core Tactics	Multi-model phishing, deepfakes, AI-built zero-days, and model poisoning.	Closed-loop defense; continuous exposure mapping and accelerated code patching.

The unified blueprint: Google AI Threat Defense

Previously, enterprise context data was fragmented across disconnected security tools. Now, AI empowers defenders to synthesize this rich data into a unified, always-on, autonomous defense.

We built Google AI Threat Defense to combine Google’s security capabilities into a single platform: the advanced reasoning of Gemini, the contextual cloud power of Wiz, the code-level remediation capabilities of CodeMender, and the frontline intelligence of Mandiant.

Our platform transforms vulnerability management across a continuous four-step framework:

Stage	Technology & Actions	Strategic Value to the Enterprise
1. Prepare	Map exposed applications, APIs, identities, and runtime environments using Wiz. Simulate attack paths with the Wiz Red Agent.	Hardens the foundation to reduce internet reachability before vulnerabilities hit production.
2. Scan & Prioritize	Run multi-model scanning — using lighter models for broad coverage and Gemini frontier models for deep-dive analysis of high-risk assets.	Replaces massive alert lists with deep, context-driven risk validation, including an optimal cost per token.
3. Remediate	Deploy CodeMender inside developer IDEs/CLIs to auto-generate verified code fixes.	Replaces slow, manual patching with autonomous code-level remediation and memory-safe migrations.
4. Monitor	Deploy AI agents tied to Wiz to hunt for vulnerabilities and anomalies across network, identity, and application telemetry. Pair with Google Security Operations to rapidly hunt for unknown threats.	Establishes machine-speed runtime detection for zero-day response and threats against unpatchable environments.

To stop vulnerabilities before they hit production, Morgan Stanley partnered with Google Cloud and Wiz, aligning their strategy with the core principles of the AI Threat Defense framework: prepare, scan, remediate, and monitor. By replacing fragmented tools with this unified blueprint, Morgan Stanley collapsed its mean time to detect threats by 99.9%, shifting from a reactive 45-minute window to proactive mitigation in 90 seconds or less.

Google Cloud x Morgan Stanley: Redefining Threat Defense in the AI Era

Maintaining strategic human oversight

While human-speed execution cannot keep pace with automated threats, human management remains essential. We align autonomous AI agents directly with the human teams they support. In Wiz, for example, the Red agent automates penetration testing, the Blue agent drives threat investigations, and the Green agent accelerates cloud remediation.

Every AI conversation is a security conversation. That means securing AI infrastructure requires building from the ground up, and not bolting on.

This ensures autonomy under human supervision, empowering engineering and security teams to eliminate backlogs and secure the software development lifecycle without sacrificing speed.

What’s next: AI-native, agent-driven infrastructure

The foundation of your defender's advantage starts with protecting your environments — not just from outside threats, but from internal risks like shadow AI and unauthorized agents. When employees download models and deploy agents outside of IT oversight, they create silent logic breaches and data-poisoning risks.

The key to countering this is enforcing Zero Trust for AI, and directing teams toward approved architectures with proper governance. Every AI conversation is a security conversation. That means securing AI infrastructure requires building from the ground up, and not bolting on.

At Google, security is not just an added layer; it is our foundation. Our secure-by-default architecture automatically blocks nearly 15 billion unwanted emails and protects billions of users every day.

As the threat landscape matures, outperforming automated adversaries requires a platform built from the ground up to be AI-native and agent-driven.

Fight AI with AI. Learn more about how to secure your software lifecycle with Google AI Threat Defense.

aside_block: <ListValue: [StructValue([('title', 'Learn something new'), ('body', <wagtail.rich_text.RichText object at 0x7f0cdfb22a00>), ('btn_text', 'Watch now'), ('href', 'https://www.youtube.com/watch?v=CmGWIwgHR60'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

In case you missed it

Here are the latest updates, products, services, and resources from our security teams so far this month:

FinOps for SecOps: How to optimize the agentic SOC for value: To be more resilient in AI adoption, CISOs should develop a disciplined "FinOps for SecOps" blueprint that maximizes threat disruption while keeping control over compute costs. Here's how. Read more.
New IDC study: How Mandiant transforms security into a competitive advantage: A new IDC Business Value White Paper found that you save an average of $4.3 million, driving a 268% three-year ROI, with Mandiant Consulting. Read more.
Drive proactive security, prioritize risks with Google Threat Intelligence and Wiz ASM: To help you match your real-world exposures with real-time adversary activity, we’ve begun integrating Google Threat Intelligence with Wiz Attack Surface Management. Read more.
Shift into high gear with agents: Securing the software-defined vehicle: To better support and secure SDVs, Google Cloud and Valtech have partnered to develop Nexus SDV, a highly-scalable, AI-enabled connected vehicle platform. Read more.
Meet the 33 cybersecurity startups joining the Gemini Startup Forum: Our flagship Google for Startups program, Gemini Startup Forum: Cybersecurity, has selected its first 33 trailblazing startups. Read more.
Introducing k8s-aibom on GKE for automated AI bills of materials: We’re open-sourcing k8s-aibom, a Kubernetes controller that continuously monitors environments to detect AI runtimes and generate standard ML-BOMs. Read more.
BGP route policies: Top 3 use cases by customer demand: We detail the three most impactful use cases for Cloud Router BGP route policies that have emerged since 2025. Read more.
Contributing to U.K. financial sector resilience as a critical third party: The U.K. Treasury has designated Google Cloud EMEA as a critical third party (CTP) to the U.K. financial sector under the CTP regime. Here’s how that helps you. Read more.
Google Cloud confirmed to offer a safer choice for EU public sector organizations with Dutch DPIA approval: We understand that for the EU public sector, data protection is a prerequisite. We’re excited to reinforce this commitment with a major milestone. Read more.
Why IaC coverage belongs on your security dashboard: Rethinking infrastructure-as-code coverage as a funnel that shows how much of your infrastructure is governed, traceable, and ready for remediation at speed. Read more.
Inside the ProdSec playbook: Operationalizing Wiz for end-to-end cloud security: Rethinking infrastructure-as-code coverage as a funnel that shows how much of your infrastructure is governed, traceable, and ready for remediation at speed. Read more.
Build AI security agents with Wiz MCP: Power AI-driven security with trusted security context, Wiz AI Agents, and Wiz AI Skills. Read more.

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

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

Threat Intelligence news

A look at the drivers, dynamics, and applications of the pro-Russia influence ecosystem: Four years into Russia’s full-scale invasion of Ukraine, the pro-Russia influence ecosystem has evolved from a tool of war back into a global strategic asset. The interconnected nature of the ecosystem's disparate components makes it resilient to limited scope disruptions, a factor that defenders need to consider to mitigate pro-Russia influence threats. Read more.
Google’s continued disruption of malicious residential proxy networks: In coordination with the FBI, Lumen, and others, Google took action against the NetNut residential proxy network, also known as Popa. This action builds on our disruption of the IPIDEA proxy network that took place in January 2026, and is a continuation of Google’s objective to dismantle malicious residential proxy networks. Read more.
GhostApproval: A trust boundary gap in AI coding assistants: Learn how Wiz uncovered a category-level blind spot in modern AI coding assistants, and why the human-in-the-loop safety model fails against this classic threat. Read more.
The latest addition to Turla’s intelligence gathering apparatus: Google Threat Intelligence Group (GTIG) has conducted an in-depth analysis of a .NET backdoor, tracked as STOCKSTAY, that has been continually developed and deployed by the Russia-linked threat actor Turla, one of the oldest known cyber espionage groups, since at least December 2022. As part of our continued tracking of this group, we’re providing an overview of our STOCKSTAY analysis, a timeline of key developmental and operational observations, and detailed similarities to KAZUAR to contextualize this new capability in Turla’s arsenal. Read more.
Recovering active ADFS signing keys via Machine DPAPI: During a recent red team engagement, Mandiant discovered that when ADFS certificates are manually rotated, configuration drift can silently leave active signing keys exposed in Machine DPAPI. Here’s how to defend against it. Read more.

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

Now hear this: Podcasts from Google Cloud

Cloud Security Podcast: Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM: Dan Lussier, founder, Nano, unpacks how he vibe-coded an entire SIEM from scratch during his end-of-year holiday break. Listen here.
Cloud Security Podcast: Scaling lessons, from leading the NSA to defending the world: Morgan Adamski discusses how public-private partnerships and the shift to cloud infrastructure have transformed cybersecurity defense through improved intelligence sharing and collective trust. Listen here.
Cloud Security Podcast: Closest alligator to the canoe: How transforming the SOC became P0 for Lloyds Bank: Matt Row, chief security officer, Lloyds Bank, explains the bank's digital transformation strategy, highlighting how it modernized its security operations center to achieve a 20x reduction in human-reviewed alerts. Listen here.
Defender’s Advantage: Human-machine teaming and applying AI to frontline threat intelligence workflows: Jake Nicastro, AI lead, Frontline Intelligence Operations, GTIG, details how his team is shifting from simple prompt engineering to more advanced agentic workflows, focusing on a model of human-machine teaming. Listen here.

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

What 10 autonomous film crews taught us about agent teamwork

Thu, 16 Jul 2026 16:00:00 +0000

Can teams of AI agents collaborate to create a short film?

As part of an internal Google generative media hackathon, we put this question to the test – specifically, to uncover whether AI agents could work collaboratively in a domain less innately familiar than software development. We gave each crew three agents with distinct roles and had them collaborate through messages and shared files under their own agent-only hackathon. Agents ran inside Scion, an open source agent orchestration testbed. Unlike code or text, media and composition are less familiar subject matter for AI agents, so this experiment taught us about how agents can collaborate with checks and gates to see projects through to an end.

Ten crews each produced a short film. A separate agent-staffed documentary crew "filmed" the process. That documentary itself became the medaling hackathon submission.

The result? Hundreds of individual agent instances were created over the project. 25+ total productions across pilot rounds and competition. About 44 minutes of delivered film. Human feedback on the output fed back into a continuous improvement loops with the agent generated tooling.

Here are two examples of agent generated short films:

The paper frontier

The printmaker's ghost

Team structure

Each crew had three agents. The Idea Person wrote the script and defined the visual style. The Technical Lead operated the generative media tools. The Editor controlled pacing and final assembly. A team-coach agent supervised gated checkpoints but didn't write or direct.

The Idea Person generated three starter ideas. Then, the team assessed the ideas from their role's POV: would this be generated well with generative media? Would it be complex to edit? Then, they pitched the idea among other teams in the hackathon, so that a team could adjust or pivot. For example, if three teams all picked a sci-fi space battle, then it would not make a good competitive entry.

A Coordinator agent scheduled the competition, running two teams at a time across five waves. The event ran about 21 hours.

The crews followed a seven-step pipeline modeled on the fundamentals of traditional filmmaking: concept, beat sheet, character workshop, storyboard, principal photography, assembly, final render. Each step had a verification gate, ensuring that at least one agent checked another agent's work for technical compliance (such as resolution, or timing).

In an early pilot, one team reported a completed film that turned out to be a 94-byte placeholder file. As it turns out, agents can be convincing about having finished work they haven't done.

While surprising (and sometimes even amusing), we uncovered other ways the agents took the film in their own direction. For example, the agents divided labor on their own in ways we didn't expect. On one team, the Idea Person wrote a line of prose in the first draft. The Editor, independently, built an eight-second silence gap around that line and marked it "NON-NEGOTIABLE" in the timeline. The Tech Lead regenerated a single shot repeatedly until a flower separated from a bouquet at the right frame. None of them coordinated this. They read the shared files and made independent editorial judgments.

This process around teamwork and tool use was co-developed with agents during the pilot-phase. During this phase, agent teams created videos which received human feedback, such as audio collisions and levels, inconsistent characters, hard to follow story or narration.

This feedback, combined with agent-authored retrospectives for each pilot was used to restructure not only the playbook and guides that instructed future teams through the process, but the agents also built and revised a custom media toolchain that combined golang CLIs with python batch automation.

The generative media models

Each film combined multiple Google AI models. The agents called them through a shared CLI toolkit called genmedia:

Gemini image generation (Nano Banana) produced character reference sheets, storyboard frames, and scene compositions. The agents kept characters visually consistent across a film through reference chaining: they generated headshots first, then used those as input for body sheets, then used body sheets as input for scene tests. Each generation call included these accumulated references as anchors.

Veo 3.1 generated the video. Clips run four to eight seconds at 720p. The agents chose different generation modes depending on the shot: text-to-video for simple compositions, image-to-video for shots anchored to storyboard frames, frame interpolation when they needed a precise start and end frame. For shots longer than eight seconds, they fed the last frame of one clip as the first frame of the next.

Veo 3.1 also generates audio inside each clip: ambient sound, room tone, and lip-synced character dialogue. One team (Lambda) built their film around this capability. They structured the script like a musical score with movement markings (Allegretto, Accelerando, Adagio) because the sync between generated speech and lip movement gave pauses real weight.

Lyria 3 generated original music. One editor composed a three-movement jazz score before any video was shot and used it as the master clock for the production. Teams also coerced Lyria into producing sound effects by framing prompts as "soundscapes."

Gemini Flash TTS generated character voices and narration from named voice personas with style direction ("world-weary narrator, slow measured pace"). TTS pacing was hard to predict. One team's narrator delivered at 108 words per minute instead of the planned 130, blowing out the runtime by a full minute. A different team had a similar problem but decided the slow pace fit their character, a 68-year-old projectionist.

A four-minute film required 40+ image generations, 25+ video clips, several music stems, a dozen voice recordings, and hundreds of assembly operations.

Scion: The orchestration system

The agents ran on Scion, an open-source multi-agent orchestration testbed. Scion defines agents from templates (persona, instructions, skills, tools), runs them in containerized sandboxes, lets agents spawn and message other agents through a shared CLI, wakes agents through event-driven notifications, and gives all agents in a project access to a shared filesystem.

Messages and notifications allowed collaboration around a shared workflow. At different points in the process, different agents brought their focused contribution to that stage. Fundamentally this allowed for "sharding" the complex process across multiple context windows. Some of these were long lived, some short lived. Combinations of different models and harnesses were used as Scion is model and harness agnostic. The same agent template runs on Claude, Gemini, or Codex.

The shared filesystem provided resilience. Agents crash, run out of context window, and get restarted by the system. The files they write persist. When one team's editor crashed during final assembly, the Tech Lead opened the editor's timeline plan, read it, and finished the job. The coordinator restarted the documentary producer agent multiple times across the project. Each new instance read the previous one's files and continued.

Some of what we learned

Agents collaborate better through files than through messages. Teams that wrote down their decisions (which visual keywords go in prompts, where shots sit on the timeline, what instruments to ban from the score) recovered from crashes without losing direction. Teams that kept decisions in message history lost them when agents restarted. The effective combination was to pass messages containing file-paths.

Choosing styles that match AI generation strengths produces better films. Teams chose claymation because its wobble made temporal drift invisible. They chose silhouette animation because it sidestepped facial consistency problems. One team couldn't generate a kiss because a safety filter blocked it. They showed two shadows merging on a wall instead. Their coach called it the strongest shot in the film.

Specific prompts beat general direction. The default output from video generation is moody cinematic noir. The teams that made distinctive work specified hex color codes rather than color names, listed banned instruments, and wrote negative prompts ruling out unwanted aesthetics. "Make it warm" produced generic results. "#F4A261, no string instruments, no lens flare" did not.

A coach role at verification gates changed outcomes. The coach could observe the full production but could only intervene at step boundaries. That constraint forced coaches to judge finished outputs rather than micromanage the process. One coach described the dynamic: "It's a room full of specialists who can each do one thing at superhuman speed, but none of them can taste the soup."

Learn more

You can see the full documentary here, and learn more about the Scion Framework, and how it was used in the hackathon.

Bridging the gap between SQL and Python with BigQuery and the %%bqsql magic

Thu, 16 Jul 2026 16:00:00 +0000

Data scientists and data engineers often find themselves caught between two worlds: SQL and Python. Some find SQL more intuitive, especially when combined with a powerful engine like BigQuery to process data at scale. Others find it easier to work in Python with its rich ecosystem of libraries and runtimes. Historically, using these languages together in one notebook required moving data from SQL results to in-memory and writing from Python memory to temporary tables for SQL to access.

To solve this friction, the Google Cloud team introduced SQL cells in Colab Enterprise. Now, we are expanding that seamless experience to the broader open-source ecosystem. With the %%bqsql IPython cell magic, you can now effortlessly chain data processing workloads across SQL and Python code cells.

Thanks to open-source packages like Jupyter, pandas, BigFrames, and the BigQuery sandbox, you can follow all steps in this guide for free* and without a credit card.

*See the BigQuery sandbox documentation for limitations.

Setting up your environment

To get started,

1. Enable the BigQuery sandbox. Make note of your Google Cloud project ID.

2. Set up a local Python development environment, or alternatively, open this notebook in Colab, which has a Python environment already installed.

To set up a local python environment, see the steps on Google Cloud Documentation. Continue with the following steps, if you choose to set up a local python environment, else jump to the next section.

3. Activate the venv you created in the previous step to isolate Python dependencies.

On Linux or macOS, use these commands (update to your preferred Python version):

code_block: <ListValue: [StructValue([('code', '. ./env/bin/activate'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f130>)])]>

4. Install the Jupyter, bigframes, and python-calamine packages.

code_block: <ListValue: [StructValue([('code', 'pip install --upgrade jupyterlab bigframes python-calamine'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f8e0>)])]>

5. Start Jupyter Lab.

code_block: <ListValue: [StructValue([('code', 'jupyter lab'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f970>)])]>

6. Open a web browser to the URL listed in the output. It will be something like http://localhost:8888/lab?token=somesupersecretvaluehere .

7. Create a new notebook using the Jupyter Lab UI (File > New > Notebook). Alternatively, download the notebook associated with this tutorial from the BigQuery DataFrames GitHub repository and open it.

Accessing and preparing local data

In this tutorial, you'll analyze the USDA wheat data. Pandas will download the data, mimicking a typical local data analysis workflow.

code_block: <ListValue: [StructValue([('code', 'url = "https://www.ers.usda.gov/media/5706/wheat-data-all-years.xlsx?v=52690"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fee0>)])]>

Next, read the data into a local pandas DataFrame. Use the pyarrow dtype_backend when preparing local pandas data for SQL processing. This ensures more consistent handling of NULL values and seamless schema mapping when you hand off the data to the BigQuery SQL engine. For this example, read the 'Table05' sheet, which contains annual wheat supply and disappearance data:

code_block: <ListValue: [StructValue([('code', 'import pandas as pd\r\n\r\ndf = pd.read_excel(\r\n url,\r\n sheet_name="Table05",\r\n dtype_backend="pyarrow",\r\n engine="calamine",\r\n header=1, # Skip the first row.\r\n)\r\ndf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f730>)])]>

Before querying the local DataFrame with SQL, ensure that the column names are SQL-friendly. BigQuery supports flexible column names, allowing most unicode characters, but special characters like "/" and "" must be removed or replaced.

code_block: <ListValue: [StructValue([('code', 'df.columns = [name.replace("/", "") for name in df.columns]\r\ndf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8ff70>)])]>

Perform a basic filter using standard Python/pandas syntax to remove rows with missing data. This represents the initial Python-only stage of a processing chain.

code_block: <ListValue: [StructValue([('code', "full_rows = df[~df['Beginning stocks'].isna()]\r\nfull_rows"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fd90>)])]>

Initializing the BigQuery SQL magic

The BigQuery DataFrames library provides the %%bqsql magic, which acts as the bridge between your Python and SQL environments. It allows the BigQuery query engine to directly reference and query your local pandas DataFrames (by implicitly uploading them as temporary tables) as well as actual BigQuery tables and external tables in GCS (Parquet, Iceberg, CSV).

To enable this integration in your notebook, load the bigframes extension.

code_block: <ListValue: [StructValue([('code', '%load_ext bigframes'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f790>)])]>

Note: The extension is pre-loaded in BigQuery Studio and Colab environments.

To ensure the correct Google Cloud project is billed for query usage, including free tier usage, configure the project ID used by the magics. Even in the free sandbox tier, a project ID is required to allocate query resources. If you don't set it explicitly, BigFrames will try to discover it from your environment (e.g., your Application Default Credentials).

code_block: <ListValue: [StructValue([('code', 'import bigframes.pandas as bpd\r\n\r\nbpd.options.bigquery.project = "your-project-id-here"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fdc0>)])]>

Querying local pandas DataFrames with SQL

With the project configured, you can now run SQL queries directly against your local pandas DataFrame (full_rows) as if it were a table in BigQuery. Simply reference the variable name inside braces {full_rows} in your SQL query. You may be prompted for an authorization code, which you'll obtain by following the link provided as part of the same message.

code_block: <ListValue: [StructValue([('code', '%%bqsql\r\nSELECT * FROM {full_rows}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fc70>)])]>

Chaining SQL and Python: Saving SQL Results

The true power of the %%bqsql magic lies in chaining. By providing a destination variable name as an argument to %%bqsql (e.g., %%bqsql destination_var), the query result is saved as a BigQuery DataFrame to that variable.

This DataFrame lives on the BigQuery engine but behaves like a pandas DataFrame in Python. You can immediately use it in subsequent Python cells, or reference it again in another SQL cell. This allows you to build a multi-step, hybrid processing pipeline.

Filter the data to only yearly entries using SQL, and save the result into a new BigFrames DataFrame named yearly:

code_block: <ListValue: [StructValue([('code', "%%bqsql yearly\r\nSELECT *\r\nFROM {full_rows}\r\nWHERE STARTS_WITH(`Time period`, 'MY')"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fb80>)])]>

Now, you can chain another SQL operation. Reference the yearly BigFrames DataFrame that you just created, extract the year using SQL regular expressions, cast it to a timestamp, and save the results into a new BigFrames DataFrame named timeseries.

code_block: <ListValue: [StructValue([('code', "%%bqsql timeseries\r\nSELECT\r\n * EXCEPT (`Marketing year 1`),\r\n TIMESTAMP(CONCAT(\r\n REGEXP_EXTRACT(`Marketing year 1`, r'([0-9]+)\\/'),\r\n '-01-01')) AS `year`\r\nFROM {yearly}"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fa30>)])]>

Notice how you are building a chain from Python to SQL and back again.

Returning to Python for visualization

Now that you've completed some SQL transformations, you can chain back to Python for visualization. Because BigFrames DataFrames implement the pandas API, you can call standard visualization methods (like .plot.line()) directly on the timeseries DataFrame without downloading the full dataset first. The computations happen in BigQuery, and only the summarized chart data is sent back to the notebook.

code_block: <ListValue: [StructValue([('code', "timeseries.set_index('year').sort_index().plot.line()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f310>)])]>

Alternatively, download the time series as a pandas DataFrame to use with your visualization library of choice.

code_block: <ListValue: [StructValue([('code', "pddf = timeseries.set_index('year').sort_index().to_pandas()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f190>)])]>

Why a hybrid pipeline matters

By pairing BigQuery DataFrames with %%bqsql magics, you have built a powerful, interoperable pipeline that seamlessly transitions between SQL and Python.

local pandas df and full_rows DataFrames
to SQL filter
to BigFrames yearly DataFrame
to SQL transform
to BigFrames timeseries DataFrame
to Python data visualization
to local pandas DataFrame.

This architecture offers key advantages:

Optimal tool selection: Use SQL for what it does best (heavy aggregations, window functions, and complex joins) and Python for what it does best (visualization, statistical modeling, and ML orchestration).
Improved code readability: Instead of writing massive SQL queries with dozens of common table expressions (CTEs), or doing complex aggregations using pandas APIs which are often convoluted compared to SQL, you can split your pipeline into logical steps, alternating between SQL and Python.
Seamless scaling: The exact same %%bqsql code can scale from a tiny local pandas DataFrame to billions of rows in a production BigQuery table. You only need to swap the initial local pandas DataFrame with a BigQuery DataFrame reference.

Next steps and scaling up

Check out the other notebooks in the BigFrames API reference site. In addition to the %%bqsql cell magic, BigFrames also registers a BigQuery Accessor on standard pandas DataFrames, allowing you to run SQL scalar functions directly on local pandas data.

For example, you can call powerful Google Cloud community UDFs from BigQuery Utils, BigFunctions, or CARTO Analytics Toolbox for BigQuery using df.bigquery.sql_scalar(...):

code_block: <ListValue: [StructValue([('code', 'import pandas as pd\r\nimport bigframes.pandas as bpd # Registers the accessor\r\n\r\nbpd.options.bigquery.project = "your-project-id"\r\ndf = pd.DataFrame({"x": [1, 2, 3]})\r\npandas_s = df.bigquery.sql_scalar("`bqutil`.fn.cw_setbit({x}, 2)")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8f100>)])]>

While the BigQuery sandbox offers a powerful environment to test these hybrid Python-SQL workflows for free, some advanced features like BigQuery Machine Learning (BQML) are restricted. By connecting a billing account to your Google Cloud project, you can unlock advanced capabilities such as the bigframes.bigquery.ai.forecast function to predict time-series data using Google's state-of-the-art foundational models directly from your SQL/Python chain.

code_block: <ListValue: [StructValue([('code', 'forecasted_pandas_df = (\r\n pddf\r\n .reset_index(drop=False)\r\n .bigquery.ai.forecast(\r\n data_col="Production",\r\n timestamp_col="year",\r\n horizon=10,\r\n )\r\n)\r\n\r\n# Plot the results\r\nforecasted_pandas_df_sorted = forecasted_pandas_df.sort_values(by=\'forecast_timestamp\')\r\nplt.plot(pddf.index, pddf[\'Production\'], label=\'Real Production\', color=\'blue\')\r\nplt.plot(forecasted_pandas_df_sorted[\'forecast_timestamp\'], forecasted_pandas_df_sorted[\'forecast_value\'], label=\'Forecasted Production\', color=\'red\', linestyle=\'--\')\r\nplt.fill_between(\r\n forecasted_pandas_df_sorted[\'forecast_timestamp\'],\r\n forecasted_pandas_df_sorted[\'prediction_interval_lower_bound\'],\r\n forecasted_pandas_df_sorted[\'prediction_interval_upper_bound\'],\r\n color=\'red\',\r\n alpha=0.2,\r\n label=\'Confidence Interval\'\r\n)\r\n# ...\r\nplt.show()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdef8fe80>)])]>

The BigFrames team would love to hear your feedback on the hybrid Python-SQL experience:

Email: bigframes-feedback@google.com
Issues: File bug reports or feature requests on the open-source BigFrames repository.
Updates: To receive news and updates, subscribe to the BigFrames email list.
Learn more: Read the BigFrames API reference and user guides in the documentation.

Three lessons in accelerating foundation model upgrades

Thu, 16 Jul 2026 16:00:00 +0000

Have you run into problems migrating your products from one model to the next?

Upgrading to the latest AI models is rarely simple. For engineering teams, model updates whether migrating to an entirely new model or updating to a newer checkpoint within the same model family, like moving from an earlier Gemini version to Gemini 3.5 — often require a slow and costly process of testing, proving quality, and manually evaluating new responses. For most engineering teams, upgrading to a new model checkpoint means months of manual toil to verify performance. And the industry is moving at breakneck pace – since 2023, we’ve announced six major model evolutions, bringing us to Gemini 3.5 today.

Our team at Google Cloud, Applied ML, has a goal to deliver transformative infrastructure and services that benefit both Google and our customers globally. As part of that, our team built an agentic workflow that completes model upgrades in hours instead of months.

In this blog, we’ll show you our approach and three lessons you can apply to accelerate your own foundation model upgrades using Gemini Enterprise Agent Platform — our new, comprehensive platform to build, scale, govern, and optimize agents – and Google Antigravity, our primary solution for developers using AI for coding and agent orchestration.

Three lessons in building a flexible agent system

To support different team needs, we had to rethink traditional automation and learned three key lessons along the way:

Lesson 1: Start with hands-on discovery. First, our engineers worked closely with product teams on real migration problems. This hands-on work helped us identify complex requirements and build our first guidelines for prompt optimization.
Lesson 2: Beware the rigidity of traditional automation. We turned these guidelines into a standard, automated workflow. While this version gave us some quick wins, we soon found that traditional automation was too rigid to handle different data formats and unique edge cases.
Lesson 3: Pivot to a flexible agent architecture. The real progress came when we rebuilt the tool using a flexible agent. Instead of forcing teams into a rigid process, the agent adapted to specific project needs, helping analyze data and test prompts dynamically with a high degree of adaptability.

How our partner teams cut migration time while boosting quality

Our partner team, which manages video translation and dubbing services, had an interesting challenge: their workflow required rewriting translated text so that the spoken duration matched the original video's pacing exactly, without altering the meaning. Historically, this strict constraint required maintaining a fine-tuned model. Their goal was to migrate to the latest out-of-the-box foundation model, guided purely by prompt engineering.

Using this agentic framework, the team provided their ground-truth dataset and baseline prompt. The system autonomously hill-climbed the prompt quality, migrating the service away from the custom stack

Make your own migration workflow with Agent Platform and Google Antigravity

These learnings can be applied by any engineering team looking to accelerate their own model upgrades. If your organization is struggling to keep pace with new foundational models, replacing manual toil with intelligent automation requires treating migration as an agentic workflow.

To build your own automated migration pipeline, follow these steps:

Deploy Autoraters: Pivot from manual human review to model-based Autoraters to evaluate the quality of a new checkpoint at scale and in a fraction of the time.
Build an agentic loop: You can use the Agent Development Kit within Gemini Enterprise Agent Platform to create your agent.
Automate the orchestration: To make the process even easier, leverage Antigravity to automate the underlying coding and agent orchestration and add in features such as loss reporting or headroom reports.

By shifting away from a manual, line-by-line engineering task, organizations can reduce infrastructural tech debt and confidently keep pace with the frontier of AI.

_{This work is the result of collaboration across Google. We thank key contributors: Anthony Green, Chris Lamb, Chungyen Li, Connie Huang, Elaine Han, Elena Erbiceanu Tener, Eugene Ie, Francesca Ciacchella, Igor Karpov, Jeanie Jung, Jose Menendez, Kiam Choo, Lina Sanders-Self, Longfei Shen, Martin Nikoltchev, Mason Ng, Matt Mancini, Paul Zhou, Pedram Oskouie, Samuel Smith, Tom Lawrie, Ye Tian, Zhen Lin}

Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management

Thu, 16 Jul 2026 14:00:00 +0000

Written by: Jules Czarniak

Introduction

As highlighted in the Mandiant M-Trends 2026 report, the mean time-to-exploit (TTE) has dropped to -7 days, meaning vulnerabilities are often exploited a week before a patch even exists.

To keep pace, many security teams are exploring how to integrate large language model (LLM) agents into their codebases, development environments and continuous integration and continuous delivery (CI/CD) pipelines for automated vulnerability discovery and remediation. However, deploying privileged artificial intelligence (AI) agents without mature integration processes introduces new architectural risks.

In response to customer inquiries about how to safely integrate AI capabilities into vulnerability management workflows, this blog provides actionable guidance from Mandiant Consulting about how to establish operational guardrails for AI assisted vulnerability management, including several detailed scenarios. What each of these examples show is that security teams can accelerate workflows with AI while also upholding the structural integrity of their environments. We suggest that combining AI capabilities with deterministic controls and human intelligence in strategic ways maximizes benefits and reduces risk.

Establish Operational Guardrails to Safely Deploy AI Agents

To safely adopt advanced AI capabilities without introducing unpredictable failures into deployment pipelines, organizations should ground their approach in established industry standards. While guidelines like the NIST AI Risk Management Framework (RMF) and the OWASP Top 10 for LLMs provide comprehensive baselines for identifying risks, operationalizing these controls requires a structural blueprint.

Frameworks like Google’s Secure AI Framework (SAIF) and Google’s approach to secure AI Agents provide a practical path forward, demanding that organizations extend existing deterministic controls directly into the AI execution environment. When deploying AI agents, security teams should navigate specific operational and structural risks:

Pre-agent data security and Defense-in-Depth: Agents should not be able to access personally identifiable information (PII), protected health information (PHI), or other sensitive data. Organizations should enforce data security before the prompt reaches the model. This includes strictly using non-production environments populated with synthetic data for testing. For production, security teams should deploy a hybrid defense-in-depth model. This includes Layer 1 deterministic policy engines acting as chokepoints, alongside Layer 2 reasoning-based defenses like specialized guard models (such as Model Armor or similar provider-agnostic guardrails) to filter out sensitive data and block malicious prompt injections before they reach the agent layer. Crucially for vulnerability discovery, security teams should treat the codebase itself as an untrusted input. Threat actors can embed indirect prompt injections within source code comments or third-party dependencies (e.g., hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables), making input sanitation a requirement even for internal scanning.
Cloud provider limitations and zero data retention (ZDR): Many cloud and LLM providers block or throttle automated offensive security probing by default to prevent abuse. Organizations should establish clear rules of engagement and authorized testing agreements to navigate acceptable use policies. Furthermore, organizations should enforce strict zero data retention (ZDR) agreements with their LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models.
Workload isolation: Agent workloads should execute in strictly isolated, unprivileged containers with dynamically limited privileges. By relying on robust sandboxing to prevent privilege escalation, if an agent hallucinates a destructive command or is hijacked via prompt injection, the blast radius remains contained.
Red Teaming: Before deploying autonomous vulnerability scanners that can dynamically spin up sandboxes and execute code, organizations should subject the AI agents themselves to human-led red teaming as part of comprehensive assurance efforts. This validates the agent's resilience against jailbreaks, recursive logic loops, and complex prompt injections, ensuring the security tooling does not become the attack vector.
Least-Privileged Machine Identities and Human Controllers: While workloads should be isolated, agents inherently require privileges to generate pull requests and commit code. Security teams should ensure these agents operate under distinct, strictly scoped machine identities that tie back to human controllers to ensure accountability and user consent. Organizations should use short-lived, just-in-time (JIT) tokens bound exclusively to the specific repository and branch under review. This enforces the principle of limited agent powers and ensures that even if an agent’s container is compromised via prompt injection, the threat actor cannot pivot to modify adjacent enterprise codebases.
Supply chain resilience for skills: As developers augment AI with third-party skills and model context protocol (MCP) servers, security teams should treat these integrations as untrusted supply chain components. MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies. Additionally, security teams should evaluate the underlying agent orchestration frameworks themselves (e.g., LangChain, AutoGen) for inherent vulnerabilities, such as session memory poisoning or recursive loop hijacking.
Toxic flow analysis (TFA) and Observable Actions: The objective of TFA is to monitor data paths at runtime, ensuring agents do not exfiltrate sensitive internal context to unvetted external endpoints. Agent actions, inputs, reasoning, and outputs must be fully observable and transparently logged. While implementing dynamic taint tracking for LLMs remains a complex architectural challenge, organizations should clearly separate this runtime observability from static supply chain controls. Integrating threat intelligence to hash and vet incoming agent tools provides a necessary baseline for verifying integrity before deployment. However, because static controls cannot address behavior post-deployment, mitigating data exfiltration ultimately requires active runtime monitoring and secure, centralized logging to trace and restrict the actual flow of data.

Figure 1: Visual representation of an isolated AI agent environment using SAIF mechanisms

By operationalizing these tools within frameworks that demand verifiable integrity and structural resilience, organizations can safely bridge the gap between AI velocity and enterprise defense.

The need for human-led threat modeling

While LLMs excel at identifying syntax patterns, source code itself rarely contains the full picture of unwritten business intent. Some organizations attempt to solve this by connecting LLM agents to internal wikis, design documents, and issue trackers using retrieval-augmented generation (RAG).

While RAG gives the model access to external business context, it is not a perfect fix. Corporate documentation is frequently stale, contradictory, or incomplete. An AI agent might retrieve an outdated architecture diagram and confidently hallucinate a secure path that no longer exists in production. Because LLM agents struggle to resolve conflicting, undocumented human assumptions, human-led threat modeling remains a critical security control across both legacy applications and modern agent workflows.

Security teams should apply threat modeling during both the pre-build system design phase to establish a secure foundation, and during post-build architecture reviews. While an AI agent might successfully identify a poorly configured internal endpoint locally, a human threat modeler asks the structural question: why does that microservice possess broad database read permissions in the first place?

Identifying architectural vulnerabilities requires reasoning about business risk, data sensitivity, and operational constraints. To structure this process, organizations can use industry frameworks like PASTA (Process for Attack Simulation and Threat Analysis) or service offerings like the Mandiant Threat Modeling Security Service to map trust boundaries, uncover structural design flaws, and prioritize compensating controls. Securing fundamental architecture through human oversight is a necessary component when relying on automated agents to find bugs in a poorly designed system.

Once these AI agents are safely sandboxed, as guided by SAIF, and the architecture is verified through threat modeling, organizations can typically apply them to two different problem spaces: Enterprise Vulnerability Management (to assist in managing the volume of known CVEs in commercial off-the-shelf (COTS) software and infrastructure) and Product Security (to identify vulnerabilities in 1st-party (1P) code).

Track 1: Enterprise Vulnerability Management

Foundational security and discovery

While the second track of this post explores how AI agents can uncover complex zero-days in custom code, organizations should manage the scale of enterprise infrastructure in tandem with these AI deployments. Even as new AI capabilities dominate headlines, organizations should still address foundational security challenges, such as secrets sprawl, unmanaged service accounts, missing FIDO2 MFA, and legacy VPN concentrators. Although vulnerability exploitation was the primary initial infection vector in intrusions Mandiant investigated last year, threat actors consistently rely on missing foundational controls and unpatched edge devices to secure and escalate their foothold after exploiting a vulnerability.

Furthermore, AI cannot replace foundational visibility. As security teams deploy AI agents, they should simultaneously close these tactical entry points by maximizing dynamic discovery capabilities like External Attack Surface Management (EASM), Cloud Security Posture Management (CSPM), and Continuous Threat Exposure Management (CTEM). In hybrid and cloud environments, tools like Wiz can be used to map this initial footprint.

Risk-based vulnerability management

Vulnerability management teams are already overwhelmed by the current volume of findings generated by traditional scanners. As organizations scale dynamic discovery tools, such as EASM, CSPM and CTEM, alongside automated AI agents, this influx of findings will compound the problem. To manage this influx, telemetry from these diverse discovery methods must first be normalized and deduplicated. This normalized data serves two purposes: it feeds directly into the risk engine, and it acts as a live overlay to correct stale records in the configuration management database (CMDB). By evaluating the deduplicated vulnerabilities alongside this newly updated asset context and frontline threat intelligence, the RBVM engine calculates a custom risk score that allows security teams to dynamically prioritize remediation.

A mature RBVM methodology calculates a customized risk score on a 0 to 100 scale using a weighted average. A sample formula for calculating this risk-based score is:

Final Score = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)

The variables and weights (W) are customized to the organization's risk appetite (for example, 0.20 for vulnerability, 0.40 for asset, and 0.40 for threat, summing to 1.0), while the underlying variables (S) are scored on a 0 to 100 scale and defined as follows:

Vulnerability severity (S_vuln): The inherent technical severity of the flaw. This is calculated by taking the CVSS Base Score (which natively accounts for confidentiality, integrity, and availability impact) and multiplying it by 10.
Asset context (S_asset): A combined metric of exposure and data sensitivity. Scores range from 100 for internet-facing assets holding customer data, down to 25 for internal-only assets with no sensitive data. To translate this impact into monetary terms for non-technical stakeholders, organizations can incorporate Factor Analysis of Information Risk (FAIR) principles into this metric. However, this approach requires highly accurate, continuously updated financial data that many enterprises struggle to maintain at scale.
Threat context (S_threat): The real-world urgency of the vulnerability. Scores range from 100 if actively exploited by threat actors relevant to the organization's profile, 75 if a proof-of-concept exists or if it is a vulnerability class easily exploited by autonomous AI agents, down to 25 if the exploit is theoretical and highly complex. Organizations should also map the Exploit Prediction Scoring System (EPSS) probability percentage directly into this variable. This allows the threat score to automatically scale up or down as real-world exploitation telemetry shifts, aligning static vulnerability data with active threat intelligence.

An asset's customized risk score should directly influence internal remediation service-level agreements (SLAs), unless external compliance-driven mandates, such as CISA Binding Operational Directives (BODs), or relevant equivalents, override internal prioritization. A risk-driven and threat-intelligence-driven vulnerability prioritization methodology will help organizations focus resources on managing and mitigating the most critical security vulnerabilities first. This is an area where LLMs can support the vulnerability management process, particularly by helping teams synthesize unstructured threat intelligence to surface relevant risk contexts more efficiently. Enforcing strict SLOs for patching, while requiring formal risk acceptance documentation for any patching exceptions, will help reduce the number of vulnerabilities available to threat actors and increase the visibility of outstanding risks across the organization. Furthermore, organizations should integrate RBVM data directly into their security orchestration, automation, and response (SOAR) platforms for automated alert enrichment.

Figure 2: Integration points of a risk-based vulnerability management (RBVM) program.

Containment and Observability

Modern architecture blueprints must prioritize attack surface reduction under the assumption that vulnerabilities will inevitably be exploited. Moving away from traditional perimeter defenses, organizations should align with zero trust principles, ensuring that security boundaries are established around every asset, workload, and identity.

A component of this alignment is the implementation of strong authentication principles. Organizations should eliminate implicit trust by enforcing continuous, context-aware authentication and authorization. Utilizing Zero Trust Network Access (ZTNA) solutions, such as Identity-Aware Proxies (IAP), shields critical management interfaces (e.g., SSH, RDP) and internal systems from direct internet exposure, granting access only to verified identities and compliant devices.

For public-facing applications and APIs, attack surface reduction involves deploying Layer 7 inspection at the load balancer or API gateway level. This hardening layer enforces strict schema validation, intercepting and neutralizing malformed inbound traffic and potential exploits before they can interact with internal application logic.

Securing the software supply chain is equally vital in modern blueprints, and organizations should align with frameworks like Supply-chain Levels for Software Artifacts (SLSA) across both dependency and build tracks. Security policies should mandate that third-party dependencies are routed through a centralized artifact repository equipped with automated curation services, such as Google Assured Open Source Software (OSS) or an equivalent solution, preventing untrusted code from entering the development lifecycle. Furthermore, maturing toward advanced SLSA build levels (e.g., SLSA level 3) through the implementation of isolation, ephemerality and reproducibility requirements via ephemeral compute infrastructure for CI/CD runners reduces the likelihood of attacker persistence by ensuring environments are short-lived and automatically cycled.

To complement these pre-build controls, runtime observability should be established across all production workloads. This requires monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production, which surfaces true exploitable risk far beyond a static Software Bill of Materials. In tandem with monitoring workloads, organizations should secure how they authenticate by implementing workload identity federation. By removing static credentials and instead using short-lived tokens backed by strong cryptographic identity verification, organizations can reduce the risk of credential theft and unauthorized lateral movement.

Within the internal environment, microsegmentation should be enforced to break down flat networks into granular security zones. Routing application traffic through a Secure Access Service Edge (SASE) architecture integrates network routing directly with robust identity controls, rendering internal services completely invisible to unauthenticated users and containing threats to their initial point of entry.

Finally, automated containment and incident response within a zero trust framework must rely on deterministic, auditable tooling. Endpoint detection and response (EDR) platforms and SOAR playbooks should handle high-fidelity containment tasks through hardcoded execution logic. While AI tools accelerate triage and policy recommendation, actual execution capabilities must remain restricted to well-defined, pre-tested workflows to maintain total architectural predictability.

Figure 3: Structural containment and observability architecture

Track 2: Product Security & Development (1P Code)

Deterministic and probabilistic tooling

Integrating LLM agents into vulnerability management and security workflows requires recognizing the differences between deterministic and probabilistic tooling. Traditional SAST and DAST tools utilize fixed methodologies to evaluate vulnerabilities through structural code parsing or definitive runtime observations. LLMs, however, evaluate source code by processing tokens simultaneously to calculate statistical and semantic relationships, rather than tracing deterministic execution tracks.

While techniques like Chain of Thought (CoT) prompting allow models to bridge this gap by decomposing complex code paths into intermediate reasoning steps, this process remains bounded by architectural limitations. Even when a model possesses a context window large enough to ingest entire repositories, it may experience attention degradation across long inputs, often failing to correctly weight intervening validation or sanitization logic within the prompt. For example, if a variable is tainted on line 10 but sanitized on line 500, attention degradation can cause the model to lose track of the sanitization logic. Furthermore, when enterprise codebases require chunking to fit within context limits, the resulting fragmentation may cause the model to lose track of end-to-end data flows.

Consequently, probabilistic engines are effective at uncovering localized, static anomalies, such as hardcoded credentials or outdated dependencies, but frequently misjudge complex vulnerabilities split across fragmented chunks or extended context windows. Notable exceptions occur when these probabilistic models are coupled with deterministic feedback loops. For instance, when analyzing C++ memory corruption, an LLM can be equipped with a test harness to iteratively execute code and definitively prove a crash. While these dynamic validation applications are detailed in subsequent sections, the baseline limitation for static analysis across standard enterprise codebases remains: models struggle to consistently evaluate dispersed logic.

Figure 4: Deterministic SAST scanners vs. probabilistic LLMs

Binary and architectural oracles

Many security programs are moving toward agent workflows where an agent autonomously spins up a test environment and uses tools to execute payloads and verify its findings. This is a promising approach, but it is important to understand where it is most effective.

Agent workflows perform well against bug classes with binary and observable oracles, meaning the system provides an objective, 'crash or no crash' feedback loop. For example, if a model is hunting for memory corruption in a C++ kernel, a successful exploit is undeniable: the payload executes, and a resulting crash definitively proves the vulnerability. This explains why the industry is currently seeing a surge in AI-discovered vulnerabilities across memory-unsafe targets like web browsers and operating systems.

However, enterprise software is heavily dominated by vulnerabilities that require architectural oracles for validation. Vulnerabilities like authorization bypasses, complex business logic flaws, and indirect server-side request forgeries require an understanding of business context and cross-service trust boundaries. If an agent's payload fails to produce a clear outcome, it can't reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly. An agent's malformed payload might even crash an unrelated background process and cause the model to hallucinate a success and report a false confirmation. Complex enterprise architecture contains unwritten business intent that a probabilistic engine can't inherently know.

Figure 5: Evaluating vulnerabilities against binary vs. architectural oracles

Targeted deployment and human impact

Organizations adopting LLMs for vulnerability discovery face a massive staffing challenge. LLMs can generate findings significantly faster than human engineers can triage them. If every LLM-generated alert requires manual review, security teams will quickly face burnout and/or suffer alarm fatigue.

Rather than indiscriminately pointing agents at all available codebases and risking an influx of unverified output, security teams need a selective deployment strategy. Mature programs should maintain SAST and DAST for baseline hygiene and deterministic rule enforcement, and reserve intensive agent audits for high-impact components with clear binary oracles.

Organizations can prioritize agent audits on systems where the technology's strengths align with the broader risk profile:

Memory-unsafe codebases: Legacy or high-performance components written in memory-unsafe languages such as C, C++, or Assembly are strong candidates for LLM audits. These languages are susceptible to memory corruption flaws, such as buffer overflows and use-after-free conditions. Because these vulnerabilities trigger definitive failure states like segmentation faults, they work well with automated sandboxes where agents can compile the code with memory sanitizers and write proof-of-concept inputs. This approach is also effective for auditing the native extensions where safe languages call unsafe internal libraries, such as Python C extensions or the Java Native Interface (JNI).
Systems highly exposed to outside content: First-party data ingestion pipelines, custom API gateways, or proprietary edge proxies. A prerequisite here is direct access to the source code, this strategy is strictly for internally developed or fully open-source codebases where the organization can inspect the logic. Because these systems directly parse untrusted internet traffic, targeting their source code for LLM-driven audits yields the highest risk-reduction ROI.
Shared internal libraries and utilities: Core serialization/deserialization packages, common utility functions, and custom middleware wrappers (such as internal message-queue parsers) maintained in-house. Because the enterprise owns the source code for these shared building blocks, agent tools can easily hook into them within automated test harnesses to fuzz inputs and catch low-level logic or parsing bugs with high fidelity.
Foundational security boundaries: Internally developed centralized authentication services, custom OAuth providers, and internal credential brokers. While testing complex identity boundaries generates higher logic-based noise, having full access to the source code allows teams to pair agents with deterministic checks to safely triage findings, given that the blast radius of an authentication failure justifies the human effort.

To filter the noise generated by LLMs, organizations should establish routing rules. Require the agent to generate a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit. This harness must execute automatically in an isolated, monitored sandbox. If the sandbox execution fails (due to a syntax error or a failed exploit), the ticket is discarded, sparing human resources. However, organizations should enforce execution timeouts and iteration limits on these test harnesses. Without hard limits, an autonomous agent attempting to prove a vulnerability can fall into an infinite loop: writing a script, failing, rewriting, and failing again, exhausting API token budgets and compute resources against a single dead-end vulnerability, creating significant cost overruns without advancing the security review. To manage these expenses, organizations should incorporate FinOps principles to balance the compute and API costs of LLM audits against the traditional expenses of manual triage.

However, a successful execution in the sandbox does not guarantee an actionable, high-priority risk. In practice, autonomous agents frequently produce working PoCs for genuine technical flaws that are ultimately irrelevant; or warrant a lower remediation priority within the context of the system's threat model. For example, the agent might successfully exploit an unreachable dead-code path, or trigger a bug that requires administrative access to execute and yields no further escalation of privilege. Therefore, a human engineer should be assigned to review and prioritize the ticket only if the sandbox registers a successful execution, validating environmental context, reachability, and true business impact as part of the review.

This workflow reduces the volume of alerts, but it is important to understand that the security team's workload does not disappear. The engineer's primary job shifts from manually hunting for the initial vulnerability to auditing the LLM-generated proof to ensure it represents a meaningful risk rather than an unexploitable or contextually irrelevant finding. Leadership should properly staff and train teams for this new reality. Deploying LLM agents does not remove the need for skilled practitioners; it redirects their workload toward complex validation. Equally important is training teams to recognize the risk of false negatives. A hyper-focus on filtering AI-generated noise can create a false sense of security. If an exploit relies on a novel technique or a zero-day vulnerability that was not heavily weighted in the model's training data, the agent will likely scan right past it in silence. LLMs augment discovery, but they do not guarantee exhaustive coverage.

When integrating LLMs into SAST triage pipelines, human engineers should also verify the broader architectural integrity. Prompting an LLM with specific SAST warnings can induce contextual narrowing, where the agent becomes hyper-fixated on resolving a localized syntax error and misses broader architectural flaws existing in the same file. Furthermore, if the agent's mandate extends beyond discovery to automated remediation (such as writing and proposing code fixes), this human-in-the-loop validation becomes critical to ensure the LLM does not inadvertently introduce new regressions or bypass intended business logic.

Figure 6: Flowchart outlining the targeted LLM deployment and triage workflow.

Remediation and hardening

LLM-assisted code remediation

A primary goal of integrating large language models (LLMs) into the software development lifecycle is automated remediation. To achieve this, organizations are deploying these capabilities through two primary execution methods: directly within the integrated development environment (IDE) or as a centralized pipeline runner. Examples include CodeMender, although as of time of writing, it is not publicly available.

IDE-integrated method

This method shifts remediation as far left as possible by operating as an active pair-programmer. Tools running continuous static analysis in the background of the IDE surface vulnerabilities directly to the developer via editor diagnostics like inline indicators or hover tooltips.

Localized scope: The developer can trigger the LLM agent to analyze the localized data flow and generate a targeted patch (such as implementing parameterized SQL queries). By constraining the LLM to localized, syntax-level fixes, the scope of the change remains contained. This prevents the agent from attempting sprawling, multi-file refactors that frequently break complex architectural logic.
Human-in-the-loop: The developer reviews the AI-generated patch before the code is committed.
Managing false positives: Local IDE agents allow developers to manage false positives dynamically. Suppressing alerts anchored to specific line text reduces alert fatigue and preserves developer trust.

CI/CD runner method

The runner method executes asynchronously within the CI/CD pipeline to use an LLM to review committed code and automatically propose remediation.

Restricted execution and deterministic validation: Asking a centralized runner to automatically rewrite a complex, multi-file authorization flaw directly in the main branch introduces a high risk of breaking logic errors. To mitigate this, agents must be restricted to generating pull requests (PRs). Once a PR is generated, it must automatically execute standard regression suites alongside the deterministic test harness. By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated. A human engineer then reviews the PR to validate the architectural logic before merging.

In all cases security teams should define a clear boundary between the two methods rather than rely on a single approach. IDE agents provide immediate, syntax-level support. They catch and resolve low-complexity errors locally before developers commit code. Centralized CI/CD runners handle broader organizational baselines. They propose complex, repository-wide fixes for vulnerabilities that bypass local environments.

Post-deployment controls

Even with human review and deterministic test harnesses, AI-generated patches can still introduce logic regressions in production. Organizations should implement strict post-deployment controls:

Automated rollbacks: Treating LLM-generated code with the same post-deployment scrutiny as any major architectural change ensures that if an unforeseen regression traverses the CI/CD pipeline, the environment can revert to a known good state.
Mitigating model drift: Relying on managed AI services introduces the ongoing risk of model drift. To prevent silent weight updates from breaking test harnesses, organizations need to pin specific model API versions to frozen releases. When a pinned version reaches its end-of-life, organizations will face a forced migration. Mitigating this pipeline fragility requires combining model pinning with deterministic regression suites.
Compliance and auditability: If an AI agent automatically closes a security ticket or generates a patch in the CI/CD pipeline, organizations should maintain immutable audit logs to satisfy frameworks like SOC 2 ,PCI-DSS, FedRAMP, and CMMC. National security deployments must also account for data sovereignty requirements. This logging should record the specific model version that proposed the fix, the deterministic test results that validated it, and the human engineer who approved the merge. Furthermore, because emerging legislation like the EU AI Act emphasizes human oversight for high-risk applications, security teams should carefully evaluate how autonomous remediation workflows align with these evolving global regulatory standards.

Figure 7: Flowchart demonstrating the difference between local IDE AI remediation and centralized CI/CD pipeline remediation.

Conclusion

Leveraging LLMs in vulnerability management is a multi-layer solution: Integrating it requires separating workflows by layer. At the enterprise infrastructure level, Risk-Based Vulnerability Management (RBVM) and exposure management are necessary to process the volume of findings and configuration drift. At the product and code security level, LLM-enabled vulnerability assessment and remediation must operate alongside foundational deterministic controls, such as SAST and DAST, to audit custom, open-source, or third-party code.

Although LLMs can help manage technical debt and accelerate vulnerability discovery, they do not replace secure-by-design principles. The fact that LLM agents are proving exceptionally capable at identifying and exploiting localized memory corruption in memory-unsafe codebases, alongside other primary vectors, should serve as a wake-up call.

As a long-term strategy aligned with NSA guidance on Software Memory Safety, organizations need to phase memory-safe languages into new internal development. LLMs are beginning to expand what is possible here by reducing the manual labor required for code migration. Converting existing C or C++ codebases to Rust has historically been unrealistic due to the large volume of engineering hours needed. While fully automated translation is not a turn-key solution, using LLMs to assist engineers with the bulk of the conversion can make these long-term migrations operationally viable. Beyond internal efforts, organizations should use procurement requirements to incentivize vendors to reduce their reliance on memory-unsafe languages and establish secure configuration defaults over time. Bridging the gap between AI velocity and enterprise defense means building an automated pipeline to manage the current backlog, while architecting systems where entire classes of vulnerabilities and misconfigurations are eliminated by design.

Acknowledgements

This analysis would not have been possible without the assistance of Google Threat Intelligence Group (GTIG) and other broader Google teams.

Securing AI at Enterprise Scale: The Google Kubernetes Engine Blueprint

Thu, 16 Jul 2026 11:28:00 +0000

Artificial intelligence is moving from prototype to production faster than traditional security paradigms can adapt. For CISOs and platform engineering teams, the challenge is clear: you need to protect proprietary model weights, defend against novel application-layer threats like prompt injection, and enforce strict regulatory compliance—all without slowing down your AI developers.

To meet all of these security goals, you need more than just a place to run containers; you need a platform that compounds layers of security out-of-the-box.

Today, we're sharing our blueprint for Best practices for AI workload security on Google Kubernetes Engine (GKE). This blueprint consolidates controls across multiple Google Cloud services and GKE features to help you to build a secure-by-default GKE platform that handles the realities of AI at scale.

The AI workload security blueprint for GKE identifies three critical layers of the AI stack. Here's how Google Cloud and GKE approach security at each of these layers.

Infrastructure Layer: Hardware-Attested Execution

You can't have a secure AI workload on an insecure cluster. The infrastructure layer is where GKE provides a security baseline that most enterprises spend years building independently.

Confidential Accelerators: Heavy inference workloads handle your most sensitive data. Confidential GKE Nodes extend hardware-level memory encryption and attestation capabilities to high-performance accelerators, including Confidential GPUs (e.g., NVIDIA H100) and TPUs. This protects your intellectual property from hypervisor-level compromise and infrastructure operator scraping, providing hardware-attested confidentiality.
Zero-Trust Networking & Identity: GKE enforces least-privilege by default. Workload Identity Federation for GKE ensures inference pods can securely fetch model weights from Cloud Storage without long-lived keys, while VPC Service Controls create a strong perimeter around regulated workloads to prevent data exfiltration.

Model Security: Provenance and Behavioral Integrity

If you are deploying your own models—whether fine-tuned or open-source—you own the safety and integrity of the weights.

GKE integrates deeply with Google Cloud's supply chain tools to ensure what you train is exactly what you serve. Traditional SBOMs do not capture AI artifacts. GKE uses k8s-aibom (AI Bill of Materials for Kubernetes) to generate comprehensive inventories of your models, datasets, and frameworks and give you enhanced supply chain visibility.

Application Security: Defending the Inference Path

The application layer is where you have content access and where novel AI-specific threats (like prompt injection and data leakage) emerge. Google Cloud provides purpose-built services that sit directly in your GKE inference path.

Content-Layer Defense: Model Armor sits between your application and the inference endpoint. It inspects every prompt and response for prompt injection, sensitive data exposure (PII), and harmful content generation.
Session Management: The GKE Inference Gateway provides session-level observability and quota enforcement. It allows you to enforce per-user rate limits and detect abuse patterns, such as session manipulation or inference cost abuse.
Agentic Isolation: When your AI acts as an agent—executing generated code or interacting with unverified third-party tools—it must be contained. GKE Sandbox (gVisor) provides a secure isolation boundary that prevents container escapes and protects the underlying node from unpredictable agent behavior.

A Phased Approach to Security

Security on GKE compounds. We recommend a phased approach to securing your AI deployments:

Phase 1 — Deploy (Your Baseline): Implement the foundational configurations. Enable Workload Identity, deploy Model Armor in front of inference endpoints, and run sensitive workloads on Confidential GKE Nodes.
Phase 2 — Operate (Your Hardening): Turn your prototype into a production system. Enforce signed-image policies with Binary Authorization, tune Model Armor profiles, and aggregate audit logs for cross-layer SIEM correlation.
Phase 3 — Govern (Enterprise Scale): Automate compliance. Establish organization-level guardrails with Organization Policy Service, enforce admission-time policies via Kubernetes webhooks, and automate incident response for high-confidence detections.

Our AI workload security blueprint provides you with recommended controls and security measures for each of these phases. Additionally, the blueprint includes foundational guidance for observing your environment over time.

Next Steps

The race to deploy AI should not be a race to the bottom for security. By building on GKE and integrating with Google Cloud, platform teams inherit the infrastructure security baseline that Google has been refining for over a decade, paired with purpose-built AI defenses.

To dive deeper into the specific threat models, architectural patterns, and the complete maturity self-assessment, read the full Best practices for AI workload security on GKE.

How to Analyze and Govern Gemini Enterprise App Usage at Scale with BigQuery

Wed, 15 Jul 2026 16:00:00 +0000

Deploying the Gemini Enterprise app across an organization marks a transformative leap forward in workforce productivity, providing employees with an amazing, high-performance suite of agentic AI tools, search-grounded assistants, and specialized solutions like NotebookLM. As adoption grows to a large scale, it can introduce a critical administrative scale challenge: how to audit, govern, and extract insights from a massive volume of telemetry without getting bogged down in manual overhead. To help administrators succeed, Google Cloud provides comprehensive, out-of-the-box analytics via pre-computed dashboards to track day-to-day adoption, user engagement, and active user metrics. While this provides a product-centric lens to look at Gemini Enterprise app's usage, to understand the impact of agentic AI, administrators might need a more nuanced, organization-centric perspective tailored to their own internal context. This is where using Google BigQuery becomes a crucial tool in the administrator's arsenal to run deep-dive forensics across their organization to analyze and govern the adoption of agentic AI.

Why Gemini Enterprise app + BigQuery is a game-changer

Augmenting the Gemini Enterprise app with BigQuery through log sinks allows a lean administrative team to analyze and govern a large-scale deployment. Specifically, it empowers IT, Data, and Security teams to:

Profile nuanced adoption and behaviors: Segment usage patterns by department to see which teams are building custom agents, track NotebookLM utilization, and calculate agent-to-employee ratios.
Quantify organizational value: Combine conversational logs with HR or line-of-business datasets to calculate actual employee hours saved, trace value creation, and build executive Looker dashboards.
Execute precision compliance audits: Audit grounding queries across Google Drive folders and enterprise directories to prevent data leaks and protect corporate IP.
Investigate safety alerts instantly: Query historical logs when security filters flag a prompt, identifying the exact text that triggered a Model Armor block to resolve compliance alerts.

To support these use cases, the telemetry is partitioned into five distinct log tables in BigQuery, capturing unique data fields:

BigQuery Destination Table	Telemetry Captured
Gen AI User Messages `discoveryengine_googleapis_com_g en_ai_user_message`	Verbatim prompt inputs typed by users
Gen AI Choices `discoveryengine_googleapis_com_g en_ai_choice`	Verbatim model responses, finish reasons, and LLM reasoning steps
User Activity Telemetry `discoveryengine_googleapis_com_g emini_enterprise_user_activity`	Corporate identity (IAM emails) and grounding file access paths
Cloud Audit Activity `cloudaudit_googleapis_com_activity`	Control plane configuration changes and administrative user logs
Cloud Audit Data Access `cloudaudit_googleapis_com_data_ac cess`	High-volume data plane interactions and search queries
Aggregate OOB Metrics (Batch Export Table)	Pre-aggregated seats claimed, seat purchases, and engagement metrics from the past 30 days. To be pulled asynchronously via custom daily batch runs of the `analytics:exportMetrics` API to build high-level adoption and cost dashboards.

Ingestion pipeline and architecture

To implement scale-ready observability, administrators establish an automated telemetry pipeline. Moving your Gemini Enterprise data to BigQuery does not require complex custom software development; instead, it leverages a continuous Cloud Logging Log Router Sink for conversational logs and an asynchronous batch export API for high-level aggregate seat metrics.

The diagram below illustrates the ingestion pipeline and how telemetry is mapped to BigQuery:

Here is your blueprint for connecting Gemini Enterprise to BigQuery to build the ultimate analytics and governance foundation for your organization.

Routing pipelines: Continuous logging and audit sinks

To capture your telemetry, establish log sinks within Cloud Logging to intercept and route runtime events to BigQuery:

The streaming pipeline (detailed logs): Streams row-by-row conversational data (user prompts, model choices, and grounding events). Ensure prompt and response logging is enabled in your Gemini Enterprise Admin Console (see Set Up Usage & Audit Logs).

- Inclusion Filter (replace [PROJECT_ID] with your Google Cloud Project ID):

code_block: <ListValue: [StructValue([('code', 'logName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgemini_enterprise_user_activity" OR\r\nlogName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.user.message" OR\r\nlogName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.choice"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe28700>)])]>

The governance pipeline (audit logs): Captures administrative actions (Admin Activity) and data plane operations (Data Access, such as grounding data connector lookups).

- Inclusion Filter (replace [PROJECT_ID] with your Google Cloud Project ID):

code_block: <ListValue: [StructValue([('code', 'logName:"projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com" AND \r\nprotoPayload.serviceName="discoveryengine.googleapis.com"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe28970>)])]>

- Admin Activity Logs: Always enabled by default; tracks resource changes (e.g., custom agent creation, updates, deletions).
- Data Access Logs: Off by default; must be enabled in GCP IAM settings for the Discovery Engine API to log user-level data read/write interactions during chats.

Unlock advanced intelligence in BigQuery

Transform raw telemetry into insights

BigQuery provides AI-powered analysis tools that make understanding and navigating telemetry effortless. By leveraging Gemini in BigQuery, administrators can translate raw log streams into visual insights and clear documentation without manual guesswork.

No-Code Conversational Analytics (BigQuery CA)
Querying nested JSON schemas is made simple with Conversational Analytics in BigQuery (BQ CA). BQ CA acts as an intelligent agent within BigQuery Studio, automatically generating and executing SQL grounded in your schema, business metadata, and verified queries/UDFs to ensure metrics consistency. It also surfaces its "thinking process" alongside the generated code to build administrative trust.

For example, as shown in the screenshot below, asking "Compare the usage of notebooklm, deep research and custom agents using oob_metrics?" generates the correct SQL, runs the query and outputs the result in seconds:

As shown in the screenshot below, BQ CA goes beyond traditional querying and standard SQL generation by allowing users to execute sophisticated AI and machine learning tasks directly within the console. Administrators can leverage these native capabilities to run advanced analysis, such as classification of user prompt sentiment or forecasting future adoption trends, streamlining the governance process.

Auto-generated schema documentation and insights

Understanding telemetry fields like useriamprincipal, finish_reason, or groundedContent is crucial for extracting the right insights. BigQuery simplifies this through automated schema documentation and AI-powered context:

Automated profiling and metadata: By pairing Knowledge Catalog Data Profiling with Gemini, you can evaluate unique value counts, null rates, and data distributions in raw tables. With a single click, Data Insights generates descriptive metadata for both tables and individual nested columns.
Unified data insights: Gemini leverages this rich context to surface insights across your entire data estate. It automatically recommends queries to find anomalies or safety failures within a single table (like gen_ai_user_message). At the dataset level (Preview), it generates an interactive relationship graph to map cross-table join paths and suggests queries that combine data—like user activity and model outputs—to calculate task complexity.
Seamless agent integration and glossaries: Table and data insights integrate directly into the BigQuery Conversational Analytics (BQ CA) agent UI, giving agents immediate access to enriched metadata and few-shot examples. To ensure agents accurately interpret domain-specific prompts, BQ CA also supports business glossaries. You can define custom terms directly for your agents or import existing glossaries from Knowledge Catalog to establish a standardized vocabulary.

Administrators can then leverage the profiling, enriched metadata and insights to navigate logged fields, understand the telemetry structure, and catalog data for compliance audits. As shown in the screenshots below, the output of Gemini-powered auto generation of schemas, descriptions and linkages makes it easy to make sense of the complex relationships and telemetry data output by agentic interactions on the Gemini Enterprise app.

Visualizing with Data Studio dashboards

For executive stakeholders, raw log tables can be transformed into interactive, high-impact business intelligence dashboards. By connecting Data Studio directly to BigQuery, you can build dashboards that monitor:

User adoption and seat ROI: Segment usage trends by department, highlighting the ratio of custom agents built relative to employee headcount.
Data grounding traffic: Map which enterprise connectors—such as SharePoint, Google Drive, or Gmail—experience the highest utilization.
Content safety and violations: Track Model Armor sanitization blocks and sentiment feedback loops over time to maintain safety standards.
Share BQ Conversational Analytics agent: Share the BQ CA agents you built via Data Studio to give business users the ability to ask more questions of the data.

Empower your organization with the Gemini Enterprise app and your administrators with BigQuery

Deploy the Gemini Enterprise App: Bring the best of Google AI to every employee.
Enable Prompt & Response Logging: Turn on prompt and response logging in the Admin Console to begin recording user activity telemetry.
Configure Log Router Sinks: Establish sinks to stream telemetry into BigQuery.
Track Metrics & Export Analytics: Access pre-computed, out-of-the-box dashboards on the console and export historical aggregate statistics.
Extract Table-Level & Dataset-Level Insights: Explore unfamiliar log tables and discover relationship join paths automatically.
Query with Conversational Analytics: Build data reasoning agents and leverage natural language querying inside BigQuery Studio.
Visualize with Data Studio: Connect Data Studio to BigQuery to build executive-level dashboards & give access to BQCA agents to business users.
Consult a Google Cloud Customer Engineer for the most cost-effective and secure configuration for the analytics setup described above.

The authors would like to acknowledge and thank the Google Forge team, especially Vicky Falconer, Dharini Chandrashekhar and Adhaar Gupta, for contributing to the core work that led to this article.

IDC: Why the right networking approach is foundational to agentic AI

Wed, 15 Jul 2026 16:00:00 +0000

Editor’s note: Today we hear from IDC on the results of its 2026 AI in Networking Special Report Survey exploring the enterprises' concerns about networking infrastructure to support the rise of agentic AI in their organizations. The survey was sponsored by Google Cloud.

Enterprises are moving quickly on AI pilots, but the move from pilot to production remains uneven. While AI models remain important, IDC research indicates that the pilot-to-production bottleneck is primarily infrastructure-centric, with core networking concerns emerging as one of the leading drivers of AI project delays and abandonment. In IDC's 2026 AI in Networking Special Report Survey:

32.6% of respondents cite security concerns: As AI workflows become more distributed and autonomous, enforcing consistent security and governance becomes more difficult.
26.8% of respondents cite challenges in automation: Manual operations and fragmented controls can slow deployment and make AI environments harder to scale.
24.7% of respondents cite staff time and talent restrictions: Limited skills and operational bandwidth can constrain an organization's ability to move AI initiatives into production.

Agentic AI specifically heightens these concerns by introducing more distributed and dynamic interactions across applications, services, APIs, tools, and data sources. In production environments, these interactions often span different agent frameworks, model providers, clouds, open-source tools, SaaS APIs, and internal applications, expanding both the operational scope and the security and governance surface area.

Networking for operational control, security, and governance at scale

Networking is the primary enabler of agentic interactions and plays a foundational role for intracloud and intercloud network- and services-layer connectivity, end-to-end security, and consistent governance. In agentic systems, networking increasingly extends into tighter service-centric controls that govern how distributed services identify one another, communicate, and exchange data securely. While AI workloads in general are increasing east-west traffic demands, agentic AI adds an additional layer of complexity by creating dynamic interactions that require tighter policy, visibility, and control closer to the application workflow.

From an infrastructure perspective, networking is much more than just a connectivity function. It is part of the infrastructure platform control plane that applies policy-based controls, supports observability, and helps maintain consistent security and governance across an AI agent's activity. This is significant because framework-level controls alone become insufficient in environments where agents and services span different runtimes, clouds, deployment models, and operating domains.

That is why an infrastructure-level approach becomes key. It does not replace application frameworks or orchestration environments, but it provides broader and more consistent policy implementation across a complex architectural landscape. As agentic AI becomes more autonomous and distributed, organizations need these controls built in as part of the infrastructure to reduce fragmented observability, inconsistent policy application, and unmanaged shadow agent activities. From a cloud infrastructure standpoint, this is where cloud network services become strategically important.

Balancing act: A platform vs. best-of-breed approach

Agentic AI systems are inherently fragmented because of underlying distributed workflows. Enterprises are already navigating a rapidly evolving landscape of business requirements, open-source components, emerging protocol standards, and new architecture patterns. In this context, choices between best-of-breed point solutions and platform-based approaches should be strategic rather than ideological.

Best-of-breed capabilities may be necessary to address specific technical requirements. But it is also true that point solutions introduced across a distributed agentic AI landscape can create inconsistent policies, operational complexity, and governance gaps. IDC research reflects this tension. In IDC’s 2026 AI in Networking Special Report Survey, organizations remained divided between platform and best-of-breed preferences for AI workloads; among respondents who favored platforms, the main reasons cited were stronger security (32.9%), reduced complexity (27.7%), and faster deployment (24.2%).

In IDC's view, a balance is important. Platforms can provide a consistent operational and policy foundation for AI deployments, but at the same time, they need to be modular and extensible to allow the inclusion of best-of-breed functionality as part of the platform toolset. The right platform for agentic AI should be open, flexible, and able to evolve. It should support integration with third-party and open-source tools, allow insertions of needed security and observability functions, and adapt without complete architectural rework.

This is a period of technology disruption. Businesses must meet their AI objectives while carefully managing dynamic agentic AI systems. In this environment, networking not only remains a connectivity piece of the AI infrastructure but becomes foundational to how organizations establish operational control, apply policy consistently, and maintain end-to-end trust across agentic workflows.

As agentic AI systems continue to evolve, the demands they place are unlikely to be addressed through best-of-breed point solutions alone. Operationalizing agentic AI at scale will require organizations to leverage the right networking approach, supported by infrastructure platforms that are open, flexible, and extensible, enabling a cohesive and adaptable security and governance framework.

Message from the sponsor
The autonomous and non-deterministic communications of agentic applications pose challenges for which the infrastructure and governance models of the cloud-native era are not prepared. In the agent-native era, an infrastructure-led approach is required to enable agentic applications at scale in production with effective governance and observability. An extensible platform based on open standards is critical in enabling the agentic journey today and through its maturity. Learn about the infrastructure imperatives and open standards that make a viable agentic infrastructure here.

How to solve PostgreSQL multilingual full-text search limitations with AlloyDB AI

Wed, 15 Jul 2026 16:00:00 +0000

AlloyDB powers enterprise-grade search for some of the largest organizations, providing robust hybrid search capabilities that combine text, vector, and keyword searches into a simple ranked SQL query. And with our recent launch of RUM index support, AlloyDB customers now have even more powerful full-text search capabilities at their fingertips.

However, database developers often face limitations when indexing continuous text in logographical languages like Chinese, Japanese, and Korean, where traditional whitespace-based tokenization fails. Gemini’s multilingual capabilities enable you to intelligently parse text in these languages to implement intelligent word segmentation and stop-word removal, but orchestrating row-wise API calls on massive datasets is slow and fragile. Now you can integrate the world knowledge of Gemini models natively into your database using AlloyDB AI Functions, enabling highly accurate full-text search for logographical languages without the administrative overhead of complex ETL pipelines.

Continuous text and logographical languages

To understand why this native integration is such a significant advancement, we must first examine the underlying mechanics of text search and why traditional indexing methods fail when processing continuous text.

To build an effective full-text search index in PostgreSQL, the engine must parse text into search tokens (lexemes) using the to_tsvector function. By default, standard text search configurations like simple or english assume that words are separated by whitespace. The database engine extracts search terms by splitting the input string at these spaces.

However, Chinese and other logographical languages do not use spaces between words. Words are written continuously, with punctuation serving as the only boundaries. Because of this, standard PostgreSQL parsers fail to extract individual keywords. Instead, they treat entire sentences or long clauses as a single, continuous lexeme.

For example, consider this input string: "你们研究所有十个图书馆" (Your research institute has ten libraries)

Without spaces, passing this to to_tsvector('simple', ...) produces a single, massive lexeme: '你们研究所有十个图书馆'

If you search for "研究所" (research institute) or "图书馆" (library), the query fails to return a match. The keywords are trapped inside the larger string, forcing you to search for the exact, long-form sentence to get a result.

Traditional workarounds and their limits

You might try to resolve this using traditional tools and pipelines, each of which introduces significant operational friction or accuracy limits:

Third-party database extensions: Extensions like zhparser or pg_jieba add Chinese tokenization to PostgreSQL. However, these are often not supported in fully-managed database environments. They also rely on static dictionaries, which frequently fail to parse modern jargon, brand names, or context-dependent terms correctly.
External preprocessing pipelines: Exporting text to an external application (such as a Python microservice running jieba or spaCy) to insert spaces before saving it to the database. This pattern introduces substantial ETL complexity, network latency, and data exposure risks by moving your data out of the database tier.
Inadequacy of rule-based and dictionary-driven segmentation: Traditional tokenizers rely on static dictionaries and hand-coded syntactic rules to split text. They often struggle to resolve semantic ambiguity, where the exact same sequence of characters must be segmented differently depending on the context. To perform accurate segmentation, you need the world knowledge and contextual intelligence of a large language model like Gemini.

In-database pre-processing with Gemini

AlloyDB AI bypasses these workarounds — and their limits — by introducing native, in-database AI Functions like ai.generate(). This allows you to call Gemini directly from SQL, keeping your data and intelligence in one place.

This approach provides three core advantages:

No data movement: All text preprocessing and segmentation happen directly within the database engine. This minimizes network latency and keeps your data protected within your database boundaries.
In-database intelligence: You do not need to build, deploy, or maintain external microservices or orchestration frameworks. The database engine coordinates the model calls natively.
Stored procedure-based batching: By using a PL/pgSQL stored procedure with array aggregation, you can process rows in parallel batches, unpack the results safely using GENERATE_SERIES, and commit each batch immediately. This prevents database memory exhaustion, bypasses row lock contention, and supports stable, performant execution even when handling massive tables.

Implementing semantic word segmentation

To implement this solution, we will create a database table where the raw content, the segmented text, the search vector, and the vector embeddings are stored together.

code_block: <ListValue: [StructValue([('code', "CREATE TABLE documents (\r\n id SERIAL PRIMARY KEY,\r\n title TEXT NOT NULL,\r\n original_content TEXT NOT NULL,\r\n content_segmented TEXT,\r\n search_vector tsvector GENERATED ALWAYS AS (to_tsvector('english', content_segmented)) STORED,\r\n embedding vector(3072) GENERATED ALWAYS AS (embedding('gemini-embedding-001', content_segmented)) STORED\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cec7ea760>)])]>

By defining search_vector and embedding as generated columns, AlloyDB automatically updates both the full-text search index and the vector embeddings whenever the content_segmented column is updated. This reduces your application-side logic to a single update statement.

Step 1: Document batch segmentation

If you consult the AlloyDB AI documentation, it recommends using cursor-based processing when dealing with large datasets (10,000 to millions of rows) to avoid memory bottlenecks.

However, the documentation’s cursor examples focus on append-only operations — streaming text into a new, empty table using INSERT. Our use case requires an in-place UPDATE on our live documents table. Implementing this with a raw cursor loop in a standard anonymous block (DO $$) introduces three important production hazards: excessive row locking that freezes live applications, a rollback risk if a network blip occurs, and alignment risks where parallel cursors fall out of step.

To mitigate these challenges and accelerate performance, we use a stored procedure configured with high-throughput array-based batching:

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE PROCEDURE segment_all_documents(p_batch_size INT DEFAULT 100)\r\nLANGUAGE plpgsql AS $$\r\nDECLARE\r\n v_processed_count INT;\r\nBEGIN\r\n LOOP\r\n -- 1. Grab a single isolated batch, aggregate into arrays, and call Gemini.\r\n -- We explicitly ORDER BY id during aggregation to guarantee the arrays match perfectly.\r\n WITH batch_raw AS (\r\n SELECT id, original_content\r\n FROM documents\r\n WHERE content_segmented IS NULL OR content_segmented = ''\r\n ORDER BY id\r\n LIMIT p_batch_size\r\n ),\r\n batch_processed AS (\r\n SELECT \r\n ARRAY_AGG(id ORDER BY id) AS target_ids,\r\n ai.generate(\r\n prompts => ARRAY_AGG('Perform Chinese word segmentation (分词) on the provided text to prepare it for full-text search indexing.\r\nRules:\r\n- Insert a single space between every atomic, meaningful word.\r\n- Separate all punctuation marks (both full-width and half-width) with spaces.\r\n- Preserve the original structure, line breaks, and non-Chinese characters (e.g., English words, numbers).\r\n- Output ONLY the processed text. Do not include any greetings, explanations, or formatting wrappers like markdown code blocks unless they exist in the original text.\r\nText to process: ' || original_content ORDER BY id),\r\n model_id => 'gemini-2.5-flash-lite'\r\n ) AS ai_outputs\r\n FROM batch_raw\r\n ),\r\n -- 2. Use GENERATE_SERIES to unpack the paired array indexes safely\r\n unpivoted_results AS (\r\n SELECT \r\n b.target_ids[i] AS doc_id,\r\n b.ai_outputs[i] AS segmented_text\r\n FROM batch_processed b,\r\n GENERATE_SERIES(1, COALESCE(ARRAY_LENGTH(b.target_ids, 1), 0)) i\r\n )\r\n -- 3. Execute the batch update for this chunk\r\n UPDATE documents d\r\n SET content_segmented = r.segmented_text\r\n FROM unpivoted_results r\r\n WHERE d.id = r.doc_id;\r\n\r\n -- Check how many rows were updated in this pass\r\n GET DIAGNOSTICS v_processed_count = ROW_COUNT;\r\n\r\n -- If the update affected 0 rows, it means the whole table is finished\r\n EXIT WHEN v_processed_count = 0;\r\n\r\n -- 4. Commit immediately to save progress and release row locks!\r\n COMMIT;\r\n \r\n RAISE NOTICE 'Successfully processed and committed a batch of % rows.', v_processed_count;\r\n END LOOP;\r\nEND $$;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cec7eaac0>)])]>

To run this preprocessing pipeline across your entire table, simply call the stored procedure:

code_block: <ListValue: [StructValue([('code', 'CALL segment_all_documents(100);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cec7ea580>)])]>

This stored procedure approach provides three benefits that directly solve your production challenges:

Parallelized array aggregation (solving the sequential bottleneck): By aggregating the batch into arrays and calling ai.generate(prompts => ...) with the array, AlloyDB batches the model requests and executes them in parallel. This is faster than processing rows one-by-one sequentially.
Safe index-based unpacking (solving cursor desync): Using GENERATE_SERIES to unpack the array indexes maps the model output back to the correct document ID, reducing the risk of parallel streams falling out of step.
Immediate commits and lock release (solving blocking and rollback risks): Committing the transaction at the end of each loop iteration (COMMIT;) is an essential optimization. It immediately saves progress to disk and releases row locks, preventing long-running transactions from freezing your live application and ensuring a network blip won't roll back hours of work.

Once this pipeline runs, our example sentence is stored in content_segmented as: "你们研究所有十个图书馆"

Step 2: Choosing simple vs. english

When defining your tsvector generated column, you must choose the appropriate PostgreSQL text search configuration. This choice depends on your dataset:

When to use simple: If your database contains only Chinese text, the simple configuration is ideal. It converts text to lowercase but does not perform stemming or default stop-word removal. Since the model prompt already handles semantic segmentation and custom stop-word filtering, the simple configuration maps directly to the model's optimized output without further modification.
When to use english: In modern enterprise applications, Chinese documentation and user queries frequently contain embedded English terms (e.g., product codes, brand names, or technical terms). In these bilingual scenarios, the english configuration is superior. The English Porter stemmer leaves non-ASCII Chinese characters completely intact as exact lexemes, while automatically normalizing the English terms (e.g., stemming "running" to "run") and filtering out generic English stop words ("the", "and"). This achieves unified bilingual search capabilities without requiring separate columns or complex routing logic.

Step 3: Query-time preprocessing

Segmenting the document content is only half the battle. To match the indexed data, the incoming search queries must be pre-processed using the same Gemini-based segmentation logic.

We can take this a step further to improve search precision. We can instruct the model to act as an intelligent stop-word filter, stripping away low-value grammatical noise that would otherwise clutter your search results:

Grammatical particles (e.g., 的, 了)
Pronouns (e.g., 你, 我们)
Comparison words (e.g., 比, 最)
Question words (e.g., 怎么, 为什么)

For example, we can process a user query on the fly using a SQL query:

code_block: <ListValue: [StructValue([('code', "SELECT ai.generate(\r\n 'Perform Chinese word segmentation (分词) on the provided search query.\r\n Additionally, remove low-value grammatical noise such as particles (e.g., 的, 了), pronouns (e.g., 你, 我们), comparison words (e.g., 比, 最), and question words (e.g., 怎么, 为什么).\r\n Rules:\r\n - Insert a single space between every remaining meaningful word.\r\n - Output ONLY the processed keywords. Do not include greetings or explanations.\r\n Query to process: 你们研究所的图书馆在哪里？'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe1c8e0>)])]>

The model processes this query and returns the keyword string: "研究所图书馆"

Step 4: executing the search with RUM

With your documents segmented and indexed, you can create a RUM index on your generated search_vector column. A RUM index is an index type that stores lexeme positions directly. This helps AlloyDB calculate search relevance and word distance directly within the index, avoiding the slow re-scan operations required by traditional GIN indexes.

code_block: <ListValue: [StructValue([('code', 'CREATE INDEX idx_docs_rum\r\nON documents\r\nUSING rum (search_vector rum_tsvector_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe1cb80>)])]>

To run a search, you convert your preprocessed query string ("研究所图书馆") into a search query using plainto_tsquery and execute it against the RUM index. You can use the RUM distance operator (<=>) to sort the results by relevance:

code_block: <ListValue: [StructValue([('code', "SELECT id, title, original_content,\r\n search_vector <=> plainto_tsquery('english', '研究所 & 图书馆') AS distance\r\nFROM documents\r\nWHERE search_vector @@ plainto_tsquery('english', '研究所 & 图书馆')\r\nORDER BY distance ASC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe1c6a0>)])]>

Because the RUM index calculates the distance score directly, this query executes with high efficiency, returning relevant matches in milliseconds.

Extending to hybrid search

While keyword-based text search is excellent for finding exact matches, it can miss relevant documents that use different terminology. To solve this, you can combine your segmented full-text search with semantic vector search using the multilingual gemini-embedding-001 model. This pattern, known as hybrid search, retrieves results that are both lexically and semantically relevant.

AlloyDB makes it easy to run hybrid search. You can create a ScaNN index (Google's vector index technology) on your embedding column and combine it with your RUM index.

Creating the ScaNN index

To accelerate your vector search, you create a ScaNN index on the embedding column:

code_block: <ListValue: [StructValue([('code', 'CREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\nCREATE INDEX idx_docs_scann\r\nON documents\r\nUSING scann (embedding cosine);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe1c070>)])]>

Running the hybrid search query

To combine the results of your vector and text searches, you can use a SQL query that implements Reciprocal Rank Fusion (RRF). RRF is a rank-based algorithm that merges multiple search result lists into a single, unified list by assigning a score to each document based on its rank in the individual lists.

The following query performs both searches in parallel using Common Table Expressions (CTEs), joins the results using a FULL OUTER JOIN, and calculates the final RRF score:

code_block: <ListValue: [StructValue([('code', "WITH vector_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY embedding <=> ai.embedding('gemini-embedding-001', '研究所图书馆')::vector) AS rank\r\n FROM documents\r\n ORDER BY embedding <=> ai.embedding('gemini-embedding-001', '研究所图书馆')::vector\r\n LIMIT 10\r\n),\r\ntext_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY search_vector <=> plainto_tsquery('english', '研究所 & 图书馆')) AS rank\r\n FROM documents\r\n WHERE search_vector @@ plainto_tsquery('english', '研究所 & 图书馆')\r\n ORDER BY search_vector <=> plainto_tsquery('english', '研究所 & 图书馆')\r\n LIMIT 10\r\n)\r\nSELECT\r\n COALESCE(vector_search.id, text_search.id) AS id,\r\n COALESCE(1.0 / (60 + vector_search.rank), 0.0) + COALESCE(1.0 / (60 + text_search.rank), 0.0) AS rrf_score\r\nFROM vector_search\r\nFULL OUTER JOIN text_search ON vector_search.id = text_search.id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f0cdfe1c130>)])]>

In this query:

The vector_search CTE uses the ScaNN index to find the top 10 documents that are semantically closest to your query, using the gemini-embedding-001 model.
The text_search CTE uses the RUM index to find the top 10 documents that match your segmented keywords, using the RUM distance operator for ranking.
The final select statement joins these lists and calculates the RRF score using the standard constant of 60. The top 5 results are returned, providing a precise blend of exact keyword matches and semantic matches.

Why AlloyDB AI is ideal for search

By using AlloyDB AI to solve the challenges of multilingual and hybrid search, you build a robust, scalable, and cost-effective foundation for your enterprise AI applications.

Native, in-database intelligence: By running model processing directly within AlloyDB AI, you avoid the cost, latency, and data exposure risks of moving transactional data to external AI services.
Enterprise-grade search performance: Combining ScaNN vector search (built on Google's search technology) and RUM full-text search in a single relational database delivers fast, accurate search outcomes without needing to maintain separate, complex search engines.
High context-aware accuracy: Unlike static, rule-based dictionaries that struggle with modern terminology, Gemini's world knowledge brings deep semantic understanding to word segmentation, providing high search precision.
Operational simplicity: You get robust bilingual and hybrid search capabilities using standard SQL. This means you can build and scale AI applications using the database skills you already have, without learning new APIs or managing complex external pipelines.

What's next

Giving your applications the ability to safely and efficiently interact with transactional data moves us away from fragmented data silos and toward an architecture where AI can reliably access enterprise truth.

Ready to build? Discover AlloyDB with a 30-day free trial, and dive into the Getting started with hybrid search in AlloyDB Codelab to start creating intelligent search experiences in your applications today.

The Risk of Exposed Cloud Functions and How to Harden

Wed, 15 Jul 2026 14:00:00 +0000

Written by: Corné de Jong

Introduction

Mandiant security assessments frequently identify publicly exposed serverless applications that lack authentication, often as a result of specific business requirements. Serverless deployments typically run custom-developed code that incorporates third-party packages, making them targets for a wide range of application-level attacks, including:

Local and Remote File Inclusion (LFI/RFI)
Command Injection

Successful exploitation of these vulnerabilities can grant an attacker full control over the underlying container instance. Such access can serve as a foothold that may ultimately lead to a full compromise of the victim’s cloud environment.

Based on lessons learned in customer engagements, in this blog post we describe attack scenarios and provide actionable guidance on how to secure serverless environments. While this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.

What are Serverless Applications?

Serverless applications, also described as Function-as-a-Service (FaaS), allow the deployment of individual blocks of code as microservices within a flexible, decoupled, and event-driven cloud architecture without the need to manage underlying infrastructure. These services enable applications and automations to scale automatically and deploy instantly, removing operational overhead. Serverless services underpin major e-commerce, media, payment processing applications, and AI usage.

The rapid expansion of generative AI adoption is a significant driver of increased serverless architecture use. AI workflows, including chatbot interactions, image generation, “vibe-coding”, and multi-step AI agents rely on serverless functions to complete tasks for users. This growth has made securing serverless environments a more pressing challenge for enterprise security teams.

Risks of Serverless Application Attacks

Publicly exposed serverless workloads can serve as an initial access point for threat actors. As noted, these services may contain vulnerabilities within the code, imported packages, or the underlying runtime environment.

Once an entry point is exploited, attackers typically attempt to escalate privileges or move laterally. Common techniques observed include:

Extracting secrets stored directly within the application code.
Reviewing application logic and sensitive data to identify further attack vectors within the environment.
Exfiltrating service account bearer tokens from the metadata server following successful Remote Code Execution (RCE).

Leveraging these compromised secrets or service accounts allows threat actors to pivot to adjacent systems and workloads, potentially resulting in a total environment takeover if proper hardening strategies are not in place.

Example Attack Scenarios

The following simplified scenarios illustrate how serverless functions can be compromised and how attackers pivot after achieving initial code execution.

Local File Inclusion (LFI)

In the following Cloud Run example, a Python/Flask function accepts user-controlled input to open a file without performing proper validation. This pattern is an example of a Local File Inclusion (LFI) vulnerability.

import functions_framework

@functions_framework.http
def hello_http(request):
    request_json = request.get_json(silent=True)
    request_args = request.args
    if request_json and 'file' in request_json:
        file = request_json['file']
    elif request_args and 'file' in request_args:
        file = request_args['file']
 
# VULNERABILITY: The 'file' parameter is used directly in open() 
# without validation, allowing arbitrary file access
    with open(file, 'r') as resp:
          filedata = resp.read()
    return 'local file data {}!'.format(filedata)

Figure 1: Vulnerable Python/Flask function accepting unvalidated user input to open files

This vulnerability allows an attacker to request sensitive files from the Cloud Run instance by using curl to send a POST request via the file parameter:

curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "main.py"}'

Figure 2: curl POST request targeting the file parameter

The response provides the complete main.py source code. An attacker can analyze the code for:

Hardcoded secrets such as API keys, database credentials, or authentication tokens
Business logic flaws and additional injection points
Internal service endpoints and architecture details
Import statements revealing the technology stack and potential CVE exposure

Additionally, attackers can leverage standard ../ directory traversal sequences to retrieve sensitive system files:

curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd"}'

Figure 3: curl POST request leveraging directory traversal sequences

An LFI vulnerability allows an attacker to retrieve and fuzz various files directly from the container. Key examples include:

requirements.txt, package.json, go.mod: Used to identify installed packages and versions with known vulnerabilities.
.env files: Frequently contain sensitive environment variables or hard coded secrets.
Application configuration files: May contain database credentials, API keys, or service endpoints if not securely managed.
/etc/passwd, /proc/self/environ: Contains user information, environment variables.
Application logs: may contain auth tokens or PII data.

Best Practice: Never store secrets or credentials within the source code or local container files. Utilize a dedicated secrets management solution, such as Secret Manager.

Code Execution/Command Injection

In the following scenario, a Python function uses shell execution methods with unsanitized user input, allowing an attacker to execute arbitrary commands.

import functions_framework
import subprocess


@functions_framework.http
def hello_http(request):
  request_json = request.get_json(silent=True)
  request_args = request.args
  if request_json and 'input' in request_json:
      input = request_json['input']
  elif request_args and 'input' in request_args:
      input = request_args['input']
  result = subprocess.run(input, shell=True,capture_output=True, text=True)
  return format(result)

Figure 4: Python function utilizing shell execution with unsanitized user input

This allows an attacker to execute a subsequent curl request targeting the GCP metadata service to retrieve the service account’s bearer token.

The following request extracts the service account's OAuth 2.0 bearer token, which remains valid for 1 hour:

curl -X POST https://cloudrun02-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"

Figure 5: Extraction of a GCP service account bearer token via a curl request

Once obtained, an attacker can use it on an attacker-controlled system to execute Google Cloud CLI commands. For example the CLOUDSDK_AUTH_ACCESS_TOKEN environment variable can be set using the stolen bearer token.

export CLOUDSDK_AUTH_ACCESS_TOKEN=”obtain bearer token”

Figure 6: Defining CLOUDSDK_AUTH_ACCESS_TOKEN environment variable

Attackers can then leverage Google Cloud Cloud CLI within the security context of the Cloud Run Compute service account. If deployed without best practices and thoughtful configuration controls, for example, if the Cloud Run service runs as the default compute service account with Editor permissions, this would be equivalent to a full GCP project takeover, and allow the attacker to:

Read/write/delete most GCP resources
Deploy new services and modify existing configurations
Access secrets and encryption keys
Exfiltrate data across all accessible storage systems
Establish persistent backdoors through new service accounts or SSH keys.

Hardening Recommendations

Mandiant recommends that organizations implement parallel approaches for effective serverless security:

Secure Software Development Lifecycle (S-SDLC): integrate security scanning, code review, least-privilege IAM into CI/CD pipelines before deployment and integrate continuous security testing;
Vibe Coding: Mandiant recommends multi-layered security enforcement for AI-generated code or "vibe coding." Organizations should isolate AI experimentation within dedicated sandbox environments and enforce strict data egress controls to protect production systems and internal data. Furthermore, development environments should be restricted to approved IDEs with human-in-the-loop capabilities, utilizing only verified plugins operating under least privilege to mitigate supply chain vulnerabilities. Finally, organizations must ensure this AI-generated software follows Secure Software Development Lifecycle (S-SDLC) controls while establishing clear internal guidelines regarding permitted use cases. Comprehensive security fundamentals for vibe coding are documented in detail within the Wiz Vibe Coding Security Fundamentals blog.
Compensating Runtime Controls: Implement the following defense-in-depth measures to limit and contain compromise even when application vulnerabilities exist;

Segregate Public Services

Host public-facing Cloud Run services consumed by untrusted external entities in a dedicated, isolated Google Cloud project. This ensures a compromise does not provide an immediate path to critical internal resources. The implementation of this 'Service Project' model is beyond the scope of this post; however, it is documented in detail within the secured serverless architecture blueprint.

Identity and Access Management (IAM)

Mandiant recommends using a custom service account for service authentication rather than the default Compute Engine service account, following the principle of least privilege. Grant only the specific permissions necessary for the Cloud Run function to operate, for example:

Cloud Storage Bucket Access: If the service only requires read access to objects from a Cloud Storage bucket, grant the Storage Object Viewer (roles/storage.objectViewer) role restricted to that specific bucket.
Secret Manager Access: If the service requires access to secrets, grant the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role only to the individual secrets required. For further details on secret access from Cloud Run, refer to the GCP documentation on configuring secrets.

Layer 7 Application Load Balancer (ALB) Architecture

Restrict ingress traffic for serverless functions to internal only and use an external Layer 7 ALB to manage internet exposure. This provides:

Centralized Traffic Management: Granular control over headers and SSL policies.
Cloud Armor Integration: Web Application Firewall (WAF) support to harden applications against vulnerabilities such as Local/Remote File Inclusion (LFI/RFI) and Server-Side Request Forgery (SSRF).
Traffic Shaping: Implementation of rate limits and request limitations to prevent abuse.
Enhanced Visibility: Robust logging and log-forwarding capabilities for security monitoring.
Identity-Aware Proxy (IAP): integration support for scenarios requiring specific identity-based authentication for internal users.

Web Application Firewall (WAF) — Cloud Armor

Cloud Armor provides WAF protections that can be integrated with the Load Balancer to filter malicious traffic. The following examples demonstrate how to configure Cloud Armor security policies to block the specific local file inclusions, remote code execution and traversal attacks previously outlined.

Local File Inclusion

The lfi-v33-stable preconfigured WAF rules can block common local file inclusion attacks (local file inclusion reference).

evaluatePreconfiguredWaf('lfi-v33-stable', {'sensitivity': 3})

Figure 7: Cloud Armor lfi-v33-stable WAF rule configuration

Blocking a path traversal request ../../../etc/passwd resulting in a 403 forbidden:

curl -X POST https://exampleabc01.com -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd}'
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden

Figure 8: Verification of Cloud Armor blocking path traversal request, resulting in a 403 forbidden

Remote Code Execution

The rce-v33-stable preconfigured WAF rules can block remote code execution attempts (remote code execution reference).

evaluatePreconfiguredWaf('rce-v33-stable', {'sensitivity': 3})

Figure 9: Cloud Armor rce-v33-stable WAF rule configuration

Blocking the remote code execution request from the previous example results in a 403 forbidden:

curl -X POST https://exampleabc01.com -H "Contencurl -X POST https://exampleabc01.com -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden

Figure 10: Verification of Cloud Armor blocking Remote Code execution, resulting in a 403 forbidden

Serverless Architecture Controls

Hardening Cloud Run services is only one part of a secure architecture. Because these services often connect to other Google Cloud resources, a single compromise can expose additional services. Implementing defense-in-depth is critical. Specifically, when using direct VPC egress or VPC Access connectors, use VPC Service Controls to restrict lateral movement and exfiltration through granular access policies.

Secure Software Development Lifecycle (S-SDLC)

While the previously outlined hardening strategies are critical, the ideal standard remains the proactive identification of vulnerabilities during the initial development stages. A deep dive into "Shift-Left" security is beyond the scope of this analysis, which focuses on mitigating risks within existing code. However, a Secure Software Development Lifecycle (S-SDLC) remains a fundamental principle. Robust code validation and continuous security testing are essential to neutralize threats before serverless functions are published externally.

Cloud Run Threat Detection

Beyond the hardening recommendations outlined in this post, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources. These include detectors for credential access, reconnaissance, and the execution of scripts or reverse shells. The Cloud Run Threat Detection service is available for Premium and Enterprise tiers.

Conclusion

Serverless applications drive agility and rapid business value. While "vibe-coding" has made it easier than ever to deploy code, this breakneck speed demands that teams integrate security early in the development lifecycle, move beyond default configurations, and prioritize a defense-in-depth strategy centered on identity and architecture.

Acknowledgements

This analysis would not have been possible without the assistance of Ischa Rijff, Phil Pearce, and Juraj Sucik.