As threat actors increasingly use AI to accelerate and develop cyberattacks, enterprise defenders need to rely on both AI and a critical defender’s advantage: Business context that only you possess.  

Enterprise cyber defense spans identity, network, endpoint, data, cloud, and application layers, often split across a dozen or more products, each with its own context. At Google Cloud Next, we brought partner-built agents into Gemini Enterprise to give you one place to discover and deploy specialized agents across functions including sales, content and creative workflows, HR, and security. 

Today, we're expanding our catalog of partner-built security offerings in the Gemini Enterprise ecosystem to help you leverage your full security context from one unified interface.

These new security agents and integrations from leading cybersecurity vendors span two areas: partner security agents that your teams invoke directly in Gemini Enterprise, and protections for AI and agentic workloads. By bringing them into Gemini Enterprise, you can now orchestrate multi-step security workflows directly in your Gemini Enterprise environment, bringing AI-powered capabilities to your defenses.

Meet new security agents and agentic defenses built with Gemini Enterprise

Acalvio: The Acalvio ShadowPlex deception agent, accessible through Gemini Enterprise, automates the deployment of decoys and honeytokens across enterprise networks and embeds deception guardrails directly into customer’s operating environment, with no manual configuration required. ShadowPlex deploys network decoys, identity honey accounts, retrieval-augmented generation (RAG) decoys, honey skills, and honeytokens at scale, trapping unauthorized interactions quickly.

Britive: The Britive Emergency Termination Agent, built on Gemini Enterprise, lets security teams contain a compromised human or non-human identity from a single natural-language request instead of working across multiple consoles. The agent confirms the identity, lists all active privileged sessions, revokes all sessions with human approval, disables the identity, and gathers audit context for the incident ticket. The result is significantly lower mean time to containment (MTTC) while maintaining strict governance and least-privilege access for agents.

Check Point: Integrated with the Google Cloud Agent Gateway and Agent Registry, Check Point AI Defense Plane provides the critical security controls and visibility required for your enterprise-scale AI. It allows organizations to discover AI workloads, monitor risk posture, detect non-compliant behavior, and apply real-time guardrails against prompt injection, data exposure, and rogue agentic behavior. Managed through the Check Point Agent in Gemini Enterprise, the unified solution secures and accelerates AI workload deployments on Gemini Enterprise.

CrowdStrike: CrowdStrike Falcon® Guardian extends guardrails and runtime protection by integrating with Agent Gateway to help secure agentic workloads running in Gemini Enterprise against risks including prompt injection, sensitive data leakage, and malicious AI activity. In addition, the CrowdStrike Gemini Enterprise agent enables practitioners to interact with the CrowdStrike platform through Gemini Enterprise, bringing CrowdStrike security context into agentic investigation and response and helping orchestrate SOC workflows across numerous tools.

Cyberhaven: The Cyberhaven Linea agent brings discovery and classification of sensitive data across endpoints, cloud apps, and agentic workflows to Gemini Enterprise. Powered by Cyberhaven's data lineage model, it can turn plain-language intent into enforceable policies, monitor interactions to catch unmapped risks before they become breaches, and fast-track investigations with automated evidence. Extending across Antigravity in Gemini Enterprise, the Linea agent can eliminate alert fatigue and empowers security teams to protect sensitive assets as fast as autonomous agents move them.

Cyera: Cyera Agent Guardian, built on Gemini Enterprise, secures agents that run on Gemini, providing data security posture management (DSPM) and data loss prevention (DLP). The Cyera agent can correlate machine identities, delegated permissions, and sensitive data classification to verify authorized agentic behavior, so organizations can deploy agents safely and maintain operational compliance at enterprise scale.

Endor Labs: Endor Labs AURI agents bring AI-native application security across the developer and security workflow. Its Static Application Security Testing (SAST) triage agent can automatically classify and prioritize code findings inside developer platforms like Google Antigravity. In Gemini Enterprise, security teams can query and act on those findings conversationally, confirming what's actually exploitable and tracking fixes, all grounded in the Endor Labs application context.

Exabeam: With Gemini Enterprise as its foundation, Exabeam is introducing the next generation of Exabeam Nova, a unified multi-agent AI system that helps security teams investigate and respond to threats faster. Nova coordinates specialized AI agents that can analyze behavior, prioritize risk, conduct investigations, and guide response actions while maintaining a shared operational context across the entire workflow. The result is a more intelligent and efficient analyst experience that helps organizations get greater value from their existing security operations environment.

Fastly: The Fastly Autonomous Edge Defense Agent (AEDA) can help security teams investigate edge and infrastructure incidents in plain language inside Gemini Enterprise, instead of manually parsing logs. AEDA pairs an organization's own telemetry with anonymized intelligence from Fastly's global customer base, determining in seconds whether an anomaly is isolated or part of a broader attack, returning evidence-backed findings with a recommended fix.  

Fortinet: Fortinet FortiAIGate delivers large language model (LLM) runtime protection for Google Cloud customers. Integrated with the Gemini Enterprise and deployed in your Google Cloud environment, FortiAIGate can empower organizations to deploy sophisticated, agentic AI applications so that their data, prompts and model interactions are actively protected against emerging threats.

Menlo Security: HEAT Shield Agent, built withGemini, analyzes web content and blocks zero-day threats and prompt injection at runtime. Alongside it, Menlo Security Orchestrator — built on Gemini Enterprise — turns security operations center (SOC) responses into natural-language, agentic workflows. It can reconstruct attacks, identify blast radius, and enforce policy in seconds, not hours. Menlo Agent Runtime Security (MARS) closes the loop, protecting human and agent-to-agent interactions so detection and containment stay unified across agentic workloads.

Obsidian Security: Obsidian Security's Risk Analyzer and Breach Response agents on Gemini Enterprise can help security analysts assess risk and respond to breaches. Built to secure an organization's cloud and AI-native application portfolio, Obsidian agents discover AI agents across enterprise environments, assess the risk, flag governance gaps, and answer critical questions like which agents hold escalated privileges or write access. 

Palo Alto Networks: Palo Alto Networks’ Cloud, Network, and AI Risk Assessment (CLARA) agent can help security teams protect critical data and compliant AI operations, without slowing down the pace of development. It can find and fix cloud and AI risks before they become breaches by continuously scanning cloud infrastructure and AI workloads, automatically surfacing hidden vulnerabilities and prioritizing fixes so security teams spend less time hunting for threats and more time closing them.

Ping Identity: With Ping Identity's new PingID self-service agent, now available in Gemini Enterprise, employees can resolve common identity and device issues, including multi-factor authentication (MFA) resets and device recovery, by asking in natural language — no help-desk ticket required. Built on PingOne with secure delegated authentication, the PingID self-service agent gives IT teams an enterprise-ready way to manage workforce identities while reducing support costs and improving onboarding experience.

Qualys: Qualys ROCky for Gemini Enterprise can help security teams manage and patch vulnerabilities using conversation inside Gemini Enterprise. Ask, "How exposed are we to Log4Shell," "What should we fix first," or "Are we meeting our CISA KEV deadlines," and get answers ranked by the Qualys TruRisk score. It runs on each user's own Qualys entitlements so anyone can self-serve answers without help. It can also stage and deploy the patch.

Splunk, a Cisco company: The Splunk Security AI agent, integrated with Gemini Enterprise, functions as an autonomous system that converts massive telemetry streams into real-time intelligence across security and observability data. By bypassing manual triage to instantly surface critical anomalies and system threats, it shifts teams from reactive investigations to proactive defense, lowering cognitive load during high-pressure incidents and enabling security teams to resolve risks faster.

Synk: Every enterprise building with Gemini Enterprise and Antigravity is shipping code faster than ever, and Snyk makes sure that code is secure from the moment it's written, not after. Snyk validates what AI agents generate in real time, catching vulnerabilities and insecure dependencies before they ever reach a repo. It's security built for the speed AI writes code, not the speed humans used to.

Thales: The Thales AI Security Fabric, integrated with Gemini Enterprise, can provide visibility, runtime protection, and centralized governance across agentic AI interactions. Organizations can move agentic AI from pilots to production, enforcing fine-grained access policies and protecting critical data assets right where they run.

Transmit Security: Transmit Security Agent Intelligence built with Gemini Enterprise identifies agentic activity interacting with customer-facing applications. As users increasingly delegate tasks, transactions, and authority to AI agents, organizations need clear visibility into what that activity is, its origin, and its intent. That context allows businesses to distinguish good agents from malicious ones, decide what to allow versus block, and stay ahead of the risk without restricting legitimate commerce.

Zscaler: Zscaler Risk360 provides a comprehensive, actionable framework that ingests data from existing Zscaler deployments to quantify cyber risk, create a detailed view of risk posture, and deliver clear insights to reduce risk. The Risk360 Agent is an AI-powered companion built on the ZAgent Framework with Gemini Enterprise, using natural-language interactions to unify Zscaler and partner signals, analyze Zero Trust risk, quantify financial exposure, recommend mitigations, and deliver decision-ready insights.

With this growing ecosystem of partner-built agents and connectors, Gemini Enterprise works with the security tools you already use — and lets you build custom agentic workflows on top of them. You can explore the security agents available in the Google Cloud Marketplace today.

route_refund combines the records and returns the case with one of three route names: AUTO_APPROVE, DENY, or MANUAL_REVIEW. Manual review handles cases that meet neither automatic rule.

This is a deterministic router: the same case data produces the same decision, and we can test the policy without calling a model.

Both routers choose among defined paths. An agent router can sit inside a static graph: the model's choice varies, while the possible connections stay the same.

For an automatic approval or denial, the next step is to explain the decision to the customer. We give each route a notice agent that writes the reply from the case data. ADK passes the dictionary in Event(output=case, ...) to that agent as a JSON user message:

The first chain fetches the records, joins them, and applies the policy. The second maps the router's decision to a destination. Automatic decisions go straight to a notice agent; MANUAL_REVIEW goes to the human-review node we'll define next.

That third branch needs more than another function call. A reviewer may take minutes or days to answer, so the workflow must pause with the case pending and continue once the person decides.

The review node yields RequestInput, which records the pending request and pauses the run. On resume, rerun_on_resume=True runs the node again, with the answer available in ctx.resume_inputs:

The response schema gives the node an approve value to route on and a note to carry forward. If the reviewer declines, the notice agent receives their reason with the case. One more edge connects the review decision to the reply:

ADK ships two variants of this. The one above is the single-node pattern: the node reruns and reads ctx.resume_inputs, as in the request_input_rerun sample. The request_input sample shows the two-node variant, where one node yields RequestInput and the reviewer's answer arrives as the next node's node_input — so there is no ctx.resume_inputs to find in that file. The companion scripts linked below include the code that sends the reviewer's answer back to the run.

A Workflow is also a node. This whole refund process can become one step in a larger customer-service workflow.

Apply the same step to a batch of cases

We now have a process for one refund. Suppose a batch of cases arrives with the records already collected. Each needs the same policy check, and the number of cases changes from batch to batch. We can apply one node to every item using a parallel worker.

In ADK, parallel_worker=True runs a node once per item in an input list and collects the results in the original order. We can reuse our policy function:

Each worker receives one case, and collect_decisions receives the results as a list. No separate JoinNode is needed. The flag also works on agents—for example, to write an explanation for each case. The parallel_worker sample shows both forms.

The policy calculation here is small. Concurrency is more useful when each item waits on an API or model call, but the way inputs and results move stays the same.

The batch size can change without changing the graph. A variable amount of work still fits inside a fixed process. See the parallel worker guide for execution details.

Let results shape the next step

Our refund process has known paths, even when a batch contains more cases or a reviewer takes longer to answer. But some work only becomes clear as we investigate.

Suppose a disputed refund reveals a second transaction. Checking it raises a delivery question that needs further investigation. Now each result can create follow-up work. A dynamic node can examine those results and schedule the next checks in Python.

ADK provides ctx.run_node to run another node and await its result. To see how that changes orchestration, let's first express our existing refund flow this way:

asyncio.gather runs the lookups together. Python combines their results, applies the policy, and runs the selected handler. use_as_output=True makes the handler's result the parent node's output without emitting it twice.

The dynamic version also adjusts the human-review node: after the answer arrives, it calls the chosen notice agent through ctx.run_node. The complete dynamic script (refund_dynamic.py) includes that variation.

In the static version, the edge list shows the branches and destinations. In this version, we read refund_flow to see them. The dynamic node guide covers this approach.

The human-review pause still works here. When the answer arrives, refund_flow runs again from the top, but completed ctx.run_node calls return their recorded outputs from session history. The lookups do not repeat, as direct function calls would. Keeping side effects inside child nodes lets completed calls replay their results when the parent resumes. Each child also gets its own trace span, and use_sub_branch=True keeps concurrent children's events on separate branches.

For this fixed refund process, the edge list remains easy to inspect. The Python version gives us a place to add the investigation logic described above: inspect a result, choose a follow-up node, and run independent checks together. A model might suggest what to investigate, while code limits the work—for example, three follow-ups per finding and two levels of investigation before human review.

Loops can still fit in a static graph. A fixed draft → check → revise process can use a conditional back-edge and a router that limits revisions. “Static” describes the possible connections; the actual path and iteration count can vary. The graph guide covers conditional cycles.

You can also place a dynamic node inside a static workflow, using Python for a stage that needs it while keeping the surrounding process visible.

Choose who decides what runs next

Start with a question: can you draw the possible workflow before the input arrives? Include branches, loops, and repeated stages. You do not need to predict the path each request will take.

Use an edge list when it makes those connections clear. Use dynamic orchestration when results create further work or Python expresses the control more naturally. A small, open-ended task may need only one agent and its tools.

In our refund workflow, the graph coordinates the lookups, code applies the policy, a person handles exceptions, and a model writes the reply. Graph engineering gives each a clear responsibility—and makes it easier to see how the process works.

Get started

• Read: the workflow guide.

• Explore: the workflow samples.

• Build: the hands-on codelab, which applies these patterns to a marathon race-day coach.

When scaling up agentic reinforcement learning (RL) and evaluation across massive parallel rollouts, frontier AI labs inevitably hit a bottleneck: Expensive GPU clusters sit idle, waiting minutes for CPU sandbox cold-starts, plus thousands of multi-gigabyte SWE-bench-style image pulls and scheduling backlogs. It’s a sandbox infrastructure problem that silently slows down your research and burns your training budget.

To solve this fundamental infrastructure bottleneck, today we are introducing GKE Agent Sandbox optimized for RL along with the Agent Sandbox RL orchestration SDK, plus native integrations for popular RL gyms and harnesses, now generally available.

As the operating system for modern AI, Kubernetes has evolved to power massive GPU/TPU training clusters and distributed inference. Now Kubernetes is expanding to drive the next AI compute frontier: agents. But unlike static workloads, agentic workloads evolve rapidly, so infrastructure must evolve just as fast. Rather than guessing at what RL researchers needed, we placed Kubernetes itself on an auto-research and verification loop driven by performance benchmarks and evaluations. We used heavy agentic benchmarks like SWE-bench to intentionally stress-test and break our own clusters. Every bottleneck that surfaced — from etcd timeouts to GPU idle spikes — was fed back into our development cycle to refine GKE’s core primitives.

