feat: add Google Cloud connector support #16287

Background

Add a standalone Google Cloud (GCP) connector. This issue focuses on the v1 product and technical shape of authentication, user login, and the initial Google Cloud capability surface.

This is independent from the broader multi-cloud tracking discussion, but it uses the GCP research already gathered from Google Cloud authentication docs, Google Cloud remote MCP docs, the google/mcp repository, and the current vm0 connector architecture.

Proposed v1 direction

Use Google OAuth to connect a Google identity, then expose Google-managed remote MCP capabilities. Project/resource/action authorization should remain Google IAM's responsibility.

For v1, do not add:

• A vm0 project allowlist step.
• A new GCP-specific vm0 firewall permission model.
• Service account key setup.
• Workload Identity Federation setup.
• Service account impersonation setup.
• Broad direct REST API coverage.

After the user connects Google Cloud, vm0 treats Google Cloud projects/resources accessible to that Google identity as usable by the agent, subject to:

• Google IAM on the underlying project/resource/action.
• Required Google Cloud API/MCP enablement.
• Required Google Cloud product roles, including roles/mcp.toolUser where applicable.

This means the connector is bound to a Google account identity, not to a single GCP project.

User login flow

1. User chooses Connect Google Cloud in vm0.
2. vm0 redirects to Google OAuth consent.
3. User selects a Google account and grants requested scopes.
4. vm0 stores the OAuth refresh/access token using the existing connector secret model.
5. Runtime refreshes access tokens when needed.
6. Agent calls Google-managed MCP endpoints with Authorization: Bearer <access_token>.

The OAuth scope set for v1 needs to include Google Cloud access, likely starting with:

• https://www.googleapis.com/auth/cloud-platform
• https://www.googleapis.com/auth/userinfo.email

userinfo.email is needed because the existing shared Google OAuth helper fetches Google user info after token exchange.

Project model

Do not bind the connector to one project.

For v1:

• The connected Google identity determines project/resource access through Google IAM.
• vm0 does not ask users to select allowed projects during connection.
• vm0 does not store a required GCP_PROJECT_ID for the connector.
• Project IDs are supplied by the agent/tool call or discovered through Resource Manager where supported.
• If Google APIs require a quota/billing project header such as x-goog-user-project, that should be treated separately from authorization scope. It must not be modeled as the only allowed project.

Product/UI copy should make the broad identity boundary explicit: vm0 can access Google Cloud resources available to the connected Google account, subject to Google IAM.

Capability surface

Google Cloud MCP is product-specific, not a single universal GCP endpoint. Supported products expose separate remote MCP endpoints, for example:

• BigQuery: https://bigquery.googleapis.com/mcp
• Cloud Run: https://run.googleapis.com/mcp
• Cloud Storage: https://storage.googleapis.com/storage/mcp
• Cloud SQL: https://sqladmin.googleapis.com/mcp
• Resource Manager: https://cloudresourcemanager.googleapis.com/mcp
• Compute Engine, Firestore, GKE, Pub/Sub, Spanner, and others also have product-level endpoints.

Relevant docs:

• https://docs.cloud.google.com/mcp/supported-products
• https://github.com/google/mcp

For v1, expose the initial Google-managed MCP surface without adding vm0 firewall permission gating. Google IAM remains the source of truth for whether the connected Google identity can perform the underlying operation.

Initial capability candidates:

• Resource Manager: project discovery/context resolution through search_projects.
• BigQuery: dataset/table metadata and SQL tools.
• Cloud Storage: bucket/object tools.
• Cloud Run: service list/get/deploy tools.

Cloud SQL can be handled after the first version because database execution and instance mutation have more complex blast radius.

Authorization boundary

The v1 authorization boundary is Google IAM.

vm0 should not attempt to mirror Google IAM project, folder, organization, resource, or role assignment logic. Those remain in Google Cloud.

For v1, vm0 also does not add GCP-specific firewall permission gating. A follow-up can add vm0 firewall permissions for Google MCP endpoints/tools after the basic connector and runtime path are proven.

Google MCP IAM supports controls such as roles/mcp.toolUser, product IAM roles, read-only/read-write tool attributes, OAuth client ID constraints, and service-based deny policies. v1 relies on Google IAM rather than representing those controls in vm0 UI.

Relevant docs:

• https://docs.cloud.google.com/mcp/access-control
• https://docs.cloud.google.com/mcp/control-mcp-use-iam

Authentication findings

Google Cloud authentication is not one uniform API-key model:

• Most Google Cloud APIs and Google-managed remote MCP servers are IAM-backed and use OAuth 2.0 credentials with Google Cloud IAM authorization.
• Google recommends attached service accounts and ADC for workloads running on Google Cloud.
• Google recommends Workload Identity Federation for external workloads when an external IdP is available.
• Google documents service account keys as risky and recommends avoiding user-managed keys where possible.
• Short-lived service account access tokens expire after 1 hour by default.
• The IAM Credentials API supports generateAccessToken for service account impersonation.
• API keys are only appropriate for services that do not require an IAM principal; many GCP MCP servers explicitly do not accept API keys.

Relevant docs:

• https://docs.cloud.google.com/docs/authentication
• https://docs.cloud.google.com/iam/docs/service-account-creds
• https://docs.cloud.google.com/iam/docs/workload-identity-federation
• https://docs.cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation
• https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys
• https://docs.cloud.google.com/iam/docs/reference/credentials/rest/v1/projects.serviceAccounts/generateAccessToken

Current vm0 architecture context

Current connector architecture:

• Connector grant kinds: manual, auth-code, device-auth, managed.
• Connector access kinds: static, refresh-token, none.
• Runtime access is env-binding based through stored connector secrets and variables.
• Existing Google OAuth support is limited to Workspace/Ads-style connectors: Gmail, Google Ads, Google Calendar, Google Docs, Google Drive, Google Meet, and Google Sheets.
• Existing Google Maps connector is API-key based.
• There is an internal non-connector example of GCP Workload Identity Federation for Vertex AI image generation using Vercel OIDC, STS, and service account impersonation.
• Existing MCP connector examples are simple single-provider endpoints and do not yet model Google-managed MCP endpoint coverage.

Relevant local files:

• turbo/packages/connectors/src/connectors.ts
• turbo/packages/connectors/src/auth-providers/oauth/google-connectors.ts
• turbo/packages/connectors/src/auth-providers/oauth/google.ts
• turbo/packages/connectors/src/connectors/google-maps.ts
• turbo/apps/api/src/signals/routes/generate-image.ts
• turbo/apps/api/src/signals/services/agent-run-create.service.ts

Product-specific examples from research

• BigQuery MCP supports dataset/table metadata and SQL execution tools. It requires roles/mcp.toolUser, roles/bigquery.jobUser, and roles/bigquery.dataViewer for basic use. It does not accept API keys.
• Cloud Run MCP supports listing/getting services and deploying from image/archive/file contents. It requires Cloud Run, Artifact Registry, service account, and MCP Tool User permissions depending on the operation. It does not accept API keys.
• Cloud Storage MCP supports creating buckets, listing buckets/objects, reading object data, reading text, and writing text. It requires Storage roles plus MCP Tool User. It does not accept API keys.
• Resource Manager MCP currently exposes search_projects, useful for resolving project context before using other product tools.
• Cloud SQL MCP exposes instance management, user management, backup/restore/import, and SQL execution/read-only SQL tools.

Relevant docs:

• https://docs.cloud.google.com/bigquery/docs/use-bigquery-mcp
• https://docs.cloud.google.com/bigquery/docs/reference/mcp
• https://docs.cloud.google.com/run/docs/use-cloud-run-mcp
• https://docs.cloud.google.com/run/docs/reference/mcp
• https://docs.cloud.google.com/storage/docs/use-cloud-storage-mcp
• https://docs.cloud.google.com/storage/docs/reference/mcp
• https://docs.cloud.google.com/sql/docs/postgres/use-cloudsql-mcp
• https://docs.cloud.google.com/resource-manager/docs/mcp
• https://docs.cloud.google.com/resource-manager/reference/mcp

Implementation requirements to define

• Add a Google Cloud connector using auth-code OAuth.
• Extend the existing Google OAuth connector/provider registry to include the new connector type.
• Define the stored secret/env binding names for Google Cloud access and refresh tokens.
• Define how runtime passes refreshed access tokens to Google-managed MCP endpoints.
• Define whether a quota/billing project is needed and how it is provided, without making it the connector's authorization boundary.
• Define the first Google-managed MCP endpoint/tool surface to expose.
• Define UI copy for Google IAM prerequisites and the broad identity/project access boundary.
• Confirm Google OAuth consent/app verification implications for the requested Cloud Platform scope.

Acceptance criteria

• A Google Cloud connector exists in the connector catalog with a clear setup path for users.
• Users can connect a Google account through OAuth consent.
• The connector stores and refreshes Google OAuth credentials through the connector auth system.
• The connector is not bound to a single GCP project.
• The initial supported Google-managed MCP endpoints/tools are explicitly defined.
• Runtime calls to Google-managed MCP endpoints use valid Google access credentials.
• UI/setup copy explains that accessible projects/resources/actions are determined by the connected Google account's IAM permissions.
• v1 does not add GCP-specific vm0 firewall permission gating.
• Tests cover connector metadata, OAuth provider registration, token refresh, and runtime credential resolution.

Follow-ups

• Add vm0 firewall permissions for Google MCP endpoints/tools.
• Add service account impersonation support.
• Add Workload Identity Federation support.
• Add narrower product-specific OAuth scopes if needed.
• Add project/quota project UX if required by real usage.

Open questions

• Should cloud-platform be the v1 scope, or should v1 use narrower product-specific scopes?
• Which Google-managed MCP product should be the first implementation target: Resource Manager, BigQuery, Cloud Storage, or Cloud Run?
• How should quota/billing project selection be handled for APIs that require x-goog-user-project?
• How should vm0 surface Google app verification constraints for sensitive/restricted scopes?

---

Updated from Codex conversation and GCP connector research.