GEMINI ENGINE - Add new authentication methods

[fbecar22]

Today, for enterprise workloads, the authentication throught vertex AI ( or now "Gemini Enterprise Agent Platform") is the recommended way to authenticate to Gemini CLI.
(cf : https://github.com/google-gemini/gemini-cli#option-3-vertex-ai )

Could you study the possibility to add this authentication method to the gemini engine please?

[pelikhan]

/scout review the gemini vertex auth and propose an implementation plan for gemini

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @github-actions[bot]

Executive Summary

The request is feasible and largely aligned with infrastructure that already exists in gh-aw. Gemini CLI supports Vertex AI (a.k.a. "Gemini Enterprise Agent Platform") purely through environment variables — no code change to the CLI invocation itself is needed. The gaps are in the GeminiEngine Go code, which currently hardcodes GEMINI_API_KEY as the only auth path. Three small, well-scoped changes would enable Vertex AI auth.

Click to expand detailed findings

Research Findings

How Gemini CLI authenticates to Vertex AI

Gemini CLI selects Vertex AI via env vars (per the official gemini-cli authentication docs):

• GOOGLE_GENAI_USE_VERTEXAI=true — switch the SDK from AI Studio to Vertex AI
• GOOGLE_CLOUD_PROJECT — GCP project ID
• GOOGLE_CLOUD_LOCATION — region (e.g. us-central1, or global)
• Credentials, one of:
  • Application Default Credentials (ADC) — GOOGLE_APPLICATION_CREDENTIALS pointing at a service-account key JSON, or ambient ADC from gcloud/Workload Identity Federation
  • Vertex express mode — GOOGLE_API_KEY (a Vertex-scoped key), no project/location needed

⚠️ Important gotcha (gemini-cli#1577): if GEMINI_API_KEY is set, Vertex AI login breaks. gh-aw currently always injects GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }} — this must be made conditional.

Current gh-aw Gemini engine behavior (pkg/workflow/gemini_engine.go)

• GetRequiredSecretNames / GetSecretValidationStep → hardcode GEMINI_API_KEY (validation would fail a Vertex-only setup).
• GetSupportedEnvVarKeys → returns only constants.GeminiAPIKey, so Vertex env keys passed via engine.env may be rejected.
• The env map (~line 262) unconditionally sets GEMINI_API_KEY.
• Escape hatch that already works today: engine.env values are merged in (maps.Copy(env, workflowData.EngineConfig.Env), ~line 340), and EngineConfig.Command allows a fully custom invocation.

Infrastructure already present (reduces scope)

• GCP OIDC/Workload Identity Federation is already recognized: google-github-actions/auth is a known credential action (pkg/workflow/known_action_credentials.go:87, safe_outputs_permissions.go:20) and auto-triggers id-token: write. This is the GitHub-Actions-native, keyless auth path (preferred over long-lived SA keys).
• Firewall is not a blocker: the default allowlist includes *.googleapis.com (pkg/workflow/domains.go:133), which covers the Vertex endpoint *-aiplatform.googleapis.com.
• AWF config already models a GCP Workload Identity Provider (awf-config.schema.json, AWF_AUTH_GCP_WORKLOAD_IDENTITY_PROVIDER).

Recommendations

1. Make GEMINI_API_KEY conditional. Detect Vertex mode (e.g. presence of GOOGLE_GENAI_USE_VERTEXAI/GOOGLE_CLOUD_PROJECT in engine.env, or an explicit engine.auth: vertex field) and, when set, do not inject GEMINI_API_KEY.
2. Broaden allowed env keys. Add GOOGLE_GENAI_USE_VERTEXAI, GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION, GOOGLE_API_KEY, GOOGLE_APPLICATION_CREDENTIALS to GetSupportedEnvVarKeys (and as constants).
3. Relax secret validation so a Vertex configuration is not forced to provide GEMINI_API_KEY.
4. Prefer WIF over SA-key files in docs/examples — leverage the already-supported google-github-actions/auth step so no static key touches the runner.
5. Document a minimal example (see below) and add a golden/lock test for the Vertex code path.

Minimal example the change should enable

engine:
  id: gemini
  env:
    GOOGLE_GENAI_USE_VERTEXAI: "true"
    GOOGLE_CLOUD_PROJECT: ${{ vars.GCP_PROJECT }}
    GOOGLE_CLOUD_LOCATION: "us-central1"
# plus a google-github-actions/auth@v2 step (WIF) for keyless ADC

Key Sources

• Gemini CLI authentication docs
• Gemini CLI Vertex AI option (issue reference)
• gemini-cli#1577 — GEMINI_API_KEY breaks Vertex login
• gh-aw code: pkg/workflow/gemini_engine.go, known_action_credentials.go:87, domains.go:133

Suggested Next Steps

1. Decide the config surface: overload engine.env (zero new schema) vs. an explicit engine.auth: api-key | vertex field (clearer UX, validatable).
2. Implement the 3 code changes above in GeminiEngine; keep GEMINI_API_KEY as the default path (no breaking change).
3. Add a compiler lock-file golden test covering Vertex mode and a docs page under the Gemini engine section.

🔭 Intelligence gathered by Scout · age00 82.6 AIC · ⌖ 12.6 AIC · ⊞ 6.4K · ◷
_{Comment /scout to run again}

[pelikhan]

@copilot use auth to align with anthropic/claude