This resulted in a purpose-built sandbox layer for agentic RL and eval workloads that features:

• 10x - 45x faster time-to-first-command: GKE can spin up a sandbox environment in 1–9 seconds instead of 45–85 seconds, keeping your expensive GPUs fully in use.
• Reduced tail latency: We reduced the worst-case sandbox wait times from 7.5 minutes down to under 10 seconds.
• 3x less control-plane churn: Each RL training step triggers a rollout burst, where thousands of sandboxes are requested at once. The SDK has an in-place recycling strategy that reuses pods across rollouts instead of deleting and re-creating them. That means 3x fewer pods being created, which keeps the Kubernetes API server stable under the churn.

With this new primitive, AI labs and agent-native startups can now reliably run large scale agentic RL trajectories and evals simultaneously, minimizing accelerator idle time and drastically accelerating their research velocity.

The real-world challenges of agentic RL infrastructure

Before we talk about the solution, let’s be precise about what makes agentic RL so demanding for infrastructure in the first place. In a standard agentic RL loop, an LLM policy generates actions like code snippets on GPUs and executes them inside isolated CPU sandboxes to observe a reward signal. However, when scaling up this loop to support tens of thousands of parallel rollouts, three critical infrastructure bottlenecks emerge:

1. Accelerator idle costs, i.e., time-to-first-command (TTFC) and the tail latency trap: Agentic RL is a batch workload, and in a synchronous RL step, training cannot proceed until the slowest sandbox in the batch is ready. If standing up CPU sandboxes takes minutes to provision, pull images, and execute initial startup scripts, expensive accelerator capacity sits wasted.
2. Massive image cardinality: Standard container caching assumes a handful of static base images. However, in agentic RL, every single task (like thousands of GitHub repositories in SWE-bench or R2E-Gym) often requires a completely distinct OCI container image. Managing thousands of unique, large images per run can lead to severe image-pulling bottlenecks and storage friction.
3. Control-plane saturation: As a bursty batch workload, agentic RL typically executes batch-size image tasks and multiple rollouts per task (e.g. 4, 8, 16 rollouts per task), pushing an already large number of images to the extreme. For instance, one public dataset we tested against has 4,578 R2E images. Assuming four rollouts per image, that means 18,312 tasks, which require 18,312 sandboxes simultaneously. Standard Kubernetes control planes degrade significantly under these burst loads. Churning tens of thousands of ephemeral pods per minute creates API-server queue bottlenecks, pod state errors and triggers false node-health evictions.

These are not hypothetical problems. They are the daily reality for frontier AI labs training state-of-the-art agents. 

GKE Agent Sandbox optimized for RL

To fan-out the code execution sandboxes, we set up a relatively modest cluster — a 10-node gVisor sandbox pool with GKE image streaming enabled, the Agent Sandbox controller, and an in-cluster SDK driver to claim warm pods. We tested various strategies and setups including a large number of images and high cardinality.

The infrastructure layer

GKE Agent Sandbox is the open Kubernetes primitive for secure agent execution, featuring built-in SandboxWarmPool capabilities that eliminate cold-start overhead by maintaining pre-initialized, healthy environments. By integrating SandboxWarmPool with GKE Image Streaming, we effectively support RL and eval workloads that demand high image cardinality — even with thousands of large images (>1.2GB), while delivering the exceptionally low TTFC required for responsive agentic training. Its snapshot, suspend and resume capabilities support checkpointing for error recovery, and sandbox forking for parallel agent branching logic to explore multiple trails.

This GKE primitive is already powering the agentic RL training infrastructure at Mistral AI, a frontier AI lab:

“To push the boundaries of reinforcement learning, you need infrastructure that can instantly scale to handle unpredictable demand. By leveraging GKE's high-performance Agent Sandbox for RL, we can seamlessly orchestrate hundreds of thousands of secure environments across clusters and handle spikes of over 30,000 sandboxes on a single cluster. It provides the reliable foundation we need to accelerate our model training and iteration cycles.” - Jean-Malo Delignon, Research Engineer, Mistral AI

Orchestration SDK and RL tool integrations

To help researchers harness this power without writing Kubernetes YAML or embedding custom daemons into container images, we built the Agent Sandbox RL orchestration SDK. It exposes a clean, async Python API with pluggable warm-pooling strategies tailored to your specific evaluation or RL training pattern. We also built native integrations for RL tools like Gymnasium, NVIDIA NeMo Gym, and OpenHands, with more to come.

Benchmarks: Reducing idle accelerator waste

We ran this on a 10-node gVisor sandbox pool against two workloads: a 500-image SWE-bench environment, and a harsher 4,578-image R2E corpus that does not fit in local disk.

1.TTFC and tail latency: 10x–45x faster

Concurrency ranged from 500 simultaneous tasks and sandboxes up to 18,312 (4,578 R2E images × 4 rollouts). The gain held across every setup.

How we got here. We instrumented the controller, the SDK, and the RL fleet, then ran hundreds of comparison runs against that fixed 10-node budget. Two changes produced nearly all of the gain:

• Image hydration moved off the critical path. A high-cardinality corpus far exceeds local disk, so pulling cold images mid-training creates I/O contention and multi-minute tails. The SDK plans image placement across nodes, and GKE Image Streaming plus upfront warm-pooling handle the rest — hydration finishes before the rollout ever asks for it.

• The control plane is paced. High-concurrency rollouts trigger API-server thundering herds. Agent Sandbox Controller v1.0.0 adds rate controls that bound how fast warm pools refill, keeping etcd and the API server stable through the burst.

The tuning knobs, the benchmark harness, and the load tests behind these numbers all ship in the agent-sandbox-rl example, which emits human-readable and JSON reports so you can reproduce the comparison on your own cluster.

2. 3x less control-plane and pod lifecycle churn during multi-trajectory rollouts

Raw Kubernetes recreates a pod for every trajectory step. At 18,312 tasks that inflates scheduling overhead, wastes disk I/O, and — in our large-scale tests — triggered unbounded garbage-collection loops. The SDK's in-place recycle strategy keeps the pod alive instead, running an in-pod git reset and repository checkout between rollout episodes. Pod creations drop 3.1x and the control plane stays flat through the burst.

The trade-off

Warming environments up front spends inexpensive CPU and background cluster time so that image streaming and readiness checks never land on the critical path. For an RL fleet that’s a straightforward trade: Accelerator idle time is the expensive resource, and this approach eliminates it.

One detail matters at training scale: The SDK counts and surfaces every failed sandbox as retriable rather than silently dropping it. An untracked drop is not just a lost rollout — it is reward bias.

Get started

• Build today: Explore the Agent Sandbox repository or the Agent Sandbox RL repository for the Python SDK and native integrations for RL tools including Gymnasium, NVIDIA NeMo Gym, and OpenHands.
• Push accelerator utilization further: Explore the llm-d co-operative time-slicing repository and its Snapshot Agent guide to dynamically interleave independent RL jobs onto shared physical hardware.
• Learn more: Read the official documentation on deploying secure execution environments with GKE Agent Sandbox.

Today, Google Cloud Data Agent Kit is generally available. Data Agent Kit is a free set of Model Context Protocol (MCP) tools and agent skills that lets the coding agent you already use work directly with your Google Cloud data products, whether you're using Antigravity, Claude Code, Codex, or other popular tools.

With GA, we are adding support for BigQuery Graph, Bigtable, and Managed Service for Apache Spark access to your open Lakehouse, along with dozens of quality-of-life improvements that make everyday work faster and smoother.

What is Data Agent Kit?

Coding agents have become remarkably good at writing SQL, PySpark, and pipeline code. What they don't have by default is context about your environment: which tables exist, how they're partitioned, which ones your team trusts, or why last night's job failed. Without that, even a strong agent has to work from assumptions, and you end up pasting schemas and error logs into the chat to fill in the gaps.

Data Agent Kit fills that gap with two things:

• MCP tools: Connections to more than 15 Google Data Cloud services, so your agent can inspect schemas, run queries, read job logs, and manage resources in your live environment.

• Google-authored skills: Open-source instructions from Google Cloud engineers that teach your agent data best practices, like optimizing BigQuery SQL, designing Bigtable row keys, and building dbt (data build tool) pipelines.

You can use Data Agent Kit wherever you already work: as an IDE extension for VS Code, Antigravity IDE, Cursor, and other VS Code-compatible editors; as a plugin for Antigravity 2.0, Antigravity CLI, Claude Code, and Codex; or in Cloud Shell and Cloud Workstations, where it comes pre-installed. The IDE extension also brings a lightweight version of the Google Cloud console into your editor, so you can browse data, run queries, and review your agent's work without switching windows.

How it works

Say you ask your agent, "Forecast next month's demand for our top-selling products and check whether we have enough inventory to meet it." Data Agent Kit loads the relevant skills, so the agent follows Google's best practices for the task. It searches Knowledge Catalog to find the sales and inventory tables your team trusts. It then uses MCP tools to run a forecast in BigQuery, check current stock levels in AlloyDB for PostgreSQL, and bring the combined answer back to your editor or terminal. Every step runs with your own IAM permissions.

What you can build

Data Agent Kit covers analytics, operational databases, the Lakehouse, and pipelines. Here's what that looks like in practice, starting with what's new at GA.

Analytics and graph: BigQuery and BigQuery Graph (New in GA)

Graphs are a natural way to explore relationships, like which products people buy together or how suppliers connect to your inventory. Building one usually means hand-writing CREATE PROPERTY GRAPH DDL, learning GQL, and working out which keys actually form edges.

Instead, you describe the graph you want and your agent builds it. The bigquery-graph-author skill maps your tables to nodes and edges, checks each proposed relationship against the actual data, and shows you a plan to approve before creating anything. It can even start from an ER diagram or data model you already have. The bigquery-graph-query skill then writes the GQL, and the graph visualizer in the IDE lets you click through the results.

Operational and real-time databases: Spanner, AlloyDB, Cloud SQL, and Bigtable (New in GA)

Some features have to load instantly, like a personalized feed, a live counter, or a "recently viewed" rail on your storefront. Bigtable is built for exactly that, and it rewards a well-designed row key.

With GA, Bigtable joins Spanner, AlloyDB, and Cloud SQL as a fully supported database in Data Agent Kit. The new bigtable-basics skill designs your schema around how the data will be read and flags hotspots and full table scans before you create anything. Your agent can then create the table and query it with GoogleSQL, with column families flattened into readable columns. In the IDE, you can browse Bigtable instances and tables in the catalog explorer and run queries from the SQL editor.

Lakehouse and Spark: Managed Service for Apache Spark and Lakehouse for Apache Iceberg (New in GA)

Your agent could already query the Apache Iceberg tables in your Lakehouse through BigQuery. Now it can also work with those same tables using serverless Spark on Managed Service for Apache Spark, with no cluster to manage. Each session keeps its state, so temporary views carry across statements, and you get Iceberg's full feature set, including branching, time travel, and schema evolution.

Your tables don't all have to live on Google Cloud, either. The federate-lakehouse-catalog skill connects your Lakehouse to AWS Glue and Databricks Unity Catalog, so your agent can query that data in place without building an ingestion pipeline first.

Pipelines and orchestration: dbt, Dataform, and Managed Service for Apache Airflow

Once your logic works, your agent can turn it into a pipeline that runs on its own. It writes dbt or Dataform models, then the gcp-pipeline-orchestration skill schedules them together with your notebooks as an Orchestration Pipeline on Managed Service for Apache Airflow. Pipelines can also include Gemini Enterprise Agent Platform steps, like uploading a model or running batch inference.

In the IDE, you can follow each run on a visual pipeline canvas. If a task needs attention, click Diagnose to hand its logs to your agent. Troubleshooting skills for Airflow and Spark trace the root cause and propose a fix for you to approve.

Improving the developer experience

GA also streamlines setup and day-to-day workflows. When you get started, you simply sign in once and select the Google Cloud services you use. Data Agent Kit automatically enables the required APIs, installs the matching skills, and configures your MCP servers with no manual setup files. Inside the IDE, the SQL editor and notebooks now support inline code generation, @ references to tables, and diff views for suggested changes. The extension also shares your active project, open file, and the error from the query you just ran with your agent, so asking it to "fix this query" just works.

We also made the core tools faster and more responsive. New Spark notebooks automatically create and select a Spark Connect runtime, and Spark SQL queries in the editor run in isolated sessions with built-in execution metrics. The catalog explorer now loads faster and includes BigQuery public datasets in the sidebar. Tuned notebook skills help your agent finish notebook tasks more quickly while using fewer tokens. 

Ready for the enterprise

Data Agent Kit is included at no additional cost; you pay standard pricing only for the Google Cloud services your agent uses. Skills also steer the agent toward cost-aware query patterns, like checking partition keys and running a dry run before executing a BigQuery query to avoid accidental full-table scans. And because the skills are open source on GitHub, your team can audit them, fork them, or write custom skills for your own internal standards.

For access control, the agent connects as you or as a service account you impersonate, so row- and column-level security policies apply automatically. Admins can also govern MCP access with Identity and Access Management (IAM), screen MCP traffic with Model Armor, and scope agents with VPC Service Controls and Principal Access Boundary policies.

Install and get started

You can set up Data Agent Kit in under a minute in either your IDE or your terminal.

Option 1: Install the IDE Extension

• IDE extension: Search for "Google Cloud Data Agent Kit" in the Extensions panel of VS Code, Antigravity IDE, Cursor, or any VS Code-compatible editor. You can also install it from the VS Code Marketplace or Open VSX.

• Antigravity 2.0: Go to Settings > Customizations > Build with Google Plugins, then download Data Agent Kit.

• Cloud Shell and Cloud Workstations: Already installed by default; just open the editor and sign in.

Option 2: Install the CLI Plugin

Run the command for your preferred coding agent using the official GoogleCloudPlatform/data-agent-kit-plugin repository:

Then try a first prompt:

Next steps & hands-on resources

• Read the docs: Explore the Data Agent Kit documentation and product overview page.

• Explore the skills: Browse, star, and contribute on GitHub.

• Build an analytics workflow: Try the Analytics with Data Agent Kit and Antigravity IDE codelab, and read the companion blog, Agentic analytics with the Data Agent Kit.

• Build a data science pipeline: Try the Fraud detection pipeline with Data Agent Kit and Antigravity IDE codelab.

Written by: Robin Grunewald, Supriya Mazumdar, Kelli Vanderlee

Introduction

Google Threat Intelligence Group (GTIG) examines vulnerability disclosure and exploitation statistics to evaluate the impact of artificial intelligence (AI) on the vulnerability threat landscape. We found that AI is measurably changing not just the pace of vulnerability discovery and exploitation, but also the types and typical risk profiles of vulnerabilities that are being discovered.

Key findings: 

• Vulnerability disclosures doubled: the number of vulnerabilities disclosed per month doubled, rising from 5,045 in January 2026 to 10,477 in July and continuing to climb to 10,740 in August 2026.

• Vulnerability exploitation nearly doubled: the number of vulnerabilities exploited increased from an average of 10.5 per month in 2025 to an average of 18 per month from January 2026 to August 2026.

