Skip to content

Enterprise > Enterprise features

Team-managed LLM API keys and endpoints

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

Configure shared LLM provider API keys and custom inference endpoints for your whole team from the Admin Panel, available in both interactive sessions and cloud agents.

Warp lets an Enterprise team admin configure shared provider API keys and OpenAI-compatible custom endpoints once, so every member can use them without pasting anything locally. Unlike the self-serve Bring Your Own API Key and custom inference endpoint features — which each member configures on their own device and which work only for interactive requests — team-managed providers are stored server-side by Warp and work for both interactive terminal requests and cloud agents.

This gives your organization one place to provision approved model providers, control spend, and keep inference on your own accounts across your whole team.

  • Admin-configured, shared across the team - An admin sets provider keys and custom endpoints once in the Admin Panel, and they appear automatically in every member's model picker.
  • Works for interactive sessions and cloud agents - Because credentials are stored by Warp, team-managed providers power both interactive terminal requests and cloud agent runs. Self-serve, member-managed keys and endpoints are stored locally and passed to Warp only in-flight for interactive requests, so they aren't available to cloud agents.
  • First-party keys and custom endpoints - Configure API keys for OpenAI, Anthropic, and Google, and add one or more OpenAI-compatible custom endpoints (for example, OpenRouter or LiteLLM).
  • Secrets stored server-side, never synced to devices - Keys and endpoint URLs are encrypted and stored by Warp. They're never synced to member devices and never delivered to cloud agent environments.
  • Optional member-managed keys - Admins choose whether members may also add their own self-serve API keys and custom endpoints on top of the team's.
  • Member key precedence - When a member has their own key for the same provider, their key is used instead of the team's. (Custom endpoints don't need precedence — a member's endpoint and a team endpoint are always distinct.)

How team-managed providers differ from self-serve BYOK and BYOLLM

Section titled “How team-managed providers differ from self-serve BYOK and BYOLLM”

Warp offers several ways to bring your own AI infrastructure. Use this table to pick the right one, and follow the links for full details.

NameConfigured byStoredWorks with cloud agentsPlans
Team-managed API keys and endpointsTeam admin (Admin Panel)Server-side by WarpYesEnterprise only
Bring Your Own API Key (BYOK)Each memberLocally on the member's deviceNoFree and all eligible paid plans
Custom inference endpointEach memberLocally on the member's deviceNoFree and all eligible paid plans
Bring Your Own LLM (BYOLLM)Team admin (Admin Panel)Cloud-native IAM (no stored keys)YesEnterprise only

Team-managed API keys and endpoints and BYOLLM are both Enterprise, admin-configured options. Choose team-managed keys and endpoints to route through provider APIs (OpenAI, Anthropic, Google) or any OpenAI-compatible endpoint using stored keys. Choose BYOLLM to route through your own AWS Bedrock environment using cloud-native IAM instead of long-lived keys.

Team-managed configuration is split into public display metadata and secrets, and the two are handled differently.

  • First-party keys (BYOK) - The admin adds an API key for a provider Warp supports (OpenAI, Anthropic, or Google). Members select the normal Warp model for that provider, and the server routes the request through the team key when the member has no key of their own.
  • Custom endpoints (BYOE) - The admin adds one or more OpenAI-compatible Chat Completions endpoints. Each endpoint has a name, a base URL, an API key, and one or more models, where each model has a model name (sent to the endpoint) and an optional alias (shown to members). Team endpoint models appear in every member's model picker as their own entries, labeled with the endpoint name.

Team-managed credentials are protected end to end and are only ever decrypted server-side at the moment a request is served:

  1. Sealed in the browser - When an admin saves a key or endpoint, the Admin Panel encrypts the secret in the browser before it's sent, so the plaintext value never travels in the clear.
  2. Encrypted at rest by Warp - The server re-encrypts each secret with envelope encryption backed by a dedicated Cloud KMS key and stores only the ciphertext. API keys and endpoint base URLs are never written to the settings that sync to clients.
  3. Injected only at request time - When a member (or a cloud agent running as the team) sends a request, the server decrypts the matching team credential and uses it to call the provider or endpoint, at the same boundary that redacts secrets from logs.

