Claude Apps Gateway-Konfiguration

​

Dateistruktur

• listen: Bindungsadresse, öffentliche URL, TLS-Beendigung
• oidc: Ihr Identitätsanbieter (IdP), einschließlich Aussteller, Client, Anspruchszuordnung und wer sich anmelden darf
• session: die Bearer-Token, die das Gateway ausstellt, mit Geheimnis und Lebensdauer
• store: PostgreSQL, für Gerätezuschüsse und Rate-Limit-Zähler
• upstreams: wohin Inferenz geht, ob Anthropic, Amazon Bedrock, Claude Platform auf AWS, Agent Platform von Google Cloud oder Microsoft Foundry

• login_notice: ein Hinweis, den Entwickler bei der Anmeldung sehen
• admin: Admin-API-Authentifizierung und Aufbewahrung für Ausgabenlimits
• enforcement: Ausgabenlimit-Verhalten bei Fehler-offen oder Fehler-geschlossen
• pricing: vertraglich vereinbarte Sätze und ein Multiplikator für das Ausgabenmessgerät und für die Kostenzahlen, die Entwickler sehen
• models und auto_include_builtin_models: von Admin kuratierte Modellliste und Pro-Upstream-IDs
• managed: verwaltete Einstellungsrichtlinien nach IdP-Gruppe
• telemetry: OTLP-Weiterleitung an Ihren Observability-Stack
• access_control, limits, timeouts, rate_limits: IP-Zulassung/Ablehnung, Anfragegrößenbeschränkungen, Upstream-Zeit-bis-erstes-Byte und Pro-IP-Anmeldungslimits
• load_test_mode: Lasttests des Gateways ohne Aufruf eines Modellanbieters

​

Geheimniserweiterung

​

Erforderliche Abschnitte

​

listen

​

oidc

​

Zertifikatbasierte Client-Authentifizierung

openssl req -x509 -newkey rsa:2048 -nodes -keyout idp-client.key -out idp-client.crt -days 365 -subj "/CN=claude-gateway"

oidc:
  issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
  client_id: <application-id>
  token_endpoint_auth_method: private_key_jwt
  client_assertion:
    private_key_pem: ${file:/etc/gateway/idp-client.key}
    certificate_pem: ${file:/etc/gateway/idp-client.crt}

[gateway] 2026-10-01T23:07:40.512Z info oidc: client authentication private_key_jwt; certificate CN=claude-gateway, SHA-1 thumbprint DE92821854EE8BAA1D98C758FAA04AABE80B9F57, expires Oct  1 23:07:31 2027 GMT

​

Client-Zertifikat rotieren

1. Laden Sie das neue Zertifikat zusätzlich zum alten beim IdP hoch.
2. Ersetzen Sie die Schlüssel- und Zertifikatsdateien, die gateway.yaml lädt, und starten Sie dann das Gateway neu. Wenn Sie mehrere Replikate betreiben, funktioniert ein Rolling Restart, da der IdP beide Zertifikate hat, bis Sie das alte entfernen.
3. Nachdem jedes Replikat neu gestartet wurde, entfernen Sie das alte Zertifikat beim IdP.

​

IdP-Anfragen durch einen Forward-Proxy

​

Proxy-only Egress

export HTTPS_PROXY=http://proxy.corp.example.com:3128
export NO_PROXY=
export no_proxy=
export CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1

• HTTPS_PROXY oder HTTP_PROXY ist gesetzt.
• NO_PROXY und no_proxy sind leer. Wenn Ihre Plattform eines davon in Pods injiziert, setzen Sie beide auf einen leeren Wert auf dem Gateway-Container. Das Auflisten eines Telemetrie-Collectors in NO_PROXY hält Proxy-only Egress aus.
• CLAUDE_GATEWAY_ALLOW_LOOPBACK ist nicht aktiviert. Ein Collector oder IdP auf dem eigenen Loopback des Pods kann nicht mit Proxy-only Egress kombiniert werden, da eine an den Proxy übergebene Loopback-Adresse die des Proxy-Hosts selbst wäre, daher geben Sie diesen Services stattdessen eine Adresse, die der Proxy erreichen kann. Aus dem gleichen Grund lehnt das Gateway localhost-ähnliche Namen grundsätzlich ab, während Proxy-only Egress aktiv ist.

​

session

​

store

​

upstreams

​

Upstream-Fehlermeldungen

• Ein Upstream gab einen Status zurück, bei dem das Gateway kein Failover durchführt: die Antwort dieses Upstreams. Das Gateway versucht keine weiteren Upstreams.
• Jeder Upstream, den das Gateway versucht hat, ist auf eine Weise fehlgeschlagen, bei der es ein Failover durchführt: der letzte 429. Wenn keiner einen 429 zurückgegeben hat, bevorzugt das Gateway in dieser Reihenfolge den letzten 401 oder 403, den letzten 404 und den letzten 501. Wenn keiner davon zurückgegeben wurde, das eigene 502 des Gateways, all upstreams failed (N attempted). N zählt Ihre upstreams-Einträge einschließlich übersprungener, abzüglich derer, deren groups-Liste den Entwickler nicht einschließt.

• 400 oder 413 in Anthropics Standard-Fehler-Envelope: die eigene Nachricht des Upstreams, wie prompt is too long. Claude Platform on AWS, Agent Platform und Microsoft Foundry geben dieses Envelope für Modell-API-Ablehnungen zurück.
• 400 oder 413 in der eigenen Form des Anbieters: ein capability_rejected:-Token. Wenn das Gateway die Ablehnung nicht klassifizieren kann, upstream rejected the request bei einem 400 oder request too large for this upstream bei einem 413.
• Jeder andere Status: generischer Text pro Status, wie upstream rate limit exceeded bei einem 429.

​

Anthropic API

upstreams:
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}
    # OR an OAuth bearer (e.g. a Workload-Identity-Federation-exchanged token):
    #   oauth_token: ${file:/var/run/secrets/anthropic-oauth-token}
    # base_url: https://api.anthropic.com   # default; override for a forward proxy

• api_key: sendet x-api-key. Rotieren Sie ihn in der Claude Console und aktualisieren Sie die Umgebungsvariable.
• oauth_token: sendet Authorization: Bearer. Verwenden Sie die Bearer-Form, wenn Ihre Organisation kurzlebige Tokens statt langlebiger API-Schlüssel ausgibt. Der Bearer wird einmal beim Start gelesen, daher aktualisieren Sie durch erneutes Mounten des Geheimnisses und Neustart.

upstreams:
  - provider: anthropic
    auth:
      federation_rule_id: ${ANTHROPIC_FEDERATION_RULE_ID}
      organization_id: ${ANTHROPIC_ORGANIZATION_ID}
      identity_token_file: /var/run/secrets/anthropic/id-token
      # workspace_id: wrkspc_...       # required if the rule covers >1 workspace
      # service_account_id: svac_...   # optional expected-target check

Identitäts-Header pro Benutzer für einen Proxy, den Sie betreiben

upstreams:
  - provider: anthropic
    base_url: https://upstream-gateway.internal.example.com
    auth:
      api_key: ${PROXY_KEY}
    forward_user_identity: true        # default false

​

Amazon Bedrock

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}                           # preferred: AWS default credential chain
    # OR explicit credentials:
    # auth:
    #   aws_access_key_id: ${AWS_AKID}
    #   aws_secret_access_key: ${AWS_SK}
    #   aws_session_token: ${AWS_ST}
    # OR a Bedrock API bearer token:
    # auth:
    #   aws_bearer_token: ${AWS_BEARER_TOKEN}
    # Override the bedrock-runtime endpoint for FIPS or VPC-endpoint deployments:
    # base_url: https://bedrock-runtime-fips.us-east-1.amazonaws.com

Eine Amazon Bedrock-Guardrail anwenden

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}
    guardrail:
      id: gr-abc123                    # guardrail ID or full ARN
      version: "1"                     # a published version number, or DRAFT
 # keep the quotes: a bare 1 fails at boot

Guardrail-Eingabe-Tags hinzufügen

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}
    guardrail:
      id: gr-abc123
      version: "1"
      input_tagging: user_messages

Was Eingabe-Tags nicht abdecken

• Inhalte, die das Gateway nicht taggt: unter anderem Nachrichten, die Ihr input_tagging-Wert auslässt, Tool-Definitionen, Eingaben von Tool-Aufrufen, Bilder und PDFs. Sofern Sie nicht all_messages_and_system setzen, ist auch der System-Prompt nicht getaggt.
• Tool-Ergebnisse: Diese enthalten, was Claudes Tools zurückgeben, etwa Dateiinhalte und Webseiten. In Tests von Anthropic hat ein Wortfilter sie nicht ausgewertet, weder mit noch ohne Tags.

Protokollieren, welcher Guardrail-Filter ausgelöst hat

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}
    guardrail:
      id: gr-abc123
      version: "1"
    guardrail_trace: true              # default false; beside guardrail, not inside it

Bedrock in einem anderen AWS-Konto

upstreams:
  - name: bedrock-isolated
    provider: bedrock
    region: us-east-1
    auth: {}                           # the gateway's own role: it only calls STS
    assume_role:
      role_arn: arn:aws:iam::222222222222:role/claude-gateway-bedrock
      # external_id: ${BEDROCK_ROLE_EXTERNAL_ID}   # when the role's trust policy requires one

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:role/claude-gateway" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "your-external-id" } }
  }]
}

• Wenn STS ablehnt oder nicht erreichbar ist, sendet das Gateway die Anfrage nicht mit den eigenen Anmeldedaten des Upstreams. Es protokolliert den STS-Fehler zusammen mit dem, was zu prüfen ist, und versucht dann den nächsten aufgelisteten Upstream. Upstream-Fehlermeldungen beschreibt, was der Client erhält, wenn kein Upstream erfolgreich ist. Ein späterer Upstream ohne assume_role würde die Anfrage mit seinen eigenen Anmeldedaten bedienen, listen Sie einen solchen also nur auf, wenn Sie das wollen.
• Das Gateway ruft den regionalen STS-Endpunkt sts.<region>.amazonaws.com auf, den sein Netzwerk erreichen muss. Für den FIPS-Endpunkt setzen Sie AWS_USE_FIPS_ENDPOINT=true in der Umgebung des Gateways statt use_fips_endpoint in einer AWS-Konfigurationsdatei.
• assume_role benötigt SigV4-Quell-Anmeldedaten: Das Gateway startet nicht, wenn es zusammen mit aws_bearer_token gesetzt ist.
• Ohne eine groups-Liste kann jeder Entwickler, den das Gateway zulässt, diesen Upstream verwenden. Um einzuschränken, welche Modelle ein Entwickler verwenden kann, setzen Sie availableModels in einer managed-Richtlinie.
• Damit ein über die Rolle bereitgestelltes Modell nicht auch von einem anderen Konto bereitgestellt wird, geben Sie ihm eine benutzerdefinierte ID, deren upstream_model-Zuordnung nur den Namen dieses Upstreams enthält. Bei einer solchen ID überspringt das Gateway jeden anderen Upstream, sodass weder die Anfrage noch die Token-Zählung für eine abgebrochene Anfrage per Failover an ein anderes Konto gehen kann.
• Eine Anfrage für einen integrierten Modellnamen kann diesen Upstream dennoch erreichen, und das Gateway signiert sie mit derselben Rolle. Führen Sie diesen Upstream zuletzt auf, sofern sein Konto diese Modelle nicht ebenfalls bereitstellen soll.

models:
  - id: restricted-claude-opus-4-8      # a custom id, not a built-in model name
    upstream_model:
      bedrock-isolated: us.anthropic.claude-opus-4-8   # the only upstream that serves it

AWS-Kostenzuordnung pro Entwickler

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}                           # the gateway's own role: it only calls STS
    assume_role:
      role_arn: arn:aws:iam::123456789012:role/claude-gateway-bedrock-user
      session_name: email              # or sub

​

Amazon Bedrock Mantle-Endpunkt

upstreams:
  - provider: mantle
    region: us-east-1
    models: [claude-opus-4-7, claude-haiku-4-5]   # required
    auth: {}                           # AWS default credential chain
  - provider: bedrock
    region: us-east-1
    auth: {}

• guardrail: Das Gateway wendet keine Bedrock-Guardrail auf Anfragen an, die es an Mantle sendet, daher weigert es sich zu starten, wenn ein mantle-Upstream aufgelistet ist, während ein bedrock-Upstream guardrail setzt.
• assume_role: Setzen Sie es für den mantle-Upstream selbst. Ohne diese Einstellung werden von Mantle bediente Anfragen mit den eigenen auth-Anmeldedaten des mantle-Upstreams gesendet.

​

Claude Platform on AWS

upstreams:
  - provider: anthropicAws
    region: us-east-1
    workspace_id: wrkspc_...
    auth:
      api_key: ${ANTHROPIC_AWS_API_KEY}   # sent as x-api-key
    # OR SigV4 via the AWS default credential chain:
    # auth: {}
    # OR explicit SigV4 credentials:
    # auth:
    #   aws_access_key_id: ${AWS_ACCESS_KEY_ID}
    #   aws_secret_access_key: ${AWS_SECRET_ACCESS_KEY}
    # Override the derived endpoint:
    # base_url: https://aws-external-anthropic.us-east-1.api.aws

​

Google Cloud Agent Platform

upstreams:
  - provider: vertex
    region: us-east5
    project_id: example-prod
    auth: {}                           # preferred: Application Default Credentials
    # OR a service account key file:
    # auth: { service_account_json: /secrets/sa.json }
    # Override the aiplatform endpoint for Private Service Connect:
    # base_url: https://us-east5-aiplatform.p.googleapis.com

​

Microsoft Foundry

upstreams:
  - provider: foundry
    resource: example-foundry              # https://example-foundry.services.ai.azure.com
    auth: { use_azure_ad: true }        # preferred: DefaultAzureCredential / Managed Identity
    # OR an API key:
    # auth:
    #   api_key: ${FOUNDRY_API_KEY}

​

Statische Header auf Upstream-Anfragen

upstreams:
  - provider: vertex
    region: us-east5
    project_id: example-prod
    base_url: https://upstream-proxy.internal.example.com
    auth: {}
    headers:
      x-source: claude-apps-gateway
      x-proxy-token: ${PROXY_TOKEN}

• authorization und x-api-key
• host, content-type und user-agent
• Jeden Namen, der mit anthropic-, x-goog-, x-amz- oder x-amzn- beginnt

​

Mehrere Upstreams

• Der Upstream ist fehlgeschlagen
• Der Upstream stellt das angeforderte Modell nicht bereit
• Der Upstream hat eine groups-Liste, in der der Entwickler nicht enthalten ist

• provider: anthropic-Upstreams: timeouts.upstream_ttfb_ms, standardmäßig 120 Sekunden
• Andere Anbieter: bis zu einer Stunde. Um diese Wartezeit für Streaming-Anfragen zu verkürzen, setzen Sie timeouts.upstream_ttfb_ms auf Gateway v2.1.295 oder später. Modellanfragen ohne Streaming warten in jedem Fall bis zu einer Stunde

upstreams:
  # Primary: provisioned throughput in your home region.
  - name: bedrock-pt
    provider: bedrock
    region: us-east-1
    auth: {}
  # Overflow: on-demand cross-region.
  - name: bedrock-od
    provider: bedrock
    region: us-west-2
    auth: {}
  # Different account: a separate Bedrock allotment via static keys.
  - name: bedrock-acct2
    provider: bedrock
    region: us-east-1
    auth:
      aws_access_key_id: ${ACCT2_AKID}
      aws_secret_access_key: ${ACCT2_SK}
  # Last resort: direct Anthropic API.
  - name: anthropic-fallback
    provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

# Per-upstream model IDs are keyed on the upstream's `name:`.
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model:
      bedrock-pt: arn:aws:bedrock:us-east-1:111111111111:provisioned-model/abcdef
      bedrock-od: us.anthropic.claude-opus-4-8
      bedrock-acct2: us.anthropic.claude-opus-4-8
      anthropic-fallback: claude-opus-4-8

​

Jedes Team an seinen eigenen Upstream senden

upstreams:
  - name: bedrock-payments
    provider: bedrock
    region: us-east-1
    auth: {}
    assume_role:
      role_arn: arn:aws:iam::111111111111:role/claude-gateway-bedrock
    groups: [payments-eng]
  - name: bedrock-search
    provider: bedrock
    region: us-east-1
    auth: {}
    assume_role:
      role_arn: arn:aws:iam::222222222222:role/claude-gateway-bedrock
    groups: [search-eng]
  - name: bedrock-shared               # no groups: open to everyone, so listed last
    provider: bedrock
    region: us-east-1
    auth: {}

• Einträge: Schreiben Sie jede Gruppe genau so, wie Ihr IdP sie im Groups-Claim sendet, den auch match.groups liest. Das Gateway startet nicht, wenn es eine leere Liste oder einen leeren Eintrag findet. Es prüft einen Eintrag nicht gegen Ihren IdP, sodass ein Eintrag, der auf niemanden zutrifft, keine Warnung auslöst.
• Reihenfolge: Setzen Sie einen Upstream ohne groups-Liste an das Ende. Er bedient alle; steht er weiter vorn, übernimmt er die Anfragen eines Teams vor dessen eigenem Upstream.

Was passiert, wenn ein Entwickler in keiner aufgeführten Gruppe ist

API Error: 400 you aren't in a group that can use this gateway. Ask your administrator to add you to one

• oidc.allowed_groups ist gesetzt: Das Gateway lehnt die Aktualisierung ab, und die Sitzung endet
• Andernfalls, wenn ein Upstream keine groups-Liste hat: Die Anfragen des Entwicklers gehen an diesen Upstream
• Andernfalls, wenn jeder Upstream eine groups-Liste hat: Die Anfragen des Entwicklers schlagen mit diesem Fehler fehl

​

Optionale Abschnitte

​

login_notice

login_notice: This gateway is for Example Corp staff. For access questions, email it-help@example.com.

​

admin

admin:
  # Named static API keys for the admin endpoints, sent as x-api-key.
  # The id appears in the audit log as admin-key:<id> so each key is
  # attributable. Array for rotation: add the new key, roll clients,
  # remove the old.
  write_keys:
    - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
    - { id: ci,        key: "${GATEWAY_ADMIN_WRITE_KEY_CI}" }
  read_keys:
    - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
  # IdP groups granted full admin via the normal gateway JWT (no API key).
  admin_groups: [platform-finops]
  blocked_message: request an increase at https://go.example.com/claude-limits
  # Try eng-platform's pooled budget first, then eng-all's, then any other group's.
  pooled_conflict_rule: priority_list
  pooled_priority_order: [eng-platform, eng-all]

​

Reihenfolge gemeinsamer Budgets

• default_order: das größte Limit zuerst, bei gleichen Limits in aufsteigender Reihenfolge der Gruppennamen
• priority_list: die Budgets der Gruppen in pooled_priority_order in Listenreihenfolge, danach die Budgets der übrigen Gruppen nach Gruppenname

​

enforcement

​

pricing

• Claude Code v2.1.227 oder später auf dem Gateway-Server. Frühere Versionen lehnen den unbekannten Schlüssel beim Start ab.
• Ein admin:-Block oder in v2.1.268 oder später ein managed:-Block mit mindestens einer Richtlinie. Das Gateway weigert sich zu starten, wenn pricing gesetzt ist und keiner der Blöcke vorhanden ist, da nichts es lesen würde.

pricing:
  multiplier: 0.85
  overrides:
    - upstream: bedrock-eu
      model: claude-sonnet-4-6
      input: 3.30
      output: 16.50
      cache_read: 0.33
      cache_write: 4.125

• Eine Zeile ersetzt den Listenpreis für Anfragen, die upstream, ein upstreams[].name, für model bedient. Das schließt den höheren Fast-Modus-Satz ein, sodass Fast- und Standardanfragen mit denselben vier Sätzen gezählt werden.
• Eine integrierte ID wie claude-sonnet-4-6, abgeglichen wie models[].id, deckt jede datierte Form, regionale Amazon-Bedrock-Form oder Google-Cloud-Agent-Plattformform ab, die der Zähler als dieses Modell bewertet. Jede andere Zeichenkette, z. B. ein Alias oder ein Inferenzprofil-ARN, gleicht die ID ab, die der Client gesendet hat, oder die Zeichenkette, die upstream gesendet wurde, Groß-/Kleinschreibung ignoriert.
• Wenn sich Zeilen überlappen, wählt der Zähler die spezifischste Zeile statt der ersten Zeile: eine Zeile, deren model die genaue Modellzeichenkette ist, die upstream gesendet wurde, dann eine Zeile, die die genaue ID abgleicht, die der Client gesendet hat, dann eine Zeile, die das integrierte Modell benennt.
• Ein unbekannter Upstream-Name schlägt beim Start fehl, ebenso wie zwei Zeilen für einen Upstream, die dasselbe Modell benennen, einschließlich zwei Schreibweisen eines integrierten Modells. Das Gateway warnt beim Start vor einer Zeile, die kein anforderbares Modell verwenden kann.
• Web-Such-Anfragen bleiben beim $0,01-Listenpreis; der Multiplikator wird immer noch auf sie angewendet.

​

Preise erhöhen

pricing:
  multiplier: 1.2

​

Sätze an angemeldete Clients senden

• Was das Gateway hinzufügt: Sofern der cli-Block einer Richtlinie nicht bereits modelPricing setzt, fügt das Gateway den multiplier und für jede Modell-ID, die ein Client anfordern kann, die Überschreibungszeile des ersten Upstream hinzu, der diese ID bedient. Ein Satz, den nur ein Failover-Upstream berechnet, bleibt beim Gateway.
• Upstreams mit einer groups-Liste: Ist ein solcher Upstream der erste, der eine Modell-ID bedient, fügt das Gateway für diese ID keine Zeile hinzu. Entwickler sehen dann den eigenen Preis von Claude Code für diese ID, also den Standardpreis des Modells, wenn Claude Code die ID erkennt, multipliziert mit dem multiplier.
• Eine Richtlinie ausschließen: Setzen Sie modelPricing auf {} im cli-Block dieser Richtlinie, und ihre Entwickler bleiben beim Listenpreis.
• Sätze einer Richtlinie behalten: Eine Richtlinie, deren cli-Block modelPricing mit ihrem eigenen multiplier oder overrides setzt, behält dieses modelPricing ganz, und das Gateway fügt keine eigenen Sätze hinzu.

​

models

auto_include_builtin_models: true   # false: expose only the list below
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    # description: optional text shown in clients that surface it
    upstream_model:
      anthropic: claude-opus-4-8
      bedrock: us.anthropic.claude-opus-4-8   # or an inference-profile ARN
      foundry: your-opus-deployment-name

​

managed

managed:
  policies:
    # Specific groups first.
    - match: { groups: [eng-contractors] }
      cli:
        availableModels: [claude-sonnet-4-6]
        permissions: { deny: ["WebFetch", "WebSearch"] }
    # Default catch-all last: matches everyone who authenticated.
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
        # Make the Default option in /model resolve inside each policy's
        # list. The eng-contractors policy inherits enforceAvailableModels.
        enforceAvailableModels: true

• Zulassungslisten: availableModels und permissions.allow. Die Liste einer bestimmten Richtlinie ersetzt die Basis vollständig.
• Denylists und Hook-Arrays: Diese bilden die Vereinigung aus Basis und Richtlinie:
  • permissions.deny und permissions.ask
  • disabledMcpjsonServers und deniedMcpServers
  • blockedMarketplaces und deniedModels
  • Die Event-Typ-Arrays von hooks
• Datensatz-typisierte Schlüssel: env, modelOverrides und skillOverrides. Diese werden flach zusammengeführt, sodass ein Pro-Rollen-env-Block Schlüssel überschreibt, die er setzt, und den Rest von der Basis erbt.

• Wenn der Wert fehlt oder leer ist, lehnt das Gateway die Anfrage mit der Meldung model is required ab. Diese Prüfung erfordert ein Gateway, das Claude Code v2.1.228 oder später ausführt.
• Wenn der Wert vorhanden ist, aber keine Zeichenkette ist, lehnt das Gateway die Anfrage mit der Meldung model must be a string ab. Erfordert ein Gateway, das Claude Code v2.1.221 oder später ausführt.

​

Jede zutreffende Richtlinie anwenden

managed:
  policy_mode: layered
  policies:
    - match: { groups: [no-web] }
      cli:
        permissions: { deny: ["WebFetch"] }
    - match: { groups: [opus-users] }
      cli:
        availableModels: [opus, sonnet]
    - match: {}
      cli:
        availableModels: [sonnet]
        enforceAvailableModels: true

• Allowlists, Einzelwerte und Blöcke wie sandbox: Jeder Wert stammt vollständig aus der zuerst aufgeführten zutreffenden Richtlinie, die ihn setzt, sodass sich die availableModels-Listen zweier Gruppen nicht addieren.
• Denylists und Hook-Arrays: Diese addieren sich über jede zutreffende Richtlinie, sodass ein Benutzer in zwei Gruppen die deny-Regeln beider Gruppen erhält.
• env, modelOverrides und skillOverrides: Einträge werden nach Namen zusammengeführt, und die zuerst aufgeführte zutreffende Richtlinie, die einen Namen setzt, liefert dessen Wert.
• desktop-Schlüssel: Diese werden nach den Regeln für den Basisblock desktop zusammengeführt.

• Ein !-Muster: eine !-Negation in einer Read- oder Edit-Regel in der Liste permissions.deny oder permissions.ask einer beliebigen Richtlinie, die der Richtlinie match: {} eingeschlossen
• Eine Einschränkung von Hooks außerhalb des Catch-all: disableAllHooks, allowedHttpHookUrls oder httpHookAllowedEnvVars in einer anderen Richtlinie als match: {}

​

Sitzungen mit einem Modell starten, das die Richtlinie zulässt

• Ein Alias wie sonnet oder eine integrierte ID wie claude-sonnet-4-6: Sitzungen starten mit einem dieser Modelle, und die Option Default in /model wird zu ihm aufgelöst
• Kein Alias und keine integrierte ID in der Liste: Sitzungen können weiterhin mit dem integrierten Standard starten, setzen Sie daher zusätzlich model im cli-Block dieser Richtlinie auf eine der aufgelisteten IDs

managed:
  policies:
    - match: { groups: [restricted-projects] }
      cli:
        availableModels: [restricted-claude-opus-4-8]
        enforceAvailableModels: true
        model: restricted-claude-opus-4-8
        env:
          ANTHROPIC_DEFAULT_OPUS_MODEL: restricted-claude-opus-4-8   # opus and Default resolve to the ID too

​

Matcher-Werte, die das Gateway beim Start stoppen

• Eine leere groups-Liste
• Ein leerer Eintrag in groups oder in admin_groups
• Eine leere email_domain
• Eine email_domain, die @, Leerzeichen oder ein Komma enthält. Das Gateway trimmt den Wert und entfernt ein führendes @, bevor diese Prüfung durchgeführt wird. Schreiben Sie eine bloße Domäne, z. B. example.com.

• Eine leere email_domain: Das Gateway übersprang die Domänenprüfung, sodass eine Richtlinie mit einer leeren email_domain und keiner groups-Liste jeden authentifizierten Benutzer abglich
• Eine leere groups-Liste: Die Richtlinie glich niemanden ab
• Eine email_domain, die @, Leerzeichen oder ein Komma enthält: Die Richtlinie glich niemanden ab
• Ein leerer Eintrag in groups oder in admin_groups: Der Eintrag glich einen Benutzer nur ab, wenn der groups-Anspruch des IdP dieses Benutzers auch einen leeren Eintrag enthielt. In admin_groups gewährte diese Übereinstimmung Admin-Zugriff. Wenn Ihre admin_groups-Liste niemals einen leeren Eintrag enthielt, erhielt niemand auf diese Weise Admin-Zugriff.

​

cli oder code wählen

• cli: das Terminal, die Erweiterungen für VS Code und JetBrains sowie das Agent SDK. Unter cli erhält der Code-Tab von Claude Desktop die abgeleiteten Einstellungen, sodass eine eingeschränkte Regel wie Read(./.env) einen Benutzer dort nicht aufhält.
• code: dieselben Orte, und auch der Code-Tab von Claude Desktop kann abgedeckt werden.

managed:
  policies:
    - match: {}
      code:
        permissions: { deny: ["Read(./.env)"] }
      desktop: {}

• Um den Code-Tab abzudecken: Wechseln Sie zu code, sobald die Rechner der Benutzer die Bedingungen in code-Einstellungen im Code-Tab anwenden erfüllen
• Um bei cli zu bleiben: Setzen Sie serve_to_desktop: false neben cli in einer Richtlinie, um die Warnung zu unterdrücken

​

Was in cli geht

managed:
  policies:
    - match: {}
      cli:
        # Model access (also enforced server-side at /v1/messages)
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
        enforceAvailableModels: true              # Default resolves inside the list

        # Permission policy
        permissions:
          deny:
            - "WebFetch"
            - "Read(./.env)"
            - "Read(./secrets/**)"
          disableBypassPermissionsMode: disable   # blocks --dangerously-skip-permissions
        allowManagedPermissionRulesOnly: true     # ignore user/project permission rules

        # Environment pushed into the CLI process. DISABLE_UPDATES blocks
        # background and manual updates; DISABLE_AUTOUPDATER stops only
        # background updates.
        env:
          DISABLE_UPDATES: "1"                    # pin versions via your own distribution

        # Org-wide hooks. Hook commands run on developer machines, not the
        # gateway, so the path must exist on every client OS in the policy.
        hooks:
          PostToolUse:
            - matcher: "Edit|Write"
              hooks:
                - { type: command, command: /usr/local/bin/audit-edit.sh }

• hooks
• env-Variablen, die die Genehmigung des Entwicklers erfordern, wie Proxy- und Basis-URL-Variablen
• Shell-Ausführungseinstellungen wie apiKeyHelper und statusLine
• die Sandbox-Binäreinstellungen sandbox.bwrapPath, sandbox.socatPath und sandbox.ripgrep
• Sandbox-Einstellungen, die Datenverkehr abfangen, Anmeldedaten injizieren oder die Isolation schwächen, wie sandbox.network.tlsTerminate und die Proxy-Port-Einstellungen. Sicherheitsgenehmigungsdialoge listet sie alle auf.

​

Eine Richtlinie vor der Bereitstellung testen

​

Kontextfenster in Terminal-Sitzungen

managed:
  policies:
    - match: {}
      cli:
        env:
          CLAUDE_CODE_AUTO_COMPACT_WINDOW: "200000"

​

Einstündiger Prompt-Cache

managed:
  policies:
    - match: {}
      cli:
        promptCacheTtl: 1h
        subagentPromptCacheTtl: 1h

​

MCP-Server in einer Richtlinie

​

Claude Desktop-Überlagerung

Einstellungen, die das Gateway für Claude Desktop ableitet

• Die Modellliste, aus availableModels. Die Liste lässt Modelle aus, die die Richtlinie mit deniedModels oder availableModelsMatch: exact blockiert. Dieser Filter erfordert Claude Code v2.1.299 oder höher auf dem Gateway-Server. Erweiterter Kontext in Claude Desktop behandelt die 1M-Kontextoption jedes Modells
• Deaktivierte Tools aus permissions.deny-Einträgen mit bloßen Tool-Namen. Wenn Sie disabledBuiltinTools im desktop-Block der Richtlinie setzen, bedient das Gateway die Vereinigung Ihres Wertes und der abgeleiteten Liste, sodass Sie auf diese Weise mehr Tools deaktivieren können, aber eines, das Sie durch permissions.deny deaktiviert haben, nicht erneut aktivieren können
• Die Egress-Allowlist, aus sandbox.network.allowedDomains. Wenn Sie coworkEgressAllowedHosts im desktop-Block der Richtlinie setzen, verwendet das Gateway diesen Wert anstelle der abgeleiteten Liste. Wenn die vom Gateway ausgelieferte Allowlist * enthält und das Gateway nicht zusätzlich allowedWorkspaceFolders von Claude Desktop ausliefert, schaltet Claude Desktop die Bash-Sandbox im Code-Tab nicht ein
• Ein OTLP-Endpunkt, der auf das Gateway selbst zeigt, und die Identitätsattribute des angemeldeten Benutzers. Das Gateway leitet die Exporte, die es an diesem Endpunkt erhält, an Ihre forward_to-Ziele weiter. Es enthält den Endpunkt und die Attribute, wenn Sie sowohl telemetry.forward_to als auch listen.public_url setzen. Claude Desktop exportiert jedes Signal mit einer Kodierung: http/protobuf oder http/json, wenn Sie OTEL_EXPORTER_OTLP_PROTOCOL oder eine seiner Pro-Signal-Varianten auf http/json im env der Richtlinie setzen. Vor Claude Code v2.1.261 auf dem Gateway-Server setzte die Antwort http/json unabhängig davon, sodass ein Collector, der nur Protobuf akzeptiert, Claude Desktops Exporte ablehnte

code-Einstellungen im Code-Tab anwenden

• Die Richtlinie hat außerdem einen desktop-Schlüssel, wobei ein leeres desktop: {} zählt
• Claude Desktop hat Version 2.9939.2 oder höher
• Die verwalteten Einstellungen von Claude Code auf dem Rechner nennen dieses Gateway
• Dieser Rechner erreicht das Gateway über HTTPS in einem privaten Netzwerk

• Über HTTPS, wenn Claude Desktop Claude Code v2.1.296 oder höher enthält: Der Code-Tab startet nicht, und die Antwort auf den Prompt des Benutzers nennt den Grund
• Über HTTPS, wenn Claude Desktop eine frühere Version enthält: Der Code-Tab startet ohne Ihre code-Einstellungen, und nichts in der Sitzung weist darauf hin
• Über reines HTTP: Der Code-Tab startet ohne Ihre code-Einstellungen, unabhängig davon, welche Version Claude Desktop enthält

Claude-Desktop-Einstellungen direkt setzen

managed:
  policies:
    - match: { groups: [eng-contractors] }
      cli:
        availableModels: [claude-sonnet-4-6]
        enforceAvailableModels: true
      desktop:
        isLocalDevMcpEnabled: false
        disableAutoUpdates: true
        banner: { text: "Contractor build: internal use only" }

Was das Gateway beim Start ablehnt

• Einen unbekannten Schlüssel
• Einen erkannten Schlüssel, dessen Wert Claude Desktop ablehnen oder stillschweigend verwerfen würde, wie einen leeren Wert oder einen falsch geschriebenen Unterschlüssel in einem verschachtelten Eintrag. Vor v2.1.260 ließ das Gateway ein falsch geschriebenes Feld in einem verschachtelten Objekt eines managedMcpServers- oder orgPluginSettings-Eintrags stillschweigend fallen, anstatt beim Start fehlzuschlagen.
• Einen Schlüssel, den das Gateway selbst berechnet: die Inferenzverbindung, die Modellliste und das OTLP-Relay. Konfigurieren Sie diese durch upstreams, models und forward_to im Abschnitt telemetry.
• Einen Legacy-Alias eines aktuellen Schlüssels. Im Boot-Fehler benennt das Gateway den kanonischen Schlüssel, den Sie schreiben sollten.

Schlüssel, die eine neuere Gateway- oder Claude-Desktop-Version erfordern

Wie eine Rollen-Richtlinie den desktop-Basisblock erbt

• disabledBuiltinTools: Das Gateway verwendet die Vereinigung der Liste der Basis und der Liste der Richtlinie
• builtinToolPolicy: Wenn Sie ein Tool in der Basis auf einen anderen Wert als allow setzen, behält das Gateway diesen Wert, auch wenn Sie allow für das gleiche Tool in einer Rollen-Richtlinie setzen

Wenn eine Richtlinienänderung Claude Desktop erreicht

• Geschlossen: Claude Desktop ruft die Bootstrap-Antwort beim Start ab, daher gilt die Änderung ab dem nächsten Start
• Geöffnet: Claude Desktop prüft standardmäßig alle 10 Minuten auf eine geänderte Antwort und wendet einige Einstellungen ohne Neustart an. Für die übrigen, etwa skillCreationEnabled, sieht der Benutzer in der Seitenleiste eine Karte Relaunch Claude Desktop und behält die vorherige Konfiguration, bis er die App neu startet. Nach standardmäßig 24 Stunden zeigt Claude Desktop einen Neustart-Dialog an und startet nach 2 Minuten Inaktivität selbstständig neu

​

Erweiterter Kontext in Claude Desktop

• Ein Upstream, der den Eintrag bedienen kann, ihn einem Modell ohne 1M-Unterstützung zuordnet, einschließlich eines Upstream, den das Gateway nur bei Failover erreicht
• Weder seine id noch einer seiner upstream_model-Werte ein Claude-Modell benennt, etwa ein benutzerdefinierter Alias, der an einen ARN eines Application-Inference-Profils weitergeleitet wird

• Benutzer mit der 1M-Option starten lassen: Setzen Sie modelPrefer1mContext: true im desktop-Block der Richtlinie. Benutzer, die noch kein Modell gewählt haben, starten mit der 1M-Option, wenn das erste aufgelistete Modell eine hat. Benutzer, die bereits ein Modell gewählt haben, behalten ihre Wahl.
• Die Option manuell anbieten: Tun Sie dies, wenn Ihr Gateway-Server eine ältere Version als v2.1.284 ausführt oder ein Eintrag kein Claude-Modell benennt. Listen Sie das Modell zweimal in models auf, einmal mit seiner einfachen ID und einmal mit angehängtem [1m], beide mit derselben upstream_model-Zuordnung. Claude Desktop zeigt das Paar als ein Modell mit einer 1M-Option an. Das Gateway bedient einen [1m]-Eintrag, ohne ihn zu prüfen, fügen Sie einen solchen Eintrag daher nur für ein Modell hinzu, das Ihre Upstreams mit 1M bedienen.

models:
  - id: corp-sonnet
    upstream_model:
      bedrock: arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/sonnet-5-prod
  - id: corp-sonnet[1m]
    upstream_model:
      bedrock: arn:aws:bedrock:us-east-2:123456789012:application-inference-profile/sonnet-5-prod

managed:
  policies:
    - match: {}
      desktop:
        modelPrefer1mContext: true

Die 1M-Option entfernen

​

Vorrang mit anderen verwalteten Quellen

​

telemetry

telemetry:
  forward_to:
    - url: https://otel-collector.internal.example.com
      headers:
        Authorization: ${OTLP_TOKEN}
      # Per-signal opt-in. Default: metrics only.
      metrics: true
      logs: false
      traces: false
    - url: https://api.datadoghq.com/api/v2/otlp
      headers:
        DD-API-KEY: ${DD_API_KEY}

• http://localhost:<port> besteht die Konfigurationsvalidierung, aber der SSRF-Guard blockiert jeden Export mit ECONNREFUSED_SSRF, es sei denn, Sie setzen CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 in der Umgebung des Gateways
• http://127.0.0.1:<port> oder http://[::1]:<port> schlägt beim Start fehl, es sei denn, diese Variable ist gesetzt

• CLAUDE_CODE_ENABLE_TELEMETRY=1
• OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER und OTEL_TRACES_EXPORTER, jeweils auf otlp gesetzt, wenn mindestens ein forward_to-Ziel dieses Signal aktiviert, und andernfalls auf none
• OTEL_EXPORTER_OTLP_ENDPOINT=<public_url>
• OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

• Lokal gesetzte Variablen: Claude Code wendet die gepushten Variablen auf der verwalteten Ebene an, sodass jede den Wert überschreibt, den ein Entwickler lokal dafür setzt.
• Lokal konfigurierte Endpunkte: Mit aktiviertem OTLP/HTTP-Export ignoriert die CLI jeden lokal konfigurierten Endpunkt, unabhängig davon, ob das Gateway die Telemetrie-Variablen gepusht hat. Ihre Exporte gehen an das Gateway, es sei denn, eine Richtlinie benennt Ihren Collector als Endpunkt.

​

Kumulative Metriken senden

• Terminal-Sitzungen: im env-Block unter dem cli- oder code-Schlüssel einer Richtlinie
• Cowork-Sitzungen, die auf dem Rechner des Benutzers laufen: im env-Block der clientseitigen verwalteten Einstellungen auf diesem Rechner
• Code-Tab-Sitzungen unter einer code-Richtlinie: im env-Block der Richtlinie, sobald Sie die Bedingungen erfüllen, unter denen code-Einstellungen gelten
• Code-Tab-Sitzungen unter einer cli-Richtlinie: im env-Block der clientseitigen verwalteten Einstellungen auf dem Rechner, der die Sitzung ausführt. Über SSH ist das der Remote-Host.

​

Ihre eigenen Labels hinzufügen

telemetry:
  forward_to:
    - url: https://otel-collector.internal.example.com
  resource_attributes:
    service.namespace: claude
    deployment.environment.name: prod

• Namen verwenden nur Buchstaben, Ziffern, ., _ und -
• Namen sind nicht reserviert. Verglichen in jeder Schreibweise sind die reservierten Namen alles, das mit user., enduser. oder identity. beginnt, plus service.name, service.version, claude.deployment_mode, host.arch, os.type, os.version und wsl.version
• Werte sind nicht leeres druckbares ASCII ohne Leerzeichen und ohne eines von , ; = \ " %
• Werte sind höchstens 255 Zeichen lang, wie das Gateway sie nach prozentualem Kodieren zählt, sodass /, : und @ jeweils als drei zählen
• Werte sind Text, setzen Sie daher eine Zahl, true oder false in Anführungszeichen

​

Gruppenänderungen während einer offenen Sitzung

processors:
  resource/drop-user-groups:
    attributes:
      - key: user.groups
        action: delete

​

Direkt an Ihren Collector exportieren

• Der Endpunkt kommt vom Gateway selbst. Wenn Sie die gleiche Variable in einem MDM-Profil oder einer lokalen managed-settings.json setzen, bleiben Exporte auf dem Relay.
• Die URL verwendet https:// oder, bei einer Loopback-Adresse, http://
• Die URL wird zu einem Pfad aufgelöst, der mit /v1/<signal> endet, ohne Abfrage oder Fragment. Claude Code erstellt diesen Pfad selbst aus der generischen Variable. Eine Pro-Signal-Variable wie OTEL_EXPORTER_OTLP_METRICS_ENDPOINT verwendet es wie geschrieben, geben Sie dort daher den vollständigen Pfad an.
• Die URL ist nicht der eigene Host des Gateways. Ein Endpunkt, der an das Gateway adressiert ist, behält den Relay-Pfad und sein Sitzungstoken.
• Weder Sie noch der Entwickler haben otelHeadersHelper in einer Einstellungsquelle konfiguriert. Mit einem konfigurierten Helper bleibt jedes Signal auf dem Relay.

• Wenn das Gateway bereits die Telemetrie-Variablen pusht, decken sie Aktivierung, Selektoren und Protokoll ab, und Ihr expliziter Endpunkt überschreibt den gepushten <public_url>-Wert. Setzen Sie einen OTEL_*_EXPORTER-Selektor nur für ein Signal selbst auf otlp, das kein forward_to-Ziel aktiviert.
• Wenn nicht, setzen Sie auch CLAUDE_CODE_ENABLE_TELEMETRY=1, die OTEL_*_EXPORTER-Selektoren und OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf.

​

Wenn ein Ziel fehlschlägt

​

HTTP-Optimierung

• Beim Start: eine Warnung im Betriebs-Log empfiehlt, nur die privaten Bereiche 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10, 127.0.0.0/8, ::1/128 und fc00::/7 zuzulassen, plus alle anderen internen Bereiche, von denen sich Ihre Entwickler verbinden. Wenn Sie das Gateway an eine Loopback-Adresse binden und weder trusted_proxies noch public_url setzen, wie in der lokalen Entwicklung, erscheint die Warnung nicht.
• Zur Laufzeit: Wenn zum ersten Mal eine Anfrage von einer Adresse außerhalb dieser privaten Bereiche ankommt, protokolliert das Gateway eine Warnung und gibt ein access.public_client-Audit-Ereignis aus, das die Client-IP trägt. Beide werden einmal pro Prozess ausgelöst. Link-lokale Adressen, 169.254.0.0/16 und fe80::/10, zählen nicht als öffentlich. Das Gateway antwortet auf /healthz und /readyz, bevor diese Prüfung ausgeführt wird, sodass Health-Probes aus öffentlichen Bereichen sie nicht auslösen.

​

load_test_mode

load_test_mode:
  enabled: true
  reply_tokens: 750     # roughly how many tokens of text each canned reply carries
  reply_seconds: 9.5    # how long a streamed reply takes

​

Vollständiges Beispiel

# Laufen mit:
#   claude gateway --config gateway.yaml
#
# Operatives Log-Verbosity wird durch die Umgebungsvariable CLAUDE_GATEWAY_LOG_LEVEL
# gesteuert (debug | info | warn | error; Standard info). debug
# protokolliert auch die Anspruchsnamen in jedem id_token zur Diagnose von groups_claim.
# Es beeinflusst nicht Audit-Ereignisse, die immer ausgegeben werden.
# Setzen Sie CLAUDE_GATEWAY_LOG_FORMAT=json, um operative Log-Zeilen als JSON-
# Objekte mit severity, time und message zu schreiben.

listen:
  host: 0.0.0.0
  port: 8080
  public_url: https://claude-gateway.internal.example.com
  # Lassen Sie den tls-Block weg, wenn Sie hinter einem TLS-beendenden Ingress laufen.
  # tls:
  #   cert: /certs/gateway.crt
  #   key: /certs/gateway.key
  # trusted_proxies:
  #   - 10.0.0.0/8

oidc:
  issuer: https://example.okta.com
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains:
    - example.com
  # Erforderlich, wenn der Aussteller der Okta-Org-Server ist, dessen id_tokens
  # E-Mail und Gruppen auslassen können; das Gateway füllt sie von /userinfo.
  userinfo_fallback: true
  # allowed_groups: [claude-code-users]
  # Okta gibt Gruppen nur aus, wenn der `groups`-Bereich angefordert wird und die
  # App-Gruppenanspruchsfilter sie erlauben. Die Contractor-Richtlinie unten
  # passt auf Gruppen, also wird der Bereich hier angefordert.
  scopes: [openid, profile, email, offline_access, groups]
  # extra_auth_params: { access_type: offline, prompt: consent }  # Google
  # groups_claim: groups          # Entra-App-Rollen: verwenden Sie `roles`
  # email_claim: email

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}   # openssl rand -base64 32
  # ttl_hours: 1

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}
  # max_connections: 5
  # connect_timeout_seconds: 5
  # readiness_grace_seconds: 300   # die Readiness-Prüfung während eines Datenbank-Failovers weiterhin bestehen

# Hinweis, der bei der Anmeldung angezeigt wird. Jeder, der das Gateway erreichen kann, kann ihn lesen.
# login_notice: This gateway is for Example Corp staff. For access questions, email it-help@example.com.

# Aktiviert /v1/organizations/spend_limits (spiegelt die Anthropic Admin API)
# und Pro-Entwickler-Ausgabendurchsetzung auf /v1/messages. Lassen Sie weg, um zu deaktivieren.
# Caps selbst werden über die Admin API gesetzt, nicht hier.
# admin:
#   write_keys:
#     - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
#   read_keys:
#     - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
#   admin_groups: [platform-finops]
#   blocked_message: request an increase at https://go.example.com/claude-limits
#   # audit_retention_days: 365
#   # spend_retention_months: 13
#   # identity_retention_days: 90
#   # group_limit_mode: min
#   # pooled_conflict_rule: priority_list
#   # pooled_priority_order: [eng-platform, eng-all]

# enforcement:
#   fail_closed_on_error: false

# Laden Sie diese Bereitstellung zu Testzwecken, ohne einen Modell-Provider aufzurufen. Niemals auf einem
# Gateway, das Entwickler verwenden: jede Anfrage erhält eine vorgefertigte Antwort.
# load_test_mode:
#   enabled: true
#   # reply_tokens: 750
#   # reply_seconds: 9.5

# Meter zu vertraglich vereinbarten Sätzen statt USD-Listenpreis. Erfordert admin: oder eine
# managed:-Richtlinie. Mit managed: gehen die gleichen Sätze auch an angemeldete Clients.
# Die folgenden Sätze sind Platzhalter, keine echten Vertragspreise.
# pricing:
#   multiplier: 0.85
#   overrides:
#     - { upstream: anthropic, model: claude-sonnet-4-6, input: 3.30, output: 16.50, cache_read: 0.33, cache_write: 4.125 }

upstreams:
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

  # - provider: bedrock
  #   region: us-east-1
  #   auth: {}

  # - provider: mantle
  #   region: us-east-1
  #   models: [claude-opus-4-8, claude-opus-4-7, claude-haiku-4-5]
  #   auth: {}

  # - provider: anthropicAws
  #   region: us-east-1
  #   workspace_id: wrkspc_...
  #   auth:
  #     api_key: ${ANTHROPIC_AWS_API_KEY}

  # - provider: vertex
  #   region: us-east5
  #   project_id: example-prod
  #   auth: {}

  # - provider: foundry
  #   resource: example-foundry
  #   auth: { use_azure_ad: true }

auto_include_builtin_models: true
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model:
      anthropic: claude-opus-4-8
      # bedrock: us.anthropic.claude-opus-4-8
      # mantle: anthropic.claude-opus-4-8
      # anthropicAws: claude-opus-4-8
      # vertex: claude-opus-4-8
      # foundry: <your-opus-deployment-name>
  - id: claude-sonnet-4-6
    label: Claude Sonnet 4.6
    upstream_model:
      anthropic: claude-sonnet-4-6
  - id: claude-haiku-4-5
    label: Claude Haiku 4.5
    upstream_model:
      anthropic: claude-haiku-4-5

managed:
  policies:
    - match: { groups: [contractors] }
      cli:
        availableModels: [claude-haiku-4-5]
        # allow genehmigt diese Tools automatisch; es blockiert nicht den Rest.
        # Fügen Sie deny-Regeln hinzu, um Tools zu beschränken.
        permissions: { allow: [Read, Grep] }
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
        # Beschränken Sie die Standard-Picker-Option auf die availableModels der jeweiligen
        # Richtlinie statt des integrierten Standards, sodass keine Rolle einen 400 auf dem Standard erhält.
        # Die Contractor-Richtlinie erbt diesen Schlüssel.
        enforceAvailableModels: true
        permissions:
          allow: [Read, Grep, Edit]
          deny: ["WebFetch"]
        env: { HTTP_PROXY: http://proxy.example.com:8080 }

telemetry:
  forward_to:
    - url: https://otel.internal.example.com:4318
      headers:
        Authorization: Bearer ${OTEL_TOKEN}

​

Client-seitige verwaltete Einstellungen

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge"
}

​

Verwandt

• Claude Apps Gateway-Übersicht: Schnellstart und Entwickler-Verbindung
• Bereitstellungsleitfaden: IdP-Setup, Container-Image, Kubernetes und Cloud Run sowie Operationen
• Ausgabenlimits: Pro-Entwickler-Caps und die Admin API