Gemini Cloud Assist Investigations: Proactive RCA and FinOps

The sentence that reframes Gemini Cloud Assist is dated 10 April 2026: creating, running and editing investigations is now only available to users with a Premium Support contract, or whose account team has granted access. Twelve days later Google released the proactive version, and on 23 April it presented the whole thing at Next '26 as available now.

This post is a close reading of that announcement, six pages of Cloud Assist documentation, the release notes and the MCP server README, all read on 17 October 2026. I have not run these agents, because Google does not offer them without Premium Support or an allowlist. So what follows is what the primary sources say, where they disagree with each other, and the configuration they actually give you.

The release notes tell a story the announcement does not

The Next '26 post, dated 23 April 2026, describes a redesigned Cloud Assist that proactively troubleshoots and optimises costs. The release notes, read in date order, are more careful. In the 17 days before the keynote Google replaced the IAM permission behind Cloud Assist, dropped investigations from VPC Service Controls perimeters and limited investigations to Premium Support customers. Proactive agents then arrived on 22 April as a private preview.

The access narrowing is a breaking change, not an upgrade. Anything that created investigations on an open path stopped working on 10 April, while earlier results stay readable. The 16 April note is the odd one out: it is an announcement, not a restriction, but it means a project can acquire a new API through usage alone.

Two products share one name, and identity is what separates them

The documentation draws one line clearly. Chat and interactive investigations run as you. A proactive agent runs as an agent identity, described as a system-provisioned IAM principal unique to your project, which lets it work with no user session. That one choice explains most of the table below.

The release notes add the reassuring sentence for the background mode: these investigations do not modify or make any changes to your environment. The concepts page adds the audit trail, saying proactive results are labelled as system-generated in the console and autonomous actions are audit-logged.

What Google claims, and what it actually measures

The announcement makes four product claims. Triggered by alerts, Cloud Assist proactively clusters and analyzes signals to initiate investigations before issues escalate. With Gemini 3 it correlates logs and metrics and identifies root causes from infrastructure signals down to the application code. It explores parallel hypotheses via tool calls. And a cost anomaly agent runs in the background 24/7.

The only number in the post is a customer quote: a Petco engineer says Cloud Assist reduced the outreach and touch points with dev teams about Google Cloud questions by 60%. That measures support load on a cloud team, not time to root cause. The post gives no resolution-time figure, no accuracy figure, no pricing, no regions and no preview or GA label, and the Gemini 3 detail appears in the blog but not in the release notes I read.

The docs are franker than the keynote. They state that re-running the same investigation can produce results with small differences, and they tell you to verify the time range the investigation used. Read an investigation the way the docs frame it: observations linked to source data, then hypotheses. It is a lead to check, not a verdict.

Switching on Proactive Mode, and the roles it needs

An administrator enables Proactive Mode per project. In the console you open the Cloud Assist panel with the spark icon, choose More actions and then Cloud Assist Settings, enable proactive agents in the Proactive Agents section, click Grant access, and save both panels. Enabling it creates the agent identity. The APIs involved are geminicloudassist.googleapis.com and, for cost work, appoptimize.googleapis.com.

Proactive troubleshooting needs roles/iam.supportUser and roles/serviceusage.serviceUsageConsumer on the agent identity. Cost optimisation adds roles/cloudhub.operator and roles/appoptimize.admin. People need roles/geminicloudassist.user to chat with the agents and roles/geminicloudassist.viewer to read investigations and cost research. The setup page notes you may need more roles depending on your environment.

# APIs: the second one is only needed for the cost agent.
gcloud services enable geminicloudassist.googleapis.com appoptimize.googleapis.com \
  --project=PROJECT_ID

# The agent identity is created when you enable Proactive Mode in the console.
# This principal string is the pattern the setup page gives; fill the three placeholders
# (ORG_NUMBER is the numeric organization id, PROJECT_NUMBER is not the project id).
AGENT="principal://agents.global.org-ORG_NUMBER.system.id.goog/resources/geminicloudassist/projects/PROJECT_NUMBER/locations/global/agents/cloud"