• Zero-day exploitation increased marginally: zero-day vulnerability exploitation grew from an average of 8 per month in 2025 to an average of 11 per month from January 2026 to August 2026.

• AI finds more consequential vulnerabilities: AI-assisted discovery found proportionally fewer Low-Risk vulnerabilities, more Moderate-Risk vulnerabilities, and more vulnerabilities leading to remote code execution (RCE).

GTIG expects that vulnerability discovery and exploitation will continue to grow in the short to medium term. To counter the increased risk from rapid vulnerability discovery and exploitation, organizations must transition from unprioritized mass-patching to threat-intelligence-driven triage, combining targeted edge-defense with automated, agentic remediation.

Scope & Methodology

This GTIG analysis examines trends in vulnerabilities disclosed from January 1, 2025 through August 31, 2026. The dataset tracks the vulnerabilities alongside critical operational dimensions, including exploitation consequences and GTIG Vulnerability Risk Ratings, and in-the-wild exploitation. When we refer to risk ratings in this blog, we are using GTIG vulnerability risk ratings, not CVSS severity.

While the baseline monitoring encompasses the full 20-month window (January 2025–August 2026), this report specifically focuses on growth velocity and emerging threat vectors.

The research seeks to evaluate the impact of AI across the cybersecurity landscape both in terms of rates of Common Vulnerabilities and Exposures (CVE) disclosure and rates of exploitation. We also examine vulnerabilities targeting the AI/large language model (LLM) operational stack.

CVE Disclosure Doubled in 2026 

Vulnerability disclosures doubled from 5,045 in January 2026 to 10,477 in July, with the count of disclosed vulnerabilities reaching a peak of 10,740 in August (Figure 1). 

Distinguishing Threat Risk from CVE Inflation

However, raw disclosure volume throughout 2026 can be misleading without threat intelligence context. Automated CVE Numbering Authority (CNA) assignment policies across open-source ecosystems can inflate baseline figures; for instance, vulnerabilities with a description containing “Linux Kernel” alone generated approximately 5,000 CVEs between January 2026 and August 2026 with zero observed exploited in-the-wild zero-days.

In terms of risk ratings, the most interesting increase occurred in High-Risk vulnerabilities, which surged from 131 disclosures in January 2026 to 350 in August 2026, a 167% growth (Figure 2). High-Risk vulnerabilities remain a small proportion (3% in August 2026) of all vulnerabilities disclosed.

The increase in High-Risk vulnerabilities throughout 2026 was driven by two compounding dynamics: a widening pool of affected vendors and concentrated vendor disclosure cycles. Across the broader software ecosystem, baseline High-Risk disclosures more than doubled over the past year, rising from ~65/month in mid-2025 to ~135/month in mid-2026 (Figure 3). On top of this elevated baseline, Figure 3 highlights two time frames in which particular vendors reported exceptionally high quantities of CVEs,  pushing monthly volumes to historic peaks:

• TOTOLINK: In April and May, mass research disclosures against consumer router firmware added 75 High-Risk flaws, driving the mid-year spike in Command Execution vulnerabilities.

• Oracle & Linux: In June, July, and August Oracle’s quarterly Critical Patch Update (CPU) across middleware like WebLogic and Coherence combined with Linux kernel network driver advisories to contribute 128 High-Risk vulnerabilities in August alone (nearly 37% of all High-Risk disclosures), directly fueling growth in Remote Code Execution vulnerabilities.

In-the-Wild Exploitation

From January 2026 to August 2026, GTIG recorded 141 distinct vulnerabilities disclosed and exploited, surpassing the total number of vulnerabilities exploited for the full year of 2025 (127). In-the-wild exploitation increased from an average of 10.5 per month in 2025 to 18 per month in 2026. However, it is important to note that the proportion of vulnerabilities exploited versus disclosed remains vanishingly small: only 0.23% of all disclosed vulnerabilities in 2026 (roughly 1 in 431) were ever observed in active exploitation, or on the order of tens versus thousands per month. This means that monthly exploitation counts can more easily be influenced by other factors such as vendor disclosure cycles and threat actor campaign spikes. Since May 2026, a shift has emerged, with the expansion of CVE exploitation (+127% indexed growth) closely mirroring disclosure growth (+128% indexed growth), scaling in tandem with the overall vulnerability landscape rather than outpacing it.

Zero-Day Exploitation Remains Stable

The count of zero-days exploited increased marginally from an average of 8 per month in 2025 to an average of 11 per month in 2026. While the number of zero-days identified per month remained near baseline levels (between 8 and 12) through mid-2026, in August, the count jumped to 22  (Figure 4). Zero-day exploitation also continues to represent a very small proportion of all vulnerabilities disclosed, though it still constitutes the majority (62%) of all observed exploited vulnerabilities from January 2026 to August 2026. 

Are Threat Actors Finding More Success with Exploiting N-Days?

It is possible that threat actors are finding it more accessible or efficient to use LLMs and AI tools to automate analysis of differences between product versions, patches, vulnerability disclosure announcements, and Proof-of-Concept (POC) code to rapidly weaponize n-days, rather than to discover new zero-days. 

CVE Exploitation Trends Toward Higher Risk Vulnerabilities

With zero-day exploitation rates increasing only marginally, we suggest that the primary source of growth in vulnerability exploitation from January 2026 to August 2026 has been concentrated in the rapid weaponization of n-days. Significantly, exploitation of High-Risk vulnerabilities more than doubled from 28 in 2025 to 75 from January 2026 to August 2026.

Exploitation by Attack Surface

Vulnerabilities affecting Edge and Security Appliances represented 14% of vulnerabilities exploited from January 2026 to August 2026, while 11% affected Enterprise Directory & Collaboration hubs. Edge gateways represent a premier initial-access vector: over 65% of edge flaws exploited from January 2026 to August 2026 met High/Critical Threat Risk ratings, with adversaries aggressively targeting unauthenticated public management interfaces to capitalize on enterprise EDR agent blind spots.

While CVE discovery volume metrics surge, adversary exploitation activity remains concentrated in perimeter appliances and exposed enterprise services.

Comparing Growth Rates For Specified Categories

Plotting raw monthly counts hides relative momentum due to the vast disparity between single-digit zero-day discoveries and more than 10,000 vulnerabilities disclosed in the month of August, for example. To enable a direct comparison of growth rates across vulnerability tiers, Figure 7 indexes four metrics to a baseline of 0 in January 2025 and provides a trendline of the three month rolling average growth rate:

• Overall CVE Disclosure (128%): As previously stated, raw counts of CVE disclosures doubled from January 2026 to August 2026. The three month rolling average growth rate suggests that CVE disclosures have steadily accelerated in 2026. 

• High-Risk Vulnerabilities Disclosed (241%): Demonstrated the steepest growth across the dataset, climbing to almost a 3.5x its initial baseline (a +241% increase) by  August 2026. Excluding Linux, Oracle, and Totolink, the rate of increase was just 128% from January 2025 to August 2026. 

• CVE Exploitation in the Wild (127%): From January to August 2026, CVE exploitation has increased at approximately the same rate as overall CVE disclosure, though the three month rolling average trendline suggests that growth in exploitation did not begin to pick up until the second quarter of 2026. 

• Zero-Days Exploited (59%): While remaining near baseline levels (between 8 and 12 zero-days per month) through mid-2026, in August, the count reached 22. This increase is reflected in the three month rolling average growth rate, which began to reveal an upward trend in the summer of 2026. 

This clear visual divergence underscores that the moderate increase in vulnerability exploitation in 2026 is driven by the rapid, targeted weaponization of high-risk exploits in the wild vulnerabilities rather than a flood of new zero-days.

