Enterprise > Enterprise features

BYOLLM: Gemini Enterprise (Vertex AI)

Route Warp Agent inference through your own Google Cloud project with Gemini Enterprise BYOLLM. Short-lived Workload Identity Federation credentials, admin-controlled models, and inference billed to your GCP account.

Warp’s Gemini Enterprise BYOLLM integration routes agent inference through your own Google Cloud project using Vertex AI (the Gemini Enterprise Agent Platform). Your team keeps using Warp’s agents as usual, while eligible requests execute against models hosted in your GCP project, billed to your Google Cloud account and governed by your IAM controls.

Gemini Enterprise is one of the providers supported by Bring Your Own LLM (BYOLLM). For AWS-based routing, see the AWS Bedrock BYOLLM setup.

Key features

Session-based federated authentication - Warp uses the member’s signed-in Warp session to issue a short-lived OIDC identity token, then exchanges it through Google Workload Identity Federation for temporary Google Cloud credentials.
Admin-controlled routing and models - Admins configure the GCP project, Vertex location, and WIF provider once in the Admin Panel, then choose exactly which models are enabled and which Vertex model references they resolve to.
Gemini and Claude models - Route native Gemini models and Claude partner models available on Vertex AI through your project.
Consolidated billing and quota attribution - Inference runs against your project’s Vertex AI quota and is billed to your Google Cloud account. Requests carry your project for quota attribution (X-Goog-User-Project).
No long-lived credentials - Warp never stores service account keys, refresh tokens, or credential files. The client keeps only a short-lived Google Cloud access token in memory and automatically replaces it as it approaches expiration.

How it works

When Gemini Enterprise is enabled, Warp redirects eligible inference calls to Vertex AI in your Google Cloud project instead of using model providers’ direct APIs.

Here’s the high-level flow:

Admin configures routing - Your team admin enables the Gemini Enterprise host on the Models page of the Admin Panel and sets the GCP project, Vertex location, and WIF provider audience string.
Members enable credentials - Each signed-in member turns on Use Gemini Enterprise credentials in Warp’s Settings (or the admin enforces it team-wide).
Warp mints a short-lived token - The Warp client exchanges a Warp-signed identity token for a short-lived Google Cloud access token via Google’s Security Token Service (STS), optionally impersonating a service account you designate.
Warp routes requests - Eligible agent requests carry that access token, and Warp’s backend uses it to call Vertex AI in your project with the configured location and model reference.
Inference executes in your cloud - The model runs in your GCP project. Responses stream back to the Warp client.

Credential lifecycle

Gemini Enterprise uses federated, short-lived credentials instead of API keys or local cloud CLI sessions:

Rooted in the Warp session - Each mint starts from the member’s signed-in Warp session. Warp issues a signed OpenID Connect (OIDC) token, exchanges it at Google STS for a federated access token, and, if configured, impersonates your designated service account.
Automatic refresh - Tokens are held in memory and refreshed automatically about five minutes before they expire. Members don’t need to re-authenticate during normal use.
Strict binding - A minted token is only attached to requests while the signed-in user and the admin’s WIF configuration still match. Signing out, switching accounts, or admin configuration changes invalidate it.
No storage or logging - The client never uploads refresh tokens, credential JSON, or service account keys, and Warp’s servers never persist or log the access token.

Model availability

Gemini Enterprise supports the intersection of models that Warp supports and models available through Vertex AI in your project:

Native Gemini models - Current Gemini Flash, Flash Lite, and Pro families (for example, Gemini 3.1 Pro and Gemini 3.6 Flash).
Claude partner models on Vertex AI - Current Claude Sonnet, Opus, Haiku, and Fable families offered as Vertex AI partner models.

To determine which models you can use, see Model Choice for Warp’s supported models and the Models page of the Admin Panel for your team’s Gemini Enterprise enablement.

Enabling Gemini Enterprise

Setting up Gemini Enterprise has two parts:

In Google Cloud - Trust identities issued by Warp, then grant them permission to call Vertex AI.
In Warp - Point the Admin Panel at your project and choose which models route through it.

Access is granted through Workload Identity Federation, so no long-lived service account key is ever created or shared with Warp. Step 2 covers two ways to grant that access: directly to your federated Warp identities, or through a service account you designate.

Prerequisites

Before configuring Gemini Enterprise, confirm the following:

You have a Google Cloud project that will own inference, quota, and billing.
The Vertex AI API (aiplatform.googleapis.com) is enabled in that project.
The models you plan to route are available to the project. Claude partner models must be enabled in the Vertex AI Model Garden.
You can create Workload Identity Federation pools and providers and modify the project’s IAM policy. To use service account impersonation in Step 2, you also need permission to create service accounts.
You have administrator access to Warp’s Admin Panel.

Values you’ll need

Collect these values before you start. You’ll reuse them across Google Cloud and Warp.

PROJECT_ID - Your Google Cloud project’s alphanumeric identifier, such as my-gcp-project.
PROJECT_NUMBER - Your Google Cloud project’s numeric identifier, such as 123456789012. Both identifiers appear on the Welcome page of the Google Cloud console.
TEAM_UID - Your Warp team UID, which is the path segment immediately after /admin/ in your Admin Panel URL. In https://app.warp.dev/admin/HzjUdNkg8Uiq8gp6FMgfxe/models, the team UID is HzjUdNkg8Uiq8gp6FMgfxe.
POOL_ID and PROVIDER_ID - Names you choose for the workload identity pool and provider you create in Step 1, such as warp-byollm and warp.

1. Create a workload identity pool and provider (cloud admin)

Before Google Cloud accepts identity tokens issued by Warp, register Warp as an OIDC identity provider in a workload identity pool.

A workload identity pool provides a namespace for external identities. The provider inside that pool tells Google Cloud how to validate and interpret the OIDC tokens Warp issues.

Warp-issued OIDC tokens carry these claims:

sub - Identifies the Warp actor, shaped as scoped_principal:TEAM_UID/ACTOR_TYPE:PRINCIPAL_UID. For interactive requests, ACTOR_TYPE is user.
teams - Lists the Warp team UIDs the actor belongs to. Mapping this claim to google.groups lets you grant a role to an entire Warp team with a single IAM binding.

Create the pool

In the Google Cloud console, go to IAM & Admin > Workload Identity Federation.
Click Create pool.
For Name, enter your POOL_ID value, then click Continue.

If your organization already has a suitable pool, skip this step and create the Warp provider inside the existing pool instead.

Create the provider

Continue in the Add a provider to pool step:

For Select a provider, choose OpenID Connect (OIDC).
For Provider name, enter your PROVIDER_ID value.
For Issuer (URL), enter https://app.warp.dev.
Leave Audience set to Default audience, then click Continue.

The default audience requires Warp’s OIDC token to name this provider in its aud claim, which takes this canonical form:

https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

You’ll enter a variation of this value in Warp in Step 3.

Configure attribute mappings

In Configure provider attributes, add both mappings exactly as shown:

Google attribute	OIDC expression
`google.subject`	`assertion.sub`
`google.groups`	`assertion.teams`

Restrict the provider to your Warp team

Turn on Attribute conditions and enter the following expression, replacing TEAM_UID with your Warp team UID:

"TEAM_UID" in assertion.teams

This rejects any Warp-issued token that doesn’t belong to your team. Click Save.

The provider now appears in the pool and is ready to exchange tokens.

2. Grant Vertex AI access to your Warp team (cloud admin)

The provider you created controls which Warp tokens Google Cloud accepts. Now grant permissions to the identities those tokens represent. Choose one of the following approaches:

Option A (Recommended): Direct federated access - Grants roles straight to your federated Warp identities.
Option B: Service account impersonation - Routes access through a dedicated service account.

Neither option creates a long-lived service account key, and Warp never receives one.

Option A: Direct federated access (recommended)

In the Google Cloud console, go to IAM & Admin > IAM, then click Grant access.

For New principals, enter your team’s principal set, substituting your own values:

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/TEAM_UID

Assign both of the following roles, then click Save:
- Vertex AI User (roles/aiplatform.user) - Allows Vertex AI inference calls. For stricter least privilege, create a custom role that contains only aiplatform.endpoints.predict and assign that role instead.
- Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) - Lets the federated identity draw quota and billing from your project.

The principal set now appears in the project’s IAM policy with both roles attached. Leave Service account email blank in Step 3.

Option B: Service account impersonation (optional)

In the Google Cloud console, go to IAM & Admin > Service Accounts, then click Create service account.
Enter a name for the account, such as warp-byollm-sa, then click Create and continue.
Grant the service account the Vertex AI User (roles/aiplatform.user) and Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) roles on your project, then click Done.
Select the service account, open the Principals with access tab, then click Grant access.

For New principals, enter your team’s principal set:

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/TEAM_UID

Assign the Workload Identity User role (roles/iam.workloadIdentityUser), then click Save.
Go to APIs & Services > Library, search for IAM Service Account Credentials API, and click Enable so Warp can request impersonated tokens.

Copy the service account’s email address, such as warp-byollm-sa@PROJECT_ID.iam.gserviceaccount.com. You’ll enter it in Step 3.

Warp never receives the service account’s keys. Each request carries a short-lived impersonated token that the client mints at request time.

3. Configure routing in the Admin Panel (Warp admin)

Connect Warp to the Google Cloud configuration you just created:

In the Admin Panel, go to the Models page.
Find the Gemini Enterprise host configuration and enable it.
For GCP project ID, enter your PROJECT_ID value.
For Location, choose the Vertex AI location that should serve requests.

For WIF audience, enter the provider resource name in this form:

//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

For Service account email, leave the field blank if you chose Option A, or enter the service account’s email if you chose Option B.
Enable the models that should route through your project, then save.

The default location is global. Multi-region values (global, us, eu) and specific regions (for example, us-central1) are supported. The location applies host-wide to every Gemini Enterprise model.

You can also choose how member credentials behave:

Enforce - Every signed-in member’s client uses Gemini Enterprise credentials automatically, and the member toggle is managed by the organization.
Respect user setting - Each member opts in with the Use Gemini Enterprise credentials toggle in their Settings.

To enforce provider-only routing, disable Direct API access for the models you enabled.

4. Validate

Run a test prompt in Warp using a model enabled for Gemini Enterprise. Verify:

The model shows the Gemini Enterprise badge in the model picker.
The request completes successfully.
The request appears in your project’s Vertex AI monitoring or Cloud Logging.

Alternative: configure Google Cloud with the gcloud CLI

If you prefer the command line, these commands replace Step 1 and Step 2, Option A. Step 3 in the Admin Panel is still required either way.

Set your values once so the commands below can reuse them:

export PROJECT_ID="my-gcp-project"
export PROJECT_NUMBER="123456789012"
export POOL_ID="warp-byollm"
export PROVIDER_ID="warp"
export TEAM_UID="HzjUdNkg8Uiq8gp6FMgfxe"

Enable the Vertex AI API:

gcloud services enable aiplatform.googleapis.com \
  --project="${PROJECT_ID}"

Create the workload identity pool:

gcloud iam workload-identity-pools create "${POOL_ID}" \
  --project="${PROJECT_ID}" \
  --location="global" \
  --display-name="Warp BYOLLM"

Create the OIDC provider:

gcloud iam workload-identity-pools providers create-oidc "${PROVIDER_ID}" \
  --project="${PROJECT_ID}" \
  --location="global" \
  --workload-identity-pool="${POOL_ID}" \
  --display-name="Warp" \
  --issuer-uri="https://app.warp.dev" \
  --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.teams" \
  --attribute-condition="'${TEAM_UID}' in assertion.teams"

Grant the Vertex AI role. For stricter least privilege, substitute a custom role that contains only aiplatform.endpoints.predict:

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${POOL_ID}/group/${TEAM_UID}" \
  --role="roles/aiplatform.user"

Grant the Service Usage Consumer role:

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${POOL_ID}/group/${TEAM_UID}" \
  --role="roles/serviceusage.serviceUsageConsumer"

Retrieve the provider resource name for the WIF audience field:

gcloud iam workload-identity-pools providers describe "${PROVIDER_ID}" \
  --project="${PROJECT_ID}" \
  --location="global" \
  --workload-identity-pool="${POOL_ID}" \
  --format="value(name)"

The command returns a value in this form:

projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

Prefix that value with //iam.googleapis.com/ and enter the result as the WIF audience in Warp:

//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

Using Gemini Enterprise as a team member

Members need to be signed in to Warp; the credential flow is rooted in the Warp session, so Gemini Enterprise isn’t available to logged-out users.

In the Warp app, go to Settings > Agents > Warp Agent and scroll to the Gemini Enterprise section. The section appears once your admin has enabled the host.
Toggle Use Gemini Enterprise credentials on. If your admin enforces credentials team-wide, the toggle is already on and managed by your organization.
Check the credential status card. It shows the current state (for example, loaded with the next scheduled refresh, refreshing, setup incomplete, or a failure) and a Refresh button to force a new credential mint.
Pick an eligible model in the model picker. Models routed through your project show a Gemini Enterprise badge.

If the status card reports that setup is incomplete, your workspace’s Gemini Enterprise host is enabled but not fully configured; contact your team admin.

Routing and fallback behavior

Host priority

For each request, Warp expands the selected model into the hosts your admin has enabled and tries them in a fixed order:

AWS Bedrock
Gemini Enterprise
Direct API

The priority is fixed and not admin-configurable. A Gemini Enterprise route is only used when the request carries valid Gemini Enterprise credentials; otherwise Warp falls back to the next enabled host.

Failover behavior

If a Gemini Enterprise request fails (for example, due to IAM misconfiguration or Vertex AI quota limits), Warp attempts to fall back to the next available host your admin has enabled. If a fallback uses a Direct API model, that request consumes Warp credits. If no fallback is available, Warp displays a clear error message.

Auto model selection

Auto model selection is disabled if an admin disables any Direct API model, regardless of Gemini Enterprise configuration. When Direct API models remain enabled, Auto picks the best model for the task; if the selected model is enabled for Gemini Enterprise and your credentials are active, the request routes through your project.

Billing behavior

When a request routes through Gemini Enterprise:

