No Vertex AI provider in api-proxy credential isolation
Four providers get real credential isolation. A fifth auth mode the same engine already supports — Google Vertex AI — has no scaffolding at all, forcing a real API key into the agent sandbox and silently dropping all token/cost telemetry.
Tags: gemini engine | Vertex AI | credential isolation | missing telemetry
What exists today
src/services/credentials/ has one file per provider. Each swaps the real API key for a host-side placeholder and routes real traffic through the api-proxy sidecar, so the key never reaches the sandboxed agent:
- ✅
anthropic-credential-env.ts
- ✅
copilot-credential-env.ts
- ✅
gemini-credential-env.ts
- ✅
openai-credential-env.ts
- ❌
vertex — does not exist
Example from gemini-credential-env.ts:
placeholders: {
GEMINI_API_KEY: 'gemini-api-key-placeholder-for-credential-isolation',
},
This only wires up GEMINI_API_KEY (the plain Generative Language API). WrapperConfig in src/types.ts has zero vertex/google fields — there's no partial scaffolding to extend, Vertex support isn't started.
The Gemini CLI engine (google-gemini/gemini-cli) itself already supports Vertex as a second auth mode via GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true — the gap is entirely on the proxy side.
Consequences for anyone using Vertex auth
1. The real key ends up inside the sandbox
Setting GOOGLE_API_KEY/GOOGLE_GENAI_USE_VERTEXAI via engine.env gets them correctly auto-excluded from the sandbox — the same mechanism that protects every other provider's key — but then gemini-cli's own startup validation fails immediately, since no placeholder exists for GOOGLE_API_KEY to satisfy it.
The only workaround is setting both in the workflow's top-level env: block instead, which bypasses that auto-exclusion entirely. The real Vertex key is then present in the agent sandbox's environment for the whole run — readable by the LLM via any shell tool call (env, printenv). This has been accepted as a narrow, deliberate trade-off for one workflow, but it shouldn't be the only available option.
2. Token and cost usage never reaches telemetry
With no Vertex target in the proxy, Vertex-mode requests go straight from the agent container to aiplatform.googleapis.com (present in network.allowed) — never touching the api-proxy sidecar. Since the proxy is what emits the token-usage OTel spans, none of this run's usage reaches the workflow's exported telemetry.
Current workaround: parse gemini-cli's own stream-json stdout for the final "type":"result" line's usage stats, post-run, and write it into agent_usage.json ourselves — reconstructing what the proxy would normally have captured live.
Ask
Could a Vertex AI provider be added alongside the existing four, with:
- A placeholder for
GOOGLE_API_KEY mirroring GEMINI_API_KEY's handling, so it can be set via engine.env like every other credential instead of needing the top-level env: bypass
- A proxy target for
aiplatform.googleapis.com, so Vertex traffic is isolated the same way as every other provider and its usage lands in the standard token-usage export
Happy to share the exact env: block currently being used as a workaround if useful.
No Vertex AI provider in api-proxy credential isolation
Four providers get real credential isolation. A fifth auth mode the same engine already supports — Google Vertex AI — has no scaffolding at all, forcing a real API key into the agent sandbox and silently dropping all token/cost telemetry.
Tags:
gemini engine|Vertex AI|credential isolation|missing telemetryWhat exists today
src/services/credentials/has one file per provider. Each swaps the real API key for a host-side placeholder and routes real traffic through the api-proxy sidecar, so the key never reaches the sandboxed agent:anthropic-credential-env.tscopilot-credential-env.tsgemini-credential-env.tsopenai-credential-env.tsvertex— does not existExample from
gemini-credential-env.ts:This only wires up
GEMINI_API_KEY(the plain Generative Language API).WrapperConfiginsrc/types.tshas zerovertex/googlefields — there's no partial scaffolding to extend, Vertex support isn't started.The Gemini CLI engine (
google-gemini/gemini-cli) itself already supports Vertex as a second auth mode viaGOOGLE_API_KEY+GOOGLE_GENAI_USE_VERTEXAI=true— the gap is entirely on the proxy side.Consequences for anyone using Vertex auth
1. The real key ends up inside the sandbox
Setting
GOOGLE_API_KEY/GOOGLE_GENAI_USE_VERTEXAIviaengine.envgets them correctly auto-excluded from the sandbox — the same mechanism that protects every other provider's key — but then gemini-cli's own startup validation fails immediately, since no placeholder exists forGOOGLE_API_KEYto satisfy it.The only workaround is setting both in the workflow's top-level
env:block instead, which bypasses that auto-exclusion entirely. The real Vertex key is then present in the agent sandbox's environment for the whole run — readable by the LLM via any shell tool call (env,printenv). This has been accepted as a narrow, deliberate trade-off for one workflow, but it shouldn't be the only available option.2. Token and cost usage never reaches telemetry
With no Vertex target in the proxy, Vertex-mode requests go straight from the agent container to
aiplatform.googleapis.com(present innetwork.allowed) — never touching the api-proxy sidecar. Since the proxy is what emits the token-usage OTel spans, none of this run's usage reaches the workflow's exported telemetry.Current workaround: parse gemini-cli's own
stream-jsonstdout for the final"type":"result"line's usage stats, post-run, and write it intoagent_usage.jsonourselves — reconstructing what the proxy would normally have captured live.Ask
Could a Vertex AI provider be added alongside the existing four, with:
GOOGLE_API_KEYmirroringGEMINI_API_KEY's handling, so it can be set viaengine.envlike every other credential instead of needing the top-levelenv:bypassaiplatform.googleapis.com, so Vertex traffic is isolated the same way as every other provider and its usage lands in the standard token-usage exportHappy to share the exact
env:block currently being used as a workaround if useful.