Summary
Enable native service_account ADC authentication for the google-vertex provider to support automated, zero-touch production deployments on Google Cloud.
Concrete Use Cases:
Production GCE/GKE Deployments: Running OpenClaw multi-agent gateways on Google Compute Engine or Kubernetes Engine, where security best practices mandate using IAM Service Accounts for server-to-server authentication instead of personal human accounts.
Zero-Touch Automation: Ensuring long-running AI agents do not crash due to Workspace session-control policies expiring or humans changing their passwords.
Tradeoffs:
Pros: Eliminates the need for manual, interactive browser OAuth flows (gcloud auth application-default login) on remote servers. It decouples production infrastructure from personal Workspace identities, which is critical for SOC2 compliance and enterprise audits.
Cons: Requires maintaining a slightly more complex auth resolution flow in OpenClaw's codebase (specifically, implementing a JWT-bearer token exchange using Node's native node:crypto module) alongside the existing authorized_user OAuth flow.
Problem to solve
The Problem
Currently, the Google-Vertex provider is hard-coded to only accept authorized_user ADC credentials. When a Google Cloud Service Account key ("type": "service_account") is used, OpenClaw rejects it at the file-type check and reports "No API key found for provider".
This prevents OpenClaw from being deployed natively on GCP infrastructure (GCE, GKE, Cloud Run) using standard Service Account authentication. Users are forced to rely on personal Workspace accounts and manual browser OAuth flows, which fail when session-control policies expire or passwords rotate.
Proposed solution
The Three-Layer Constraint & Proposed Solution
We successfully patched this locally in our production environment (OpenClaw 2026.5.20 (e510042)). Fixing this upstream requires three small changes:
-
JWT Token Exchange in vertex-adc.ts: We bypassed the authorized_user restriction by adding a service_account handler that reads the JSON key, builds a JWT ({ iss: client_email, scope: "cloud-platform", aud: token_uri }), signs it with node:crypto (RSA-SHA256), and exchanges it at Google's token endpoint for a Bearer token.
-
Schema Extension in types.models.ts: We added "google-vertex" to the MODEL_APIS Zod schema array to prevent configuration crashes when api: "google-vertex" is specified.
-
BaseUrl Sniffing in provider-registration.ts: Because custom providers default to openai-completions, we added a fallback in createStreamFn to route the payload to createGoogleVertexTransportStreamFn() if model.baseUrl includes "aiplatform.googleapis.com".
Alternatives considered
No response
Impact
Merging these changes will make OpenClaw immediately compatible with enterprise Google Cloud deployments, allowing for zero-touch, programmatically rotated Service Account identities.
Evidence/examples
No response
Additional information
No response
Summary
Enable native service_account ADC authentication for the google-vertex provider to support automated, zero-touch production deployments on Google Cloud.
Concrete Use Cases:
Production GCE/GKE Deployments: Running OpenClaw multi-agent gateways on Google Compute Engine or Kubernetes Engine, where security best practices mandate using IAM Service Accounts for server-to-server authentication instead of personal human accounts.
Zero-Touch Automation: Ensuring long-running AI agents do not crash due to Workspace session-control policies expiring or humans changing their passwords.
Tradeoffs:
Pros: Eliminates the need for manual, interactive browser OAuth flows (gcloud auth application-default login) on remote servers. It decouples production infrastructure from personal Workspace identities, which is critical for SOC2 compliance and enterprise audits.
Cons: Requires maintaining a slightly more complex auth resolution flow in OpenClaw's codebase (specifically, implementing a JWT-bearer token exchange using Node's native node:crypto module) alongside the existing authorized_user OAuth flow.
Problem to solve
The Problem
Currently, the Google-Vertex provider is hard-coded to only accept authorized_user ADC credentials. When a Google Cloud Service Account key ("type": "service_account") is used, OpenClaw rejects it at the file-type check and reports "No API key found for provider".
This prevents OpenClaw from being deployed natively on GCP infrastructure (GCE, GKE, Cloud Run) using standard Service Account authentication. Users are forced to rely on personal Workspace accounts and manual browser OAuth flows, which fail when session-control policies expire or passwords rotate.
Proposed solution
The Three-Layer Constraint & Proposed Solution
We successfully patched this locally in our production environment (OpenClaw 2026.5.20 (e510042)). Fixing this upstream requires three small changes:
JWT Token Exchange in vertex-adc.ts: We bypassed the authorized_user restriction by adding a service_account handler that reads the JSON key, builds a JWT ({ iss: client_email, scope: "cloud-platform", aud: token_uri }), signs it with node:crypto (RSA-SHA256), and exchanges it at Google's token endpoint for a Bearer token.
Schema Extension in types.models.ts: We added "google-vertex" to the MODEL_APIS Zod schema array to prevent configuration crashes when api: "google-vertex" is specified.
BaseUrl Sniffing in provider-registration.ts: Because custom providers default to openai-completions, we added a fallback in createStreamFn to route the payload to createGoogleVertexTransportStreamFn() if model.baseUrl includes "aiplatform.googleapis.com".
Alternatives considered
No response
Impact
Merging these changes will make OpenClaw immediately compatible with enterprise Google Cloud deployments, allowing for zero-touch, programmatically rotated Service Account identities.
Evidence/examples
No response
Additional information
No response