Skip to content

No Vertex AI provider in api-proxy credential isolation #5877

Description

@jaroslawgajewski

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions