Skip to main content

Bring Your Own Key

Use CaseLLMAuthAI Gateway

Teams already hold provider API keys, tied to their own accounts, budgets, and quotas. A gateway that makes them hand those keys over takes on storing, rotating, and protecting every key.

The Problem

A gateway that keeps provider keys in its own configuration becomes a store of secrets, and a leak of its configuration leaks every key. Usage also stops being billed to the team that made it, unless the gateway keeps a key per team.

How Zilla Solves It

Zilla forwards the key each caller already sends. llm · server reads the key from the request with an inline guard, and llm · client sends it to the provider with the same guard, in the header that provider expects. No provider key is written to zilla.yaml, and each call is billed to the account of the key that made it.

Architecture

Bring your own key flow
Bring your own key flow

Configuration

guards:
  api_key:
    type: inline

bindings:
  north_llm_server:
    type: llm
    kind: server
    options:
      dialect: openai
      authorization:
        api_key:
          credentials: "Bearer {credentials}"
    exit: north_llm_proxy

  anthropic_llm_client:
    type: llm
    kind: client
    options:
      dialect: anthropic
      server: https://api.anthropic.com
      authorization:
        api_key:
          credentials: "{credentials}"
    exit: sys:http_client

An OpenAI SDK caller's Authorization: Bearer <key> reaches Anthropic as x-api-key: <key>.

Limits

  • The inline guard doesn't validate keys. A wrong key is rejected by the provider, and that error is returned to the caller.
  • The caller sends the key for the provider that serves the model it asks for: an Anthropic key for a claude-* model, whichever SDK it uses.
  • AWS Bedrock doesn't use the caller's key. Zilla Plus signs Bedrock requests with its own AWS credentials. See AWS Bedrock.

Try It

Try the guide

Walk through Bring Your Own Key to forward a caller's key and confirm which key reaches the provider.