AI as the Hunter: AI-Assisted Vulnerability Discovery

Detection Methodology & Attribution Realities

Current public data significantly undercount vulnerabilities discovered by AI due to two structural dynamics:

1. Absence of Standardized Metadata: Public CVE repositories do not yet feature uniform metadata tags for AI attribution, requiring manual heuristic tracking.

2. Silent First-Party & Cloud Patching: Major cloud and SaaS providers routinely remediate AI-surfaced vulnerabilities directly in production without requesting formal CVE IDs, as CVE assignments are typically reserved for on-premise or third-party software requiring customer patching coordination. Many findings also remain embargoed for a period during established Coordinated Vulnerability Disclosure (CVD) windows.

However, we can identify vulnerabilities likely surfaced by autonomous agents using a multi-tier verification process:

1. Verified Lab & Vendor Ledgers: Directly ingesting confirmed disclosures from frontier AI research programs.

2. Advisory & Release Parsing: Programmatically monitoring Cybersecurity and Infrastructure Security Agency (CISA) advisories, MITRE records, and vendor security bulletins for explicit acknowledgments attributing root-cause discovery or PoC synthesis to autonomous AI agents (e.g., Hacktron AI, AISLE).

Risk Profile Divergence: AI vs. Conventional Discovery

Analyzing disclosed vulnerabilities we were able to identify as likely AI discovered suggests a structural divergence from conventional human and scanner discoveries. AI agents have been used to surface proportionally fewer Low-Risk vulnerabilities, and proportionally more Medium- and High-Risk vulnerabilities.

Table 1: Share of vulnerabilities per risk rating  - AI vs. Non AI discovery - Jan to August 2026 (Source: GTIG)

Conventional CVE disclosures are dominated by low-severity findings (69% Low Threat Risk, 28% Medium). In contrast, AI-discovered vulnerabilities invert this distribution: 58% qualify for Medium Threat Risk (more than double the baseline), while low-risk findings drop to 39%.

This distribution largely likely reflects how research programs scope and deploy these systems. Rather than running broad, automated scans for cosmetic flaws or compliance warnings, researchers deliberately prompt and task autonomous agents with auditing critical infrastructure and sensitive privilege boundaries, focusing on high-impact findings. Mandiant has described similar findings when using a specialized Agentic Vulnerability Discovery Harness (AVDH) in point-in-time assessments of client codebases.

Divergence between AI-discovered vulnerabilities and vulnerabilities not discovered by AI is also apparent in terms of exploitation consequences. Exactly 50% of all AI-discovered vulnerabilities result in Remote Code Execution (RCE), compared to just 26% across the broader CVE ecosystem. Conversely, AI agents under-index in lower-impact categories, surfacing less than half the rate of Information Disclosure (8% vs. 18%) and Data Manipulation (5% vs. 9%) as vulnerabilities not identified as discovered by AI.

This concentration on code execution likely stems from how frontier agents operate. Autonomous systems are engineered to navigate complex, multi-step semantic code paths across core C/C++ libraries, runtimes, and hypervisors. By synthesizing fuzzing harnesses, modeling memory states, and chaining obscure edge-case logic, AI models excel at identifying memory corruption (buffer overflows, use-after-free) and logic bypasses that consistently elude traditional static analyzers.

While currently an early indicator rather than an established trend, confirmed exploitation of AI-discovered vulnerabilities demonstrates that increased risk from AI-discovered flaws is not purely theoretical.

A notable case is CVE-2026-1731, an unauthenticated OS command injection flaw in BeyondTrust Privileged Remote Access (PRA) and Remote Support that was discovered autonomously by a third-party research agent (Hacktron AI). Following public disclosure, GTIG observed threat actors weaponize this vulnerability in targeted initial-access campaigns to bypass enterprise perimeters. More specifically, within four days of public disclosure, GTIG observed a threat cluster exploiting this vulnerability, followed by five additional threat clusters within seven days of public disclosure. GTIG observed these threat actors collectively conduct a variety of post-exploitation activities, including privilege escalation, data exfiltration, and dropping secondary payloads including SNOWLIGHT, SPARKRAT, and cryptominers. This operational collision highlights that defensive AI agents are uncovering high-impact vulnerabilities that threat actors actively seek to exploit.

AI as the Hunted: Vulnerabilities Targeting the AI/LLM Operational Stack

Architectural Breakdown of AI Stack Vulnerabilities

As enterprise adoption of generative AI accelerates, security research and adversary interest have also focused on vulnerabilities in the underlying AI operational stack. Across the January 2025–August 2026 monitoring window, GTIG tracked 2,076 cumulative AI-related CVE disclosures, with over 1,500 vulnerabilities identified from January 2026 to August 2026 alone across eight core architectural layers:

Table 2: Break down of vulnerabilities targeting AI systems (Source: GTIG)

Emerging Battlegrounds: Orchestration & Inference

From January 2026 through August 2026, disclosures of AI application vulnerabilities were heavily concentrated in three core areas: agent orchestration frameworks, backend serving infrastructure, and enterprise AI gateways:

• Agent Orchestration as the Primary Chokepoint: Orchestration middleware accounts for 50% of all AI-related flaws, experiencing a +347% surge in disclosures in 2026. Visual workflow builders (e.g., Flowise, Langflow) and autonomous frameworks often deploy dynamic code execution nodes to facilitate environment interaction. Attackers exploit these nodes via prompt injection or crafted workflow JSONs to hijack execution loops, turning natural language prompts into unauthenticated Remote Code Execution.

• Centralized AI Gateways and Lateral Cloud Movement: Enterprise AI gateways represent a catastrophic dual-threat vector. At the application layer, compromised gateways expose third-party application programming interface (API) keys and private prompt streams containing personally identifiable information (PII) or proprietary source code. At the infrastructure layer, they act as initial footholds for adversaries to harvest database credentials and pivot laterally into internal cloud environments.

• Inference Gateways as the New Perimeter: Disclosures across backend serving infrastructure (e.g., vLLM, Triton, LiteLLM, Ollama) reached 212 vulnerabilities in 2026. Nearly a quarter (24%) of these flaws stem directly from unauthenticated API endpoints or Server-Side Request Forgery (SSRF), providing remote adversaries with direct entry points to bypass perimeter firewalls, exhaust expensive GPU compute resources, or extract proprietary model checkpoints.

Active In-the-Wild Exploitation of AI Middleware

While zero-day exploitation of AI infrastructure has not yet been observed, threat actors are actively weaponizing newly disclosed vulnerabilities in exposed middleware. However, out of 2,076 cumulative disclosures, only a handful of vulnerabilities have been confirmed as exploited in-the-wild. Among the examples, we identified several that we rated High Threat Risk and provide unauthenticated RCE, command injection, or arbitrary file writes:

1. CVE-2026-42271 (BerriAI LiteLLM): Command injection in Model Context Protocol (MCP) server preview endpoints (POST /mcp-rest/test/connection), resulting in host takeover and API credential theft.

2. CVE-2026-5027 (Langflow): Path traversal file write in the POST /api/v2/files upload handler, allowing remote threat actors to drop unauthorized files (e.g., cron jobs, Secure Shell (SSH) keys) onto the host.

3. CVE-2025-3248 (Langflow): Unauthenticated Python code injection via exec() in /api/v1/validate/code, permitting immediate RCE.

Outlook

GTIG expects that rates of vulnerability discovery and exploitation are likely to continue to increase in the short to medium term. In other research, such as our May AI Threat Tracker, we reported the first known case of a threat actor in possession of a zero-day exploit script developed with generative AI. While intercepted during operational planning before in-the-wild execution, analysis of the exploit's structural artifacts revealed high-confidence LLM generation markers. In our September AI Threat Tracker, we further noted threat actors sharing resources and prototyping agentic vulnerability discovery tooling.

We are still in the early days of publicly available data on both AI-augmented vulnerability discovery and vulnerabilities targeting AI infrastructure and technologies. Nonetheless, we can see emerging signals that AI is contributing to vulnerability discovery. When directed at critical attack surfaces, autonomous research agents demonstrate a formidable capacity to uncover high-severity flaws. By reasoning through complex semantic code paths and synthesizing dynamic proof harnesses, agentic workflows excel at identifying memory corruption and logic bypasses in core libraries and runtimes, surfacing the exact types of flaws that sophisticated adversaries actively seek to exploit.

As threat actors begin to exploit vulnerabilities in AI systems in the wild, organizations cannot afford to treat AI security as an afterthought. Securing this landscape demands immediate containment strategies, sandboxing autonomous agentic workloads, and implementing risk-based vulnerability management to defend the new perimeter.

At this moment, the cybersecurity community has a window of opportunity to bolster defenses on two fronts before threat actors are able to scale up zero-day and n-day exploitation. First, organizations must modernize how they triage and remediate disclosed vulnerabilities. In a separate blog post, Mandiant laid out a blueprint for implementing AI-Assisted Vulnerability Management to help defenders counter compressed adversary timelines. Second, organizations that provide software or services to other enterprises and consumers, should proactively run AI-enhanced code review internally to identify and fix flaws before they are shipped to production and become exploitable vulnerabilities. Leveraging agentic defensive capabilities, such as CodeMender, integrated into Google AI Threat Defense, to continuously audit and patch code across developer workflows will be vital. If pre-release AI code review becomes standard best practice, the rate of growth in public vulnerability disclosures could eventually slow.

※この投稿は米国時間 2026 年 9 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

先週の Gemini 3.8 Live と Gemini 3.8 Live Extended Thinking の発表に続き、Gemini 3.8 Live with Live Avatar が Gemini Enterprise で一般提供されることになりました。Google Cloud Next 2026 で初めてプレビューされたこのテクノロジーは、企業の本番環境に正式に対応しました。

企業の音声 AI が基本的な速度やコストの指標を超えて進化するにつれ、Google の優先事項は、各インタラクションの品質をさらに高めることに移っています。Gemini 3.8 Live は、ネイティブの音声間基盤により、流暢で応答性の高い会話を実現しています。Live Avatar 機能は、ウェブ、モバイル、インタラクティブ キオスクなどの会話型動画エージェントに、視覚的なインタラクションと確かな存在感をもたらします。これにより、以下の機能を利用できます。

1. 動画アバター: Live Avatar 機能を使用した会話型動画では、リップシンクが同期された動画アバターを生成できます。注: カスタム アバター機能は、許可リストに登録されている場合にのみ利用できます。

2. 流暢な対話: ネイティブな音声間対応により、会話の文脈やバックエンドの処理を途切れさせることなく、ユーザーからの割り込みにもより自然に対応できます。

3. ツール呼び出し: 会話を続けながら、バックグラウンドでツールと API 呼び出しを実行します。これにより、モデルはリクエストを認識し、バックグラウンドでタスクが完了するまでチャットを続けることができます。

4. 言語の壁を打破: Gemini 3.8 Live は 97 の言語を理解して話すことができ、言語の自動検出にも対応しています。

5. ユーザーの視界をエージェントと手軽に共有: Live の視覚理解機能により、ライブカメラのフィードや画面共有を、音声と同時にすべてリアルタイムで処理できます。

Gemini 3.8 Live Extended Thinking は限定公開プレビュー版のままですが、Gemini 3.8 Live with Live Avatar が利用可能になりました。米国と EU のエンドポイントで提供され、プロビジョンド スループット、エンタープライズ コンプライアンス、厳格なデータ ガバナンスを備えています。Gemini Enterprise でモデルとその機能をお試しいただき、API を使用して今すぐ構築を始めましょう。

信頼と透明性を重視

アイデンティティの保護と不正利用の防止のため、お客様は厳選された事前構築済みアバターのライブラリからデプロイできます。一方、カスタム アバターの作成には、厳格なエンタープライズ許可リストへの登録と身元確認プロセスが必要となります。さらに、生成されたすべての音声ストリームと動画ストリームには、人間には感知できない SynthID の透かしが埋め込まれており、AI 生成コンテンツの透明性と検証可能性が確保されています。

Gemini 3.8 Live と Live Avatar の 3 つのデモ

1: インタラクティブなカスタム アバター

^{インタラクティブなカスタム アバターを段階的に作成}

Gemini 3.8 Live で、システム指示を追加し、参照用の写真と音声ファイルのサンプルを 1 つずつアップロードすることで、カスタム アバターを作成する方法をご覧ください。

2: 音声優先の保険金請求受付におけるライブ動画の理解

^{Gemini 3.8 Live を使用したライブ動画の理解により、請求の受付を効率化}

このデモでは、Gemini 3.8 Live を使用して、一般的なユースケースである受付エージェントを実際に作成します。このシナリオでは、保険金請求の受付エージェントを想定しています。カメラに向かって話し、損傷を映すだけで、請求ノートブックが自動的に入力されていきます。バックグラウンドでは、ADK エージェント チームがポリシーを確認し、受付ルールを適用して、アジャスター パケットを作成します。詳細については、オープンソース コードをご覧ください。

3: Google ADK と Gemini Live API を使用したリアルタイム音声 AI エージェント

^{Google ADK と Gemini Live API を使用してライブ音声エージェントを構築}

デベロッパーが Agent Development Kit（ADK）を使用して、エージェントの定義、ランナーとセッション メモリの管理を行い、従来の音声文字変換パイプラインを介さずに、リアルタイム音声を Gemini Live API へ直接ストリーミングする方法をご覧ください。

Gemini 3.8 Live with Live Avatar を活用したイノベーションの事例

※この投稿は米国時間 2026 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

通信業界は現在、従来の人間による手動運用から、完全な自律型ネットワーク運用へのパラダイム シフトを経験しています。最新のネットワークは複雑性、異種性、大規模性を増しているため、運用の自動化を実現するには、手動で設定したルールによるルールベースの手法や従来型の機械学習（ML）手法だけでは不十分です。従来の ML は大量の構造化データから微妙なパターンを特定してきめ細かな予測を行うことができる一方、データとそれが示すシステムを理解して推論し、最終的に人間のオペレーターと同じような意思決定を行う能力はありません。

AI エージェントの成長とその推論能力は、この課題に対する有望な解決策となります。しかし、人間のオペレーターが大規模なネットワーク中に作成された数十億のデータポイントに分散した統計情報を直接取り込むことができないのと同様に、AI エージェントにもそのような規模のネットワークを運用する能力はありません。この課題に対処するために電気通信事業者が採用しているのがグラフ ニューラル ネットワーク（GNN）です。GNN は、大量の時間データやリレーショナル データをネイティブに処理するように設計された最新の ML です。電気通信事業者は、GNN を AI エージェントと統合することで、根本原因分析、キャパシティ プランニング、トラフィック予測、What-If 分析、リアルタイムの異常検出などの高度な診断を、これらの分析情報を解釈して正当なアクションを実行するために必要な推論能力と組み合わせて利用できます。この強力な組み合わせにより、ネットワークを TM Forum が定義するレベル 5 の自律性（システムが自律的に動作する状態）に安全に移行させることが可能になります。

この投稿では、Google Cloud の自律型ネットワーク運用フレームワークを強化する 3 つのコンポーネント（データ、ML、AI）を紹介します。

基盤: Spanner Graph 上のデジタルツイン

Google Cloud の自律型ネットワーク運用フレームワークの中核となるのは、ネットワーク デジタルツインです。これは、稼働中の通信ネットワークをリアルタイムで継続的にミラーリングし、細部にわたって忠実に再現する仮想レプリカです。静的なモデルではなく、進化し続けるコンポーネントの状態と関係を経時的に捉える、動的な時系列ネットワーク グラフとして表現されます。このアーキテクチャ アプローチにより、オペレーターは過去に「戻って」過去のデータで ML モデルをトレーニングおよび評価できると同時に、レベル 5 の自律性を実現するために必要な基本的な運用知識を AI エージェントに提供できます。デジタルツインは、提案されたネットワーク変更の影響をこのデジタル環境内でシミュレートすることで、信頼性の重要なレイヤを確立し、AI エージェントが自信を持って将来の状態を設計し、ネットワークの問題を自動的に解決できるようにします。

Google Cloud の Spanner Graph はこのデジタルツインをホストするのに最適なサービスですが、その理由は以下のとおりです。

• スケーラビリティと可用性: Spanner Graph は、最新のアプリケーションに妥協のない基盤を提供します。ネットワークの成長に合わせて事実上無制限にスケーリングでき、RPO と RTO はともに 0 であると同時に、99.999% の可用性を保証します。

• マルチモデルのサポート: 単一のプラットフォームで複数のデータモデル（リレーショナル、グラフ、ベクトル、全文検索）をサポートしているため、グラフ走査と最近傍ベクトル検索を組み合わせるなど、複雑な構成の構築が可能です。

• グローバルな整合性: Spanner は、グローバルに整合性のあるネットワーク ビューを提供し、システム開発を簡素化します。

次の図は、ルーター、インターフェース（物理ポート）、VPN（L3VPN サービス インスタンス）、フロー（アクティブなトラフィック セッション）の 4 種類のノードを含むネットワーク トポロジを示しています。これらは、ネットワーク スタック全体をキャプチャする有向エッジによって接続されます。接続の種類としては、ルーターとインターフェース間の物理的封じ込め、インターフェース間の物理リンク、OSPF/iBGP を介したルーター間のコントロール プレーン ピアリング、ルーターと VPN 間のサービス メンバーシップ、フローとインターフェース間およびフローと VPN 間のトラフィック アンカリングが挙げられます。

ML レイヤ: Distributed Graph Flow（DGF）

ネットワークの動作と反応を予測するために、デジタルツインは Distributed Graph Flow（DGF）を活用した ML レイヤを利用します。このレイヤは、Spanner Graph 内にホストされている膨大な量の過去の構造化データでトレーニングすることで、重要な予測的分析情報を引き出します。これにより、人間のオペレーターと AI エージェントは、事後的ではなく事前的にネットワークを管理できるようになります。

先日オープンソース化された DGF は、GNN モデリングのエンドツーエンドのライフサイクル全体を管理するために設計された Python ライブラリです。Google CoreML と Google Research によって開発されたこのライブラリにより、Google Cloud の企業クライアントは、Google が 10 年にわたり開発してきた社内ツールと専門知識を直接活用できるようになります。さまざまなエンジニアリング ニーズに対応するこのライブラリは、高度なチーム向けに高性能でコンポーズ可能な低レベル プリミティブを提供するほか、GNN の専門知識なしで迅速な開発を行うためのシンプルな API も提供しています。

たとえば、高レベル API を使用して GraphFlow で GNN モデルをトレーニングして評価する場合、次のように 5 行のコードを記述するだけで済みます。

DGF は、自律型ネットワーク運用要件に直接マッピングされる最上位概念を提供します。

ユースケース

DGF と GNN を活用する電気通信事業者は、複数の高度なユースケースを通じて、事後保守から予防保守へと移行できます。

• 異常検出: GNN は、過去のパターンと現在の状態をカプセル化したノードとエッジのエンベディングを生成します。異常なエンベディングは、サービスの低下につながる前に調査対象としてフラグが立てられます。

• 根本原因分析（RCA）: DGF は、特定の郵便番号での「接続失敗」など、インシデントに関連するネットワーク インスタンスのみを含む特定のサブグラフを出力できます。グローバル ネットワーク全体をスキャンする必要性がなくなるため、トラブルシューティング エージェントは、分析を高速で実行できます。

• 予測メンテナンス: システムは、高速移動する機器の「ハンドオーバー障害」など、デバイスの障害やエッジの切断の可能性を予測し、プロアクティブなロード バランシングやルート変更を可能にします。さらに、エージェントを組み合わせることで、「人間関与型」や「人間参加型」を採用して修復アクションを自動化できます。

• What-If 分析: GNN を使用すると、電気通信事業者はファイバーの切断、トラフィックの急増、デバイス構成の変更などのシナリオをシミュレートできます。GNN は、トポロジカルな依存関係をモデル化することで、こうした局所的な変化がネットワーク全体にどのように伝播するかを予測できるため、エンジニアはリスクのないデジタル環境で復元力をテストし、緩和戦略を評価できます。

シナリオ: GNN と DGF を使用した根本原因分析

デジタルツインを作成したら（サンプルコード）、以下の簡単な 5 ステップのプロセスで、GNN と DGF を使用した根本原因分析（RCA）検出を実装できます。

1. デジタルツインに接続する: DGF Spanner Graph コネクタ（dgf.io.read_spanner_graph）を使用して、Spanner Graph のデジタルツインから DGF 環境にネットワーク トポロジを直接読み込みます。

2. 教師ありノード（またはエッジ）予測モデルをトレーニングする: トレーニング データと目的に応じて、教師ありノード予測モデルをトレーニングしてターゲット ノードの特徴を予測するか、エッジ予測モデルをトレーニングして根本原因エンティティ ノードと影響を受けるエンティティ ノード間のエッジを予測します。指定されたサンプルデータに対して、高レベルの dgf.learning.train_node_model API を使用して、教師ありノード予測モデルをトレーニングします。

3. ノード予測モデルを使用して根本原因ノードを予測する: ノード予測モデルを直接使用して、異常のあるノードへの影響スコアを予測できます。異常の影響を受けるエンティティ ノードのうち、予測される影響スコアが最も高いものが根本原因の最有力候補となります。

4. Gemini Enterprise Agent Platform（旧称 Vertex AI）にデプロイする: モデルをエクスポートして Gemini Enterprise エンドポイントにホストし、スケーラブルかつ低レイテンシの予測を可能にします。

5. リアルタイム推論: 異常の日付を入力として、推論エンドポイントに予測呼び出しを行います。エンドポイントは、予測された根本原因のエンティティ ノードを返します。

使ってみる

Distributed Graph Flow を使用した GNN のネットワーク運用への統合は、単なる技術的なアップグレードではなく、通信業界の重要な進化です。GNN を活用した自律型フレームワークに移行することで、電気通信事業者はサービス停止時間を大幅に短縮し、リアルタイムで容量を最適化できます。さらに、最終的には運用効率の向上を通じて優れたカスタマー エクスペリエンスを提供することにもつながります。

独自のインテリジェント ネットワーク アプリケーションの構築を始めるには、スケーラブルな GNN トレーニングと推論に不可欠なプリミティブを提供する Distributed GraphFlow（DGF）ライブラリをご覧ください。実践演習を行う場合は、コードサンプルの手順に沿って進めます。また、当社が最近受賞したビジネスアウェア GNN ヒーリング ネットワークに関するムーンショット プロジェクトもご覧ください。自己最適化自律ネットワークに対する Google のアプローチについては、こちらのホワイトペーパーをご確認ください。