🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Credential/endpoint confusion: google-vertex routed through google-generative-ai forward-compat fallback without Vertex endpoint constraints

Description

resolveGoogleGenai31ForwardCompatModel() now allows provider: "google-vertex" into the Google GenAI forward-compat path and can synthesize a Model with api: "google-generative-ai" while keeping provider: "google-vertex".

This creates a risky provider/api mismatch:

• Input: user-controlled model ref google-vertex/gemini-3.1-… (from config / CLI selection)
• Auth resolution: elsewhere, google-vertex credentials are resolved from gcloud ADC (resolveEnvApiKey() uses getEnvApiKey("google-vertex") and labels it "gcloud adc").
• Transport selection: api: "google-generative-ai" selects the Gemini (public GenAI) transport.
• When no template exists in the registry, the synthesized model omits an explicit baseUrl, so the underlying google-generative-ai transport will fall back to its default endpoint behavior.

Impact (security/privacy):

• Users selecting google-vertex/* typically expect Vertex AI routing (project/region scoped, enterprise controls such as VPC-SC/org policies). This fallback can send prompts/tool output to a different backend path than intended.
• The combination of Vertex-sourced credentials (ADC) with a GenAI transport increases the risk of misapplied credentials (e.g., OAuth/ADC material being attached in an unexpected way) and inadvertent data egress outside the expected Vertex perimeter.

Vulnerable code:

const GOOGLE_GENAI_ELIGIBLE_PROVIDERS = new Set(["google", "google-vertex"]);
...
return normalizeModelCompat({
  id: trimmed,
  name: trimmed,
  api: "google-generative-ai",
  provider: normalizedProvider,
  ...
});

Recommendation

Avoid routing google-vertex through the generic GenAI fallback unless you can guarantee Vertex-correct endpoint + auth semantics.

Safer options:

1. Disallow google-vertex in this forward-compat resolver (only allow google).

const GOOGLE_GENAI_ELIGIBLE_PROVIDERS = new Set(["google"]);

2. If you want forward-compat for Vertex, only allow cloning from an existing Vertex template (which should already contain the correct Vertex baseUrl and any required metadata). If no template exists, return undefined so the user gets a clear “Unknown model” instead of silent rerouting.

if (normalizedProvider === "google-vertex") {
  const cloned = cloneFirstTemplateModel({ ... });
  return cloned; // no synthetic fallback for vertex
}

3. Additionally (defense-in-depth), when returning a forward-compat model in resolveModel(), consider applying any configured provider baseUrl override even for forward-compat models, so enterprise users can force Vertex/private endpoints.

Analyzed PR: #36173 at commit c96535e

_{Last updated on: 2026-03-05T14:09:26Z}

Greptile Summary

This PR extends the existing forward-compat model resolution to cover the google and google-vertex providers for Gemini 3.1 series models, fixing FailoverError: Unknown model when those models are used as fallbacks. The implementation correctly follows the established pattern: attempt to clone a known template model from the registry, and synthesize a minimal model definition if no template is found.

Key issues:

• Wrong api adapter in the synthetic fallback for google-vertex (src/agents/model-forward-compat.ts, lines 205–215): The fallback hardcodes api: "google-generative-ai", which is the correct adapter for the google (AI Studio) provider but not for google-vertex. If the Vertex AI registry doesn't contain a gemini-3-flash-preview or gemini-3-pro-preview template, the synthetic model will route calls through the wrong HTTP adapter, likely causing authentication or endpoint errors at runtime.

• Missing api assertion in the google-vertex test (model.forward-compat.test.ts, line 144–152): The test exercises the exact synthetic fallback path that has the wrong api value, but does not assert on api, so it passes today and would continue to pass even after the bug is introduced. Adding an api assertion would both document the expected behavior and act as a regression guard.

Confidence Score: 3/5

• Safe to merge for google provider users; carries a latent runtime risk for google-vertex users who hit the synthetic fallback path due to the wrong API adapter being set.
• The template-clone path (the common case) is correct for both providers. The issue is narrowly scoped to the synthetic fallback, which is only triggered when neither gemini-3-pro-preview nor gemini-3-flash-preview exists in the google-vertex registry. If Vertex AI's built-in catalog always includes those templates, the bug is never reached in practice. However, it is a definite correctness gap that the test suite does not catch, warranting a score below 4.
• Pay close attention to src/agents/model-forward-compat.ts lines 205–215 (synthetic fallback) and the google-vertex test case in src/agents/pi-embedded-runner/model.forward-compat.test.ts.

_{Last reviewed commit: c96535e}