Google Cloud Updates: AI Agents, GPUs, and Security

Data centers don’t become “AI-ready” because someone adds a bigger GPU cluster. They become AI-ready when the whole stack—data, identity, orchestration, networking, and observability—starts behaving like a coordinated system.

That’s why the latest Google Cloud release notes (mid‑Nov through mid‑Dec 2025) are worth reading even if you don’t care about release notes. They show a clear pattern: AI is moving from a feature to an operating model for cloud infrastructure. Databases are getting built-in “data agents,” Kubernetes and compute are getting smarter about scarce accelerators, and security products are starting to treat AI traffic as a first-class thing to govern.

This post is part of our AI in Cloud Computing & Data Centers series, where we track how cloud providers are applying AI to infrastructure optimization, workload management, and intelligent resource allocation. Here’s what matters from this wave of updates, and how to turn it into practical decisions.

AI agents are becoming a platform primitive

The big change: AI agents aren’t being treated like “apps you deploy.” They’re being treated like services that need identity, telemetry, governance, and standardized tool access—the same way we treat APIs.

Database “data agents” are arriving across managed databases

Google introduced data agents (Preview, sign-up required) across multiple database products:

• AlloyDB for PostgreSQL
• Cloud SQL for MySQL
• Cloud SQL for PostgreSQL
• Spanner

The takeaway isn’t “chat with your database.” The takeaway is architectural:

• Your database becomes a tool that an agent can call safely.
• Teams will start exposing approved “database actions” instead of raw query access.
• The bottleneck shifts to governance and prompt safety, not connectivity.

If you’ve built internal analytics chatbots before, you know the failure mode: users get an LLM answer, you can’t trace the query lineage, and permissions are a mess. Data agents are an attempt to fix that by putting the “agent layer” closer to the database.

Tooling standardization is creeping in via MCP

A quiet but important thread: Model Context Protocol (MCP) keeps showing up.

• API hub supports MCP as a first-class API style.
• Cloud API Registry (Preview) is positioned to discover and govern MCP servers/tools.
• BigQuery adds a remote MCP server (Preview) so agents can perform data tasks.

That’s a big deal for enterprise platform teams because MCP is basically saying:

“Tools for agents should be registered, versioned, governed, and monitored like APIs.”

If you’re building agentic workflows for ops (capacity planning, incident response, or DB optimization), this is the direction to align with.

Gemini model availability is widening (and showing where Google’s focusing)

Gemini 3 Flash shows up in multiple places:

• Vertex AI: Gemini 3 Flash is in public preview.
• Gemini Enterprise: Gemini 3 Flash (Preview) toggle for admins.
• AlloyDB: Gemini 3 Flash preview supported inside generative SQL functions.

What that signals: fast reasoning + agentic workflows are becoming the default expectation. Not every workload needs the biggest model. Many infrastructure and data center automation tasks need predictable latency and good tool use.

GPU and accelerator capacity is now an engineering discipline

If 2023–2024 was “get GPUs,” 2025 is “operate GPUs like a scarce resource portfolio.” Google’s updates reflect that shift.

Future reservations for GPUs/TPUs move to GA

Compute Engine future reservation requests in calendar mode are now generally available for reserving GPU, TPU, or H4D resources for up to 90 days.

That matters because it changes how you plan:

• You can treat model training windows as scheduled infrastructure events.
• You can coordinate with finance: reserved time windows are easier to attribute.
• You can reduce “we couldn’t get GPUs this week” risk.

If you run quarterly model refreshes or large fine-tunes, calendar mode reservation becomes part of your runbook, not a procurement escalation.

Sole-tenant GPU support expands

Sole-tenancy support expands for A2 and A3 GPU machine types. The practical use cases:

• Regulated workloads where dedicated host control matters.
• Performance isolation when multi-tenant noisy-neighbor risk is unacceptable.

If you’re building an internal AI platform and you’ve promised predictable throughput, sole-tenancy is one of the few levers that actually enforces isolation at the physical host layer.

Reliability warnings are now part of AI operations

A blunt note appears for AI Hypercomputer:

• A4 VMs with NVIDIA B200 GPUs may experience interruptions due to a firmware issue.
• Google recommends resetting GPUs at least every 60 days.

This is the new normal: “AI infrastructure” includes firmware, health prediction, driver rollouts, and proactive maintenance. Which leads to the next item…

AI-optimized GKE gets node health prediction (GA)

Node health prediction can steer scheduling away from nodes likely to degrade in the next five hours.

This is very “data center AI” in practice:

• Predictive maintenance meets scheduling.
• Reduced blast radius for long-running training jobs.

If you’ve ever lost a multi-day training run because a node flaked out late in the job, you understand why this matters. The biggest savings here isn’t compute cost—it’s human time and iteration speed.

Security is shifting from perimeter controls to AI traffic controls

The security updates in this release cycle have a theme: govern the new paths agents and models create, not just classic API endpoints.

Model Armor is spreading into more surfaces

Model Armor shows up in several ways:

• GA monitoring dashboard
• GA integration with Vertex AI
• Preview floor settings for Google-managed MCP servers
• Preview integration with Google Cloud MCP servers

The point isn’t the product name. The point is the control plane:

• Input sanitization (prompt injection defense)
• Output sanitization (data exfiltration and policy violations)
• Logging of sanitization operations

If you’re deploying internal agents that touch production systems, you will need a policy layer. Relying on “good prompts” is the fastest way to ship an incident.

Advanced API Security gets multi-gateway posture management

Apigee Advanced API Security can centrally manage security posture across multiple Apigee projects/environments/gateways (via API hub).

This is relevant to AI in cloud computing because agents often call many APIs. When an agent has tool access, your API sprawl becomes agent sprawl.

A unified risk dashboard helps answer:

• Which APIs are safest to expose as agent tools?
• Are we enforcing the same security profiles across environments?

Single-tenant Cloud HSM moves to GA

Single-tenant Cloud HSM is GA in multiple regions, with quorum approval and external key custody requirements.

If you’re operating AI systems that require strict crypto boundaries (regulated data, signed artifacts, model provenance, confidential inference), dedicated HSM capacity is part of the modern “AI data center” toolkit.

Data, observability, and workflow scale: the unglamorous bottlenecks

AI programs don’t fail because the model is bad. They fail because pipelines can’t scale, logs are chaotic, and ops teams can’t see what changed.

Cloud Composer 3 adds Extra Large environments (GA)

Extra Large environments in Composer 3 are GA, sized for several thousand DAGs.

If you’re building AI data pipelines (feature generation, embedding refresh, evaluation), the orchestration layer becomes a real constraint. Extra Large isn’t a vanity size—it’s a sign that organizations are running enough workflows that “Airflow hygiene” becomes a platform responsibility.

Enhanced backups for Cloud SQL are GA (and include PITR after deletion)

Enhanced backups are GA for Cloud SQL MySQL/PostgreSQL/SQL Server, managed via Backup and DR, and they support point‑in‑time recovery after instance deletion.

That last part is underrated. Accidental deletion is a top-tier operational risk, and AI workflows often create automation pathways that increase the chance of “oops” moments.

Anywhere Cache integrates with BigQuery reads

Cloud Storage Anywhere Cache can serve object reads issued by BigQuery.

This is an infrastructure efficiency move: if you have data-heavy workloads (training data reads, feature tables, analytics), caching closer to compute reduces both latency and cross-region churn.

VM Extension Manager appears (Preview)

VM Extension Manager lets you manage guest agent extensions across fleets (Ops Agent, SAP agent, etc.) without logging into every VM.

That’s classic data center ops modernization: reduce toil, enforce consistency, and make fleet observability something you can manage by policy.

What to do next: a practical checklist for AI-ready infrastructure

If you’re responsible for AI platforms, cloud infrastructure, or data center operations, here’s how I’d translate these release notes into action.

1) Decide where agents will live—and where they won’t

Create a policy that defines:

• Which systems are allowed as agent tools (databases, ticketing, CI/CD)
• Required controls (logging, approvals, sandboxing)
• A rollout path (pilot → limited teams → broader)

Data agents and MCP support are telling you the ecosystem is standardizing. Take advantage early.

2) Treat accelerator capacity as scheduled inventory

If you run large training or fine-tuning:

• Move to calendar-mode reservations for predictable windows.
• Define “GPU availability SLOs” for internal teams.
• Build a simple intake process: workload duration, GPU type, region, start/end date.

3) Add an AI security layer before the first incident

Don’t wait until an agent calls the wrong endpoint.

• Put prompt and response sanitization into the design.
• Require audit logging for tool calls.
• Define “deny by default” policies for sensitive actions.

4) Scale orchestration and backups like they’re core AI features

If Composer Extra Large and Cloud SQL enhanced backups feel unrelated to AI, they’re not.

• AI systems are pipeline-heavy.
• AI systems amplify operational mistakes.

The reliability foundation has to keep up.

Where this is headed next

Google Cloud’s recent updates point to a simple direction: AI is becoming operational infrastructure, not an add-on product category. Data agents inside databases, standardized tool registries, smarter scheduling for scarce accelerators, and security controls designed for model traffic are all parts of the same story.

If you’re building AI in cloud computing and data centers, the question to ask your team right now isn’t “Which model do we pick?” It’s: Which parts of our infrastructure should become agent-accessible, and what guardrails make that safe at scale?