Warp doesn’t consume AI credits for that request. Inference is billed by Google Cloud to your project.
Platform credits still apply - On Business and Enterprise plans, local agent runs that use customer-supplied inference consume platform credits for Warp’s platform infrastructure.
Fallbacks are billed normally - A request that falls back to a Direct API model consumes Warp credits at the standard rate.

See The three credit buckets for more on credit types.

Security and data handling

Credential security

No long-lived credentials - The only long-lived credential involved is the member’s Warp session. Access tokens are short-lived, held in memory, and never persisted.
Nothing sensitive leaves your boundary - Warp stores only non-secret routing configuration (project ID, location, WIF audience, and optional service account email). Service account keys, refresh tokens, and credential files are never uploaded to Warp.
Per-user identity - Every token is minted for the individual signed-in member, so access control and revocation stay in your identity stack: remove a member from your Warp team (or restrict the WIF provider’s attribute condition) and their tokens stop minting.

Zero Data Retention (ZDR)

Warp maintains SOC 2 compliance and has Zero Data Retention (ZDR) agreements with its contracted LLM providers.

However, when using Gemini Enterprise:

Your Google Cloud project settings determine data retention policies.
Warp cannot enforce ZDR for requests routed through your infrastructure.
Review Vertex AI’s data governance settings for your project to control retention.

Auditability

Warp keeps all conversations fully steerable and logged within Warp.
Your GCP project retains provider-side logs (usage, latency, errors) in Vertex AI monitoring and Cloud Logging, attributed to your project.

Troubleshooting

Common errors

Credentials expired or invalid - The request reached Vertex AI but was rejected as unauthenticated. Click Refresh credentials in the inline error, or use the Refresh button in Settings > Agents > Warp Agent, then retry.
Setup incomplete - The host is enabled but the WIF audience is missing or blank. A team admin needs to complete the Models page configuration.
Token exchange or impersonation failed - Verify the WIF provider’s issuer (https://app.warp.dev), both attribute mappings, and the attribute condition. Confirm your Warp team UID in the condition matches the one in your Admin Panel URL exactly. With service account impersonation, also confirm the principal set holds roles/iam.workloadIdentityUser on the service account and that the IAM Service Account Credentials API is enabled.
Permission denied from Vertex AI - Confirm that roles/aiplatform.user and roles/serviceusage.serviceUsageConsumer are granted on the project, to the principal set for direct access or to the service account for impersonation.
Model not found - Confirm the model is available in your configured location and, for Claude partner models, enabled in the Vertex AI Model Garden. Check any per-model reference overrides on the Models page.
Provider quota limits - Check your project’s Vertex AI quotas and request increases if needed.

Debugging steps

Confirm the WIF audience in the Admin Panel exactly matches the provider’s full resource name.
Check the credential status card in Settings > Agents > Warp Agent for the failing state and recovery action.
Verify the IAM bindings for the principal set, and for the service account if you use impersonation, in your GCP project.
Confirm the model reference and location match what’s available in your project.
Inspect Cloud Logging in your project for request details and errors.

FAQ

How is this different from BYOK with a Google API key?

BYOK routes requests to the Gemini Developer API using a personal API key stored on each member’s device. Gemini Enterprise BYOLLM routes requests to Vertex AI in your organization’s GCP project using short-lived federated credentials, configured centrally by an admin, with your project’s IAM, quota, and billing. See Bring Your Own API Key for the self-serve option.

Do members need the gcloud CLI installed?

No. Unlike AWS Bedrock BYOLLM, which uses each member’s local AWS CLI session, Gemini Enterprise mints credentials from the member’s signed-in Warp session. No local Google tooling or configuration is required. Admins can optionally use the gcloud CLI for the one-time Google Cloud setup, but it isn’t required.

Does Gemini Enterprise work with cloud agents?

Not yet. Gemini Enterprise currently routes interactive agent requests in the Warp app. Cloud agent BYOLLM is available today through AWS Bedrock, and Gemini Enterprise support for cloud agents is planned.

Which Claude models route through my project?

Claude models offered as Vertex AI partner models (current Sonnet, Opus, Haiku, and Fable families) can route through Gemini Enterprise when your admin enables them. Eligible models show the Gemini Enterprise badge in the model picker. This is unrelated to any routing Warp does through its own infrastructure for Warp-billed requests.

Can admins enforce provider-only routing?

Yes. Admins can disable Direct API access for models on the Models page so eligible requests only route through your project. Note that disabling any Direct API model also disables Auto model selection.

Bring Your Own LLM - BYOLLM overview and provider comparison
BYOLLM: AWS Bedrock - Route inference through your AWS account
Team-managed API keys and endpoints - Admin-configured shared provider keys and custom endpoints
Bring Your Own API Key - Self-serve, user-level API keys
Model Choice - Full list of supported models
Admin Panel - Configure team settings
Contact sales - Get help with Enterprise setup