What syncs to a member's client is display metadata only: whether a key is configured for each provider, and the names, models, and aliases of team endpoints. API keys, endpoint base URLs, and ciphertext are never exposed to clients.

When the admin allows member-managed keys and endpoints, a member's own key for a provider takes precedence over the team's. Custom endpoints don't require precedence, because a member's endpoint and a team endpoint are always distinct:

  • First-party keys - If a member has their own key for a provider, requests route through the member's key; otherwise the team key is used; otherwise Warp-managed inference is used (if allowed).
  • Custom endpoints - A member's own endpoint and a team endpoint never collide, even if they share a name. The member's endpoint is used when they select it; team endpoints resolve to the team's stored credential.

Because team-managed keys and endpoints are stored by Warp rather than on a member's device, cloud agents running as the team can perform inference through the team's configured providers with no per-member device state. The secret is decrypted only at the server-side inference boundary and never reaches the cloud agent's environment. Member-managed (local) keys and endpoints are never used by cloud agents.

Configuring team-managed keys and endpoints

Section titled “Configuring team-managed keys and endpoints”
  • You have admin access to your team's Admin Panel.
  • Your organization is on the Enterprise plan.

Configure team providers from the Admin Panel Models page, where a First-party API keys card and a Custom endpoints card sit alongside the Direct API and AWS Bedrock cards.

  1. In the Admin Panel, go to the Models page.
  2. To add a team API key, use the First-party API keys card: enter the key for a provider (OpenAI, Anthropic, or Google) and save it. Each provider row shows whether a key is configured without revealing the stored value.
  3. To add a team custom endpoint, use the Custom endpoints card: enter a name, a base URL, an API key, and at least one model (a model name plus an optional alias), then save. An endpoint can't be saved without a name, a valid base URL, an API key, and at least one model.
  4. Choose whether members may add their own keys and endpoints. When this is off, Warp won't use any key or endpoint a member adds, even if they've saved one — their saved keys are preserved for when it's turned back on.

Saved configuration propagates to members the next time their client loads team settings — the team's providers appear in their model picker, and disabled endpoints or models are removed automatically.

By default, members can still choose Warp-managed models even when team providers are configured. To require that inference goes to your providers, turn off Direct API access on the Models page so Warp-managed models are no longer selectable.

Members don't configure anything for team providers — they just select a model. Team-managed configuration syncs to each member's client automatically:

  • Custom endpoints - Each enabled team endpoint model appears in the model picker as its own entry, showing the model's name (or alias) and the endpoint name. Members select it like any other model.
  • First-party keys - Members select the standard model for a provider (for example, a Claude, GPT, or Gemini model), and requests route through the team key automatically. If a member has added their own key for that provider, their own key takes precedence.

If the admin allows members to add their own keys and endpoints, members can still do so through the standard self-serve BYOK and custom inference endpoint settings.

  • No AI credits for team-routed inference - When a request routes through a team key or team endpoint, Warp doesn't consume your AI credits. Inference is billed directly by your provider or endpoint.
  • Auto still uses Warp credits - Warp's Auto models route across providers using Warp's infrastructure, so Auto always consumes Warp credits. To use a team provider, select a specific model or endpoint from the picker.
  • Platform and compute credits still apply - On Enterprise, local agent runs still consume platform credits for Warp's platform infrastructure (run lifecycle, orchestration, and observability). Cloud agent runs consume platform credits too, plus compute credits when they use Warp-hosted compute.

See The three credit buckets for more on credit types.

  • Secrets encrypted at rest - Team keys and endpoint URLs are sealed in the admin's browser, re-encrypted server-side with envelope encryption backed by Cloud KMS, and stored only as ciphertext.
  • Never synced to devices - Only display metadata syncs to member clients. API keys, endpoint base URLs, and ciphertext are never sent to clients.
  • Never delivered to cloud agent environments - Team credentials are decrypted only at the server-side inference boundary and never reach a cloud agent's worker or environment.

Warp is SOC 2 compliant and has Zero Data Retention (ZDR) agreements with its contracted LLM providers. When you route through your own keys or endpoints:

  • Data retention on the provider side is determined by your provider's account settings.
  • Warp cannot enforce ZDR for requests sent through your keys or endpoints.
  • If your provider account doesn't have ZDR enabled, your requests may be retained according to their terms.