# Proactive troubleshooting: bind these two first.
for ROLE in roles/iam.supportUser roles/serviceusage.serviceUsageConsumer; do
  gcloud projects add-iam-policy-binding PROJECT_ID --role="$ROLE" --member="$AGENT"
done

# Proactive cost optimisation adds these. appoptimize.admin has "admin" in its
# name: read what it grants before binding it in production.
for ROLE in roles/cloudhub.operator roles/appoptimize.admin; do
  gcloud projects add-iam-policy-binding PROJECT_ID --role="$ROLE" --member="$AGENT"
done

# People, not the agent: chat, and read-only access to investigations and cost research.
gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/geminicloudassist.user --member="user:EMAIL_ADDRESS"
gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/geminicloudassist.viewer --member="user:EMAIL_ADDRESS"

One trap sits in organisation policy. If a custom constraint blocks role grants to the agent identity, the page says to add iam.googleapis.com/AgenticIdentityPoolPrincipal to the MemberTypeMatches portion of that constraint. Without it the grants fail, and the agent stays blind.

The cost anomaly agent, and routing its findings with Eventarc

The cost agent starts from Cloud Billing, not from your dashboards. When Billing detects an anomaly, the agent opens an investigation, at most once a day per project, looking for significant changes in spending over time, the specific resources behind a spike and underutilised resources with high spending. Results appear on the Cloud Hub Optimization page. The setup page says the Billing cost anomaly alerts it relies on are on by default for all projects.

When a background task finishes, Cloud Assist emits the event type google.cloud.geminicloudassist.task.v1.completed. The docs' example trigger routes it to Cloud Run, and Cloud Run functions and Workflows are also listed as destinations. The payload, in Protobuf inside CloudEvents or in JSON, carries a title and a result_object_reference URI for the artifact the agent produced.

# The trigger from the docs: one event type, filtered to proactive agents.
# Cloud Run functions and Workflows are also valid destinations.
gcloud eventarc triggers create gca-proactive-tasks \
    --location=global \
    --destination-run-service=gca-task-router \
    --event-filters="type=google.cloud.geminicloudassist.task.v1.completed" \
    --event-filters="proactive=true" \
    --service-account=SERVICE_ACCOUNT

Every proactive agent shares that one event type, so Eventarc attributes cannot separate cost from troubleshooting. The docs' answer is to filter on title in the destination: Cost Anomaly or Cost Optimization for cost, Investigation of for troubleshooting. The handler below does that. I have not seen a live event, so it reads the two documented fields from the top level and logs every title it ignores, because a title is a weak contract.

// gca-task-router: a Cloud Run service (Node 20+, ES modules).
// The docs name two payload fields, title and result_object_reference.
// I have not seen a live event, so the handler accepts them at the top level
// or under data, and logs anything it cannot classify instead of dropping it.
import http from "node:http";

const COST_MARKERS = ["Cost Anomaly", "Cost Optimization"];
const TROUBLESHOOT_MARKER = "Investigation of";

function classify(title) {
  if (COST_MARKERS.some((m) => title.includes(m))) return "cost";
  if (title.includes(TROUBLESHOOT_MARKER)) return "troubleshooting";
  return "unclassified";
}

http
  .createServer((req, res) => {
    const chunks = [];
    req.on("data", (c) => chunks.push(c));
    req.on("end", () => {
      let body = {};
      try {
        body = JSON.parse(Buffer.concat(chunks).toString("utf8"));
      } catch {
        // Protobuf-wrapped CloudEvents are not JSON: log and acknowledge
        // so Eventarc does not retry a payload we will never understand.
        console.log(JSON.stringify({ severity: "WARNING", msg: "non-json payload" }));
        res.writeHead(204).end();
        return;
      }
      const data = body.data ?? body;
      const title = String(data.title ?? "");
      const kind = classify(title);

      // Wrong: if (kind === "cost") page(...)  -- silent on every other title.
      // Right: log every title, route only the ones you recognise.
      console.log(
        JSON.stringify({
          severity: kind === "unclassified" ? "WARNING" : "INFO",
          kind,
          title,
          result: data.result_object_reference,
        }),
      );
      res.writeHead(204).end();
    });
  })
  .listen(process.env.PORT || 8080);

The MCP surface: six tools, one allowlist

The same agents are reachable over MCP. The 22 April release note calls it Private Preview through your account team, and the README of GoogleCloudPlatform/gemini-cloud-assist-mcp says the APIs sit behind an allowlist. The Next '26 post lists Gemini CLI, agentic IDEs, ServiceNow and Slack as surfaces. The README I read shows configurations for Antigravity and Cursor and points Claude Code users to a Cloud Operator plugin, with no Gemini CLI block.

The server moved from a local Node.js process to a remote one: you need v0.8.0 or later, and the local server loses support in the coming months. Authentication uses Application Default Credentials with roles/geminicloudassist.user, plus roles/serviceusage.serviceUsageAdmin to enable APIs. The README warns the tools are not stable APIs and their parameters may change. invoke_operation is the only one that changes resources, so decide who approves it before a shared agent can see it.

# Prerequisites from the README: ADC for local use, and an allowlisted project.
gcloud auth login
gcloud auth application-default login

// The two keys the README shows for Antigravity. The entry name is mine, and
// the surrounding file layout is the client's, not Google's.
"gemini-cloud-assist": {
  "serverUrl": "https://geminicloudassist.googleapis.com/mcp",
  "authProviderType": "google_credentials"
}

Where it breaks: five failure modes from the sources

Reading the sources against each other, I count five ways this goes wrong, and Google documents most of them itself.

• Log-based alerts are not supported for proactive alert investigation, so a team whose paging runs on log-based alerts gets nothing proactive from them.
• Autonomous actions are omitted from the logs if the relevant audit log type is not enabled, which leaves a background agent with a thinner trail than a person.
• Title matching is the routing contract for cost versus troubleshooting. If a title changes, a filter that silently drops unmatched events stops delivering.
• Investigation resources can be stored in any Google Cloud data center, and the docs say not to run investigations on data subject to residency or jurisdictional compliance requirements.
• Scope is one project or one App Hub application. Host-project applications are unsupported, and not every resource inside a supported product is covered.

The quiet failure I would plan for first is the permission swap. A custom role that still carries the old permission loses Cloud Assist access with no change on your side, and the symptom is a missing button, not an error. The audit script in the next section finds those roles.

The trade is real. An agent identity gives a background agent access with nobody present, and the price is that someone must choose its roles. The read-only default is a sound start, but appoptimize.admin is in the cost set and carries admin in its name, so read what it grants before binding it in a production project.

What to do on Monday

Start with the cheap checks, because the first one decides whether the rest is more than reading.

1. Find out whether you hold the entitlement: a Premium Support contract, or access granted by your account team. Without it you cannot create investigations, and the proactive agents are not offered.
2. Search your custom roles for the old completeTask permission and replace it with geminicloudassist.agents.invoke, using the script below.
3. In one non-production project, enable Proactive Mode and bind only the troubleshooting roles first. Add the cost roles when you are ready to read what they grant.
4. Create the Eventarc trigger against a handler that only logs titles for a week, so you can see what fires before it pages anyone.
5. Compare what the cost agent reports with the Billing anomaly alerts you already receive, and keep it only if it explains spikes you could not explain yourself.

# Step 2: list custom roles in a project that still carry the replaced permission.
# Organisation-level custom roles need --organization instead of --project.
OLD="cloudaicompanion.instances.completeTask"
for r in $(gcloud iam roles list --project=PROJECT_ID --format="value(name)"); do
  gcloud iam roles describe "$(basename "$r")" --project=PROJECT_ID \
    --format="value(includedPermissions)" | grep -q "$OLD" && echo "needs update: $r"
done
# Then add geminicloudassist.agents.invoke to each role and remove $OLD.

# Step 4: read the handler's log for a week before it is allowed to notify anyone.
gcloud run services logs read gca-task-router --region=REGION --limit=50

None of this needs the agents to be good. It needs you to know what changed in April, what identity the background work runs under, and where its results arrive.

Treat Gemini Cloud Assist as two products with different contracts: an interactive tool that borrows your access and now needs Premium Support, and a background agent with its own identity that is still a private preview. Read the release notes before the keynote, bind roles deliberately, and let a handler that logs everything earn the right to page anyone.