Claude-Apps-Gateway für Amazon Bedrock, Claude Platform auf AWS, Google Cloud und Microsoft Foundry

Führen Sie Claude Code über Amazon Bedrock, Claude Platform auf AWS, Google Cloud oder Microsoft Foundry hinter einem selbstgehosteten Gateway mit SSO-Anmeldung, Modellzugriff pro Gruppe und OTLP-Telemetrie aus.

Claude-Apps-Gateway ist ein selbstgehosteter Service, der sich zwischen den Claude-Code-Clients Ihrer Entwickler und Ihrem Modellanbietern befindet. Entwickler melden sich mit Ihrem Unternehmensidentitätsanbieter (IdP) an, anstatt API-Schlüssel oder Cloud-Anmeldedaten zu halten. Das Gateway hält die Upstream-Anmeldedaten, erzwingt Modellzugriff und verwaltete Einstellungen nach IdP-Gruppe und leitet Nutzungstelemetrie an Ihren eigenen Observability-Stack weiter.

Es ist in der claude-Binärdatei enthalten, daher führt die gleiche ausführbare Datei, die Claude Code auf einem Laptop ausführt, den Gateway-Server mit claude gateway --config gateway.yaml aus.

Diese Seite behandelt:

• Warum Claude-Apps-Gateway, was es gegenüber dem Betrieb Ihres eigenen hinzufügt, und wann etwas anderes besser passt
• Ein Schnellstart mit Voraussetzungen, der ein Gateway von Null zu einem angemeldeten Entwickler bringt
• Entwickler verbinden, einschließlich der Einstellung der Gateway-URL durch verwaltete Einstellungen
• Verfügbarkeit und Einschränkungen, die abdecken, welche Claude-Code-Funktionen über das Gateway funktionieren und was der Server unterstützt

Begleitseiten gehen tiefer. Die Konfigurationsreferenz behandelt jede Option in der YAML-Datei, die der Schnellstart schreibt, und der Bereitstellungsleitfaden behandelt IdP-spezifische Einrichtung, Kubernetes- und Cloud-Run-Bereitstellung sowie Operationen.

Warum Claude apps gateway

Die Gateway-Übersicht behandelt, was ein Gateway tut und warum Sie eines ausführen würden. Claude apps gateway ist Anthropics eigenes Gateway, das in die claude-Binärdatei integriert und neben jeder Claude-Code-Version getestet wird, daher leitet es die Header und Anforderungsfelder weiter, die Claude Code sendet, ohne dass Operatoren eine separate Zulassungsliste verwalten müssen. Nach der Bereitstellung erhalten Sie:

• Anmeldedaten: Der Upstream-API-Schlüssel oder die Cloud-Anmeldedaten befinden sich nur in Ihrer Infrastruktur. Entwickler authentifizieren sich mit Corporate SSO und erhalten kurzlebige Bearer-Token, daher erfolgt das Offboarding in Ihrem IdP. Heben Sie die Bereitstellung eines Benutzers auf und sein Gateway-Zugriff läuft innerhalb der Sitzungsdauer ab, standardmäßig eine Stunde.
• Zugriffskontrolle: Ihre IdP-Gruppen werden Modellzulassungslisten und verwaltete Einstellungen-Richtlinien zugeordnet. Das Gateway erzwingt Modellzugriff auf der Serverseite, lehnt Anfragen für nicht gewährte Modelle ab und wählt die verwaltete Einstellungsrichtlinie jeder Gruppe aus, die die CLI auf der Ebene der verwalteten Einstellungen anwendet. Verschiedene Teams erhalten verschiedene Modelle, Tools und Berechtigungen, und ein Entwickler kann nicht überschreiben, was seine Richtlinie sperrt.
• Einstellungsbereitstellung: Das Gateway liefert verwaltete Einstellungen selbst an angemeldete Clients und ersetzt servergesteuerte Einstellungen aus der claude.ai-Admin-Konsole.
• Telemetrie: Jedes konfigurierte Ziel empfängt OpenTelemetry-Protokoll (OTLP)-Metriken mit Token-Zählungen, Modell, Benutzeridentität und Latenz standardmäßig, mit Protokollen und Traces als optionale Ziele pro Ziel.
• Upstream-Routing: Clients sprechen die Anthropic Messages API mit dem Gateway, und das Gateway übersetzt für jeden Upstream, ob Amazon Bedrock, Claude Platform on AWS, Google Clouds Agent Platform, Microsoft Foundry oder die Anthropic API, mit Failover zwischen ihnen. Sie können Regionen, Anbieter oder Failover-Reihenfolge ändern, ohne dass Entwickler dies bemerken oder neu konfigurieren müssen.

Welche Claude-Code-Funktionen über das Gateway funktionieren und was der Server selbst unterstützt, siehe Verfügbarkeit und Einschränkungen unten. Für Entscheidungen wie Kosten, Umgehung, Ausführung mehrerer Gateways und serverlose Plattformen siehe den Bereitstellungsleitfaden.

Andere Gateway-Implementierungen

Wenn Sie bereits ein LLM-Gateway oder API-Gateway ausführen, das Ihre Anforderungen erfüllt, verwenden Sie es weiterhin; Andere LLM-Gateways behandelt die Konfiguration von Claude Code dagegen.

Die Gateway-Kompatibilitätsleitfaden dokumentiert, was Claude Code von jedem Gateway erwartet: die Endpunkte, die es aufruft, die Header und Body-Felder zum Weiterleiten und was nicht funktioniert, wenn sie entfernt werden. Ein laufendes Claude-Apps-Gateway bedient auch sein eigenes Protokoll unter GET /protocol, das die Endpunkte beschreibt, die es Claude-Code-Clients bereitstellt: SSO-Anmeldung, Inferenz, Verwaltete-Einstellungen-Bereitstellung, Modellermittlung und Telemetrie. Rufen Sie es mit curl https://claude-gateway.internal.example.com/protocol von jedem bereitgestellten Gateway ab, wie dem, das der Schnellstart unten erzeugt.

Breaking Changes am Protokoll werden im Voraus angekündigt, aber unbegrenzte Rückwärtskompatibilität ist nicht garantiert.

Schnellstart

Dieser Schnellstart führt den minimalen Weg: Registrieren Sie einen OAuth-Client in Ihrem IdP, schreiben Sie eine gateway.yaml, führen Sie das Gateway zusammen mit Postgres mit Docker Compose aus und überprüfen Sie die Anmeldung von Ende zu Ende. Es verwendet einen Amazon-Bedrock-Upstream; Claude Platform auf AWS, Google Clouds Agent Platform, Microsoft Foundry und die Anthropic API werden gleichermaßen unterstützt, indem Sie den upstreams-Block wie in der Konfigurationsreferenz gezeigt austauschen. Am Ende haben Sie ein Gateway, bei dem sich ein Entwickler /login anmelden kann.

Voraussetzungen

Haben Sie diese vor dem Start bereit:

Schritte

listen:
host: 0.0.0.0
port: 8080
# Erforderlich, sofern der Host keine Loopback-Adresse ist. Wird für den IdP
# redirect_uri und das Discovery-Dokument verwendet.
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # muss /.well-known/openid-configuration bedienen
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # lehne id_tokens außerhalb Ihrer Organisation ab
userinfo_fallback: true                  # für IdPs, deren id_token E-Mail/Gruppen auslässt; ansonsten harmlos

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # begrenzt auch die Widerrufungslatenz bei IdP-Entbereitstellung

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # fügen Sie ?sslmode=require für verwaltetes Postgres hinzu

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # leer: AWS-Standard-Anmeldekette
# (IRSA, EC2/ECS-Task-Rolle, Umgebungsvariablen, ~/.aws)

# Modelle werden pro Upstream automatisch übersetzt. Der integrierte Katalog
# ordnet claude-opus-4-8 us.anthropic.claude-opus-4-8 zu und so weiter für jedes
# von Bedrock unterstützte Claude-Modell. Setzen Sie false und fügen Sie eine `models:`-Liste hinzu, um
# nur bestimmte Modelle verfügbar zu machen.
auto_include_builtin_models: true

services:
gateway:
image: registry.example.com/claude-gateway:2.1.198
ports: ["8080:8080"]
volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
environment:
OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
# AWS-Anmeldedaten: in der Produktion diese auslassen und eine Instance-Rolle verwenden.
# Für lokales Compose-Testen, übergeben Sie Ihre eigenen:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
depends_on:
postgres:
condition: service_healthy
postgres:
image: postgres:16-alpine
environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
healthcheck:
test: ["CMD-SHELL", "pg_isready -U gw"]
interval: 5s
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
"issuer": "https://claude-gateway.internal.example.com",
"device_authorization_endpoint": "…/oauth/device_authorization",
"token_endpoint": "…/oauth/token",
"grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
"device_code": "…",
"user_code": "WDJB-MJHT",
"verification_uri": "https://claude-gateway.internal.example.com/device",
"verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
"expires_in": 600,
"interval": 5
}

Entwickler verbinden

Entwickler verbinden sich von ihren eigenen Laptops mit einer Browser-Anmeldung, indem sie ihr Unternehmensarbeitskonto verwenden. Sie benötigen kein claude.ai-Konto, keinen API-Schlüssel und kein Abonnement, da Anfragen an das Modell über das Gateway mit den Upstream-Anmeldedaten der Organisation gehen. Die Verbindung wird durch die clientseitigen verwalteten Einstellungen gesteuert, die Sie über MDM pushen, daher gibt es keine manuelle Einrichtung auf der Entwicklerseite; dieser Abschnitt behandelt, was der Admin konfiguriert.

Die CLI fingerabdruckt das TLS-Blatt-Zertifikat des Gateways beim ersten Verbinden und heftet es pro Hostname an. Sie überprüft diesen Pin erneut während der Anmeldung, bei stillen Sitzungsaktualisierungen und beim Abrufen verwalteter Einstellungen, während Inferenzanfragen die standardmäßige TLS-Validierung ohne Pin verwenden. Anfragen, die über einen HTTPS-Proxy weitergeleitet werden, überspringen die Pin-Überprüfung, daher fügen Sie den Gateway-Host zu NO_PROXY hinzu, um sie direkt zu halten.

Veröffentlichen Sie den erwarteten SHA-256-Fingerabdruck zusammen mit der Gateway-URL, damit Entwickler etwas zum Vergleichen haben. Die /login-Eingabeaufforderung zeigt die ersten 16 Zeichen des Fingerabdrucks als Kleinbuchstaben-Hexadezimal ohne Doppelpunkte. Um den vollständigen Fingerabdruck in dieser Form aus der Zertifikatsdatei auszudrucken, führen Sie aus:

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

Wenn das Zertifikat rotiert, sieht jeder Entwickler die Vertrauensaufforderung erneut, daher behandeln Sie Rotationen als geplantes Ereignis und veröffentlichen Sie den Fingerabdruck erneut. Wenn Ihre Gateway-Richtlinie Einstellungen enthält, die Genehmigung benötigen, sieht der Entwickler auch diesen Genehmigungsdialog erneut nach Akzeptanz des neuen Zertifikats, da Claude Code die Genehmigungserinnerung an das angeheftete Zertifikat bindet.

Ein Gateway kann das optionale Feld email in seiner Token-Antwort zurückgeben, um das Konto zu benennen, das eine Anmeldung verwendet hat. Wenn es das tut, bestätigt der Entwickler das Konto, bevor Claude Code die Anmeldedaten speichert. Nach einer bestätigten Anmeldung zeigt /status das Konto an.

Die Bestätigung erfordert Claude Code v2.1.275 oder später auf der Entwicklermaschine; ein Client unter dieser Version ignoriert das Feld. Der Gateway-Server in der claude-Binärdatei gibt das Feld nicht zurück, daher werden seine Anmeldungen ohne die Bestätigung abgeschlossen.

Sobald sich der Entwickler angemeldet hat, zeigt die Modellauswahl die Modelle in der availableModels-Zulassungsliste des Entwicklers. Verwaltete Einstellungen werden beim Start angewendet und stündlich aktualisiert, und Telemetrie wird an Ihren Collector weitergeleitet.

Sitzungen werden vor Ablauf von ttl_hours stillschweigend aktualisiert. Wenn eine Aktualisierung nach IdP-Entbereitstellung fehlschlägt, fordert Claude Code den Entwickler auf, sich erneut anzumelden.

Gateway-URL festlegen

Drei Schlüssel gehen in die Pro-OS-Datei mit verwalteten Einstellungen, die Sie über MDM oder direkt auf der Festplatte bereitstellen. forceLoginMethod und forceLoginGatewayUrl öffnen /login direkt auf dem Cloud gateway-Bildschirm mit der ausgefüllten URL, und parentSettingsBehavior: "merge" ermöglicht es Claude Desktop, die Egress-Zulassungsliste des Gateways an die Claude Code-Sitzungen zu liefern, die es startet, wie in Richtlinie an Claude Desktop-Sitzungen liefern erläutert:

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

Der Entwickler drückt Enter, um sich zu verbinden. Die Fingerabdruck-Eingabeaufforderung beim ersten Verbinden wird immer noch angezeigt. Sobald die Datei auf einer Maschine vorhanden ist, sieht ein Entwickler, der die Gateway-Anmeldung nicht abgeschlossen hat, eine der unter Administratorrichtlinie erfordert eine Cloud-Gateway-Anmeldung beschriebenen Meldungen. Entwickler, die einen Cloud-Anbieter über eine Umgebungsvariable wie CLAUDE_CODE_USE_BEDROCK auswählen, benötigen die Gateway-Anmeldung nicht.

Ein Entwickler kann dies nicht manuell einrichten. Die Anmeldungsauswahl hat keine Gateway-Option, und forceLoginGatewayUrl wird in den eigenen Einstellungsdateien eines Entwicklers ignoriert. forceLoginMethod allein, ohne URL, lässt den Entwickler bei einer „Kontaktieren Sie Ihren IT-Administrator"-Nachricht. Die Anmeldeschlüssel gehören in die Datei, die Sie auf Maschinen pushen, nicht in den managed.policies[].cli-Block des Gateways, der nur bereits verbundene Clients erreicht.

Ein Gateway auf öffentlichem Adressraum zulassen, den Sie besitzen

Einige Organisationen nummerieren ihr internes Netzwerk aus einem öffentlichen IPv4-Block, den sie besitzen, wie z. B. den eigenen Adressraum eines Carriers oder ein Legacy-/8, daher kann ihr Gateway keine private Adresse haben. Listen Sie diese Blöcke in der verwalteten Einstellung gatewayInternalNetworks auf. /login akzeptiert dann ein Gateway in einem aufgelisteten Block, wenn sich die Maschine des Entwicklers von einer Adresse in demselben Block aus damit verbindet. Dies erfordert Claude Code v2.1.268 oder später auf der Entwicklermaschine; frühere Versionen ignorieren den Schlüssel und wenden die Regel für private Adressen an.

Fügen Sie den Schlüssel zur gleichen verwalteten Einstellungsquelle wie die Anmeldeschlüssel hinzu: die Datei mit verwalteten Einstellungen, das MDM-Profil oder die Registrierungsrichtlinie. Claude Code ignoriert ihn in Benutzer-, Projekt- und Server-verwalteten Einstellungen.

Dieses Beispiel deklariert einen Block. Ersetzen Sie 203.0.113.0/24 durch Ihren eigenen Block. Es ist ein Dokumentationsbereich, und Claude Code lehnt diese ab.

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

Claude Code validiert die Liste bei /login, bevor sie sich mit einem Gateway verbindet:

• Jeder Eintrag ist ein IPv4-Block, geschrieben als seine erste Adresse und ein Präfix von /8 bis /32.
• Die Liste enthält höchstens vier Blöcke, und keine zwei überlappen sich.
• Kein Block überlappt privaten Adressraum: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 und 100.64.0.0/10. /login akzeptiert ein Gateway dort bereits ohne diesen Schlüssel.
• Kein Block überlappt Raum, der niemals das Netzwerk einer Organisation ist: 198.18.0.0/15 und 192.0.0.0/24, die VPN- und NAT64-Clients als lokale Adressen halten; die Dokumentationsbereiche 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24; und die reservierten Bereiche 0.0.0.0/8, 192.88.99.0/24 und Multicast 224.0.0.0/4. Sie können Blöcke in 240.0.0.0/4 deklarieren, die einige große Netzwerke als internen Unicast-Raum verwenden.

Blöcke aus managed-settings.json und seinen managed-settings.d/-Drop-in-Dateien kombinieren sich zu einer Liste, und diese Grenzen gelten für die kombinierte Liste. Um einen Block zu verengen, ersetzen Sie seinen Eintrag, anstatt einen zweiten, überlappenden in einem Drop-in hinzuzufügen; /login lehnt die Überlappung ab.

Wenn ein Eintrag eine Regel bricht oder der Wert keine Liste von Strings ist, lehnt Claude Code jede neue Gateway-Anmeldung auf dieser Maschine ab und benennt das Problem in der Nachricht. Die Anmeldung bei einem Gateway auf einer privaten Adresse schlägt ebenfalls fehl, und bestehende Anmeldungen funktionieren weiterhin. Versuchen Sie den Wert auf einer Maschine, bevor Sie ihn bereitstellen. Claude Code listet auch einen falsch typisierten Wert unter den ungültigen verwalteten Einstellungen auf, die es meldet.

Mit einer gültigen Liste wendet /login drei Überprüfungen auf ein Gateway an, dessen Adresse in einem aufgelisteten Block liegt:

• Jede Adresse, zu der sich der Hostname des Gateways auflöst, liegt in diesem einen Block. Claude Code lehnt einen Namen ab, der auch Datensätze außerhalb davon, private und IPv6-Adressen eingeschlossen, hat.
• Die Maschine des Entwicklers verbindet sich von innerhalb desselben Blocks. Claude Code lehnt eine Maschine hinter NAT, in einem Container oder WSL2 oder auf einem VPN ab, dessen Adresspool außerhalb des Blocks liegt, und benennt die Adresse, von der sich die Maschine verbunden hat.
• Die Verbindung ist direkt. Wenn HTTPS_PROXY für den Gateway-Host gilt, lehnt /login ab und benennt den NO_PROXY-Eintrag, der hinzugefügt werden soll.

Wenn alle drei bestanden werden, fügt die Vertrauensaufforderung eine Zeile hinzu, die die Adresse der Maschine, die Adresse des Gateways und den deklarierten Block, der beide enthält, benennt.

Der Schlüssel ändert nichts für andere Gateways: Die Anmeldung bei einem auf einer privaten Adresse funktioniert wie zuvor, und die Anmeldung bei einem auf einer öffentlichen Adresse außerhalb jeden aufgelisteten Blocks wird wie zuvor abgelehnt.

Ein deklarierter Block verengt, wer sich anmelden kann, beweist aber nicht, wo sich eine Maschine befindet, daher deklarieren Sie nur Adressraum, den Ihre Organisation kontrolliert. Ein Block, der mit anderen Mandanten geteilt wird, wie z. B. ein öffentlicher Bereich eines Cloud-Anbieters, lässt jeden darin die gleiche Überprüfung bestehen.

Richtlinie an Claude Desktop-Sitzungen liefern

Claude Desktop führt seine Cowork- und Code-Registerkarten sowie die Chat-Registerkarte, wenn Sie diese aktivieren, auf eingebetteten Claude Code-Sitzungen aus und sendet ihre Modellanfragen durch das Gateway. Es übergibt die Richtlinie an jede dieser Sitzungen, aufgebaut aus der Konfiguration, die das Gateway ihr unter /user/bootstrap bereitstellt: die Modellzulassungsliste, deaktivierte Tools und die Egress-Zulassungsliste, die aus dem cli-Block der übereinstimmenden Richtlinie abgeleitet ist, plus die desktop-Überlagerung.

Andere cli-Schlüssel, wie Hooks, env und bereichsbezogene Berechtigungsregeln wie Bash(npm *), erreichen nur Clients, die sich über /login anmelden. Claude Desktop liest die Gateway-URL aus seiner eigenen verwalteten Konfiguration und meldet sich mit seinem eigenen Fluss an, getrennt von den forceLoginMethod- und forceLoginGatewayUrl-Schlüsseln in Gateway-URL festlegen.

Einstellungen, die von einem startenden Prozess übergeben werden, sind übergeordnete Einstellungen. Claude Code ignoriert übergeordnete Einstellungen auf jeder Maschine, die eine von einem Admin bereitgestellte verwaltete Quelle hat, es sei denn, die Quelle, die die Richtlinie liefert, setzt parentSettingsBehavior: "merge".

Welche Maschinen benötigen die Opt-in

Maschinen, die nur Claude Desktop ausführen, benötigen sie. Claude Desktop wendet die Modelliste und die Liste der deaktivierten Tools auf eingebettete Sitzungen selbst an, aber die Egress-Zulassungsliste erreicht sie nur als übergeordnete Einstellungen, in Form von WebFetch-Domänenregeln und Sandbox-Netzwerkregeln. Ohne die Opt-in führen diese Sitzungen ohne die Egress-Einschränkung aus, und nichts warnt Sie. Das Gateway lehnt weiterhin Inferenzanfragen für Modelle ab, die die Richtlinie nicht gewährt.

Maschinen, auf denen sich Entwickler über /login anmelden, benötigen sie nicht; jede Claude Code-Sitzung ruft ihre Richtlinie vom Gateway ab.

Flotten, deren policyHelper verwaltete Einstellungen liefert, können sie nicht verwenden: Claude Code führt übergeordnete Einstellungen auf diesen Flotten niemals zusammen, da es verwaltete Einstellungen nur aus der Ausgabe des Helpers liest.

Opt-in festlegen

Stellen Sie das Snippet für verwaltete Einstellungen aus Gateway-URL festlegen bereit, spiegeln Sie es auf jede clientseitige Quelle, die die Datei überragt, und überprüfen Sie es.

Übergeordnete Einstellungen einschränken

Sobald Sie parentSettingsBehavior: "merge" bereitstellen, kann jeder Host-Prozess, der Claude Code startet, übergeordnete Einstellungen liefern, nicht nur Claude Desktop, sondern auch eine Agent SDK-Anwendung oder eine IDE-Erweiterung.

Claude Code filtert übergeordnete Einstellungen gegen eine Zulassungsliste restriktiver Schlüssel, aber einige zulässige Schlüssel können Zugriff gewähren statt ihn einzuschränken. Wenn Sie die allowManaged*Only-Sperren nicht setzen, gelten Berechtigungszulassungsregeln und Sandbox-Zulassungslisten, die vom Host bereitgestellt werden, weiterhin. Die Deny- und Ask-Regeln Ihrer Richtlinie bleiben in jedem Fall gültig; sie werden vor jeder Zulassungsregel ausgewertet.

Claude Code leitet übergeordnete sandbox.credentials-Einträge in gestreifter Form weiter:

• deny-Einträge: weitergeleitet mit nur ihrem path oder name und dem Modus.
• Dateieinträge mit mode: mask: weitergeleitet nur als Sentinel, als vollständige Dateimaskierung, deren injectHosts die leere Liste ist, daher ersetzt der Proxy niemals den echten Wert für einen übergeordneten Eintrag auf einer beliebigen Plattform. Alle strukturierten Maskierungsfelder werden ebenfalls gelöscht, daher kann ein übergeordnetes Extraktionsmuster keine strengere Maskierung verdrängen, die eine andere Quelle für denselben Pfad setzt.
• envVars-Einträge mit mode: mask: nicht weitergeleitet. deny ist die einzige Einschränkung, die der übergeordnete Kanal durch envVars-Einträge ausdrücken kann.
• awsPairs und sigv4: Einschränkung nur weitergeleitet. Aus sigv4 werden nur deny-Werte beibehalten, und ein übergeordneter, der einen sigv4-Block überhaupt definiert, heftet alle drei Anforderungsformen, streaming, presigned und sigv4a, an deny. Ein awsPairs-Paar wird niemals in einer Form weitergeleitet, die erneut signieren kann; ein Paar, das eine der konventionellen AWS-Variablen benennt, wird durch einen inerten Eintrag ersetzt, der die automatische Kopplung von AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN unterdrückt.

Sperren bereitstellen

Um übergeordnete Einstellungen so nah wie möglich an restriktiv zu halten, wie der Filter unterstützt, fügen Sie alle fünf allowManaged*Only-Sperren und die Zulassungslisten, die sie regeln, zu denselben Quellen wie die Merge-Opt-in hinzu:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

Eine OS-Richtlinie, wie eine HKLM-Registrierungsrichtlinie oder eine verwaltete Preferences-Plist, überragt diese Datei, daher liefern Sie das gesamte Snippet stattdessen durch sie. Die Remote-Verwaltungseinstellungen des Gateways überragen die OS-Richtlinie und Dateiquellen, erreichen aber nur verbundene Clients. Spiegeln Sie die Sperren, die Zulassungslisten und die Merge-Opt-in in den cli-Block der Richtlinie und behalten Sie diese Datei bereitgestellt, da Maschinen, die sich niemals verbinden, einschließlich solcher, die nur Claude Desktop ausführen, ihre Richtlinie nur aus der Datei erhalten.

Sperrverhalten über Quellen hinweg

Das Setzen einer Sperre schränkt die anderen nicht ein; jeder Schlüssel ist in der Einstellungsreferenz dokumentiert. Aus einer Admin-Quelle unter dem Gewinner gelten die beiden Sandbox-Sperren immer noch, und allowManagedPermissionRulesOnly blockiert weiterhin übergeordnete Zulassungsregeln und additionalDirectories. Auf Claude Code v2.1.273 oder später gilt auch die MCP-Server-Sperre aus einer Quelle unter dem Gewinner, und während sie aktiv ist, kommt die verwaltete allowedMcpServers-Liste aus der höchsten Prioritäts-Admin-Quelle, die eine setzt.

Die Hooks-Sperre und die Auswirkung von allowManagedPermissionRulesOnly auf die eigenen Regeln des Entwicklers benötigen standardmäßig die Gewinnerquelle; unter der Merge-Opt-in managedSourcesBehavior in wie Claude Code verwaltete Quellen kombiniert, wendet Claude Code den strengsten Wert an, den jede Quelle für jede Sperre setzt. Auf policyHelper-Flotten werden die Sperren nur aus der Ausgabe des Helpers gelesen.

Jede Sperre lässt Claude Code die eigenen Einträge des Entwicklers für diese Einstellung ignorieren, daher schließen Sie die Zulassungslisten Ihrer Organisation neben den Sperren ein:

• Netzwerkdomänen: Das Sperren mit einer leeren verwalteten Domänenliste blockiert den gesamten ausgehenden Sandbox-Verkehr.
• MCP-Server: Das Sperren ohne allowedMcpServers in einer Admin-Quelle oder in den übergeordneten Einstellungen lädt jeden Server, den deniedMcpServers nicht blockiert.
• Lesepfade: allowRead-Einträge erlauben nur Pfade in denyRead-Regionen erneut, daher koppeln Sie sie mit einem verwalteten denyRead.

Einstellungen, die die Sperren nicht abdecken

Vier übergeordnete Einstellungen passieren den Filter auch mit allen fünf Sperren gesetzt. Unter der Standard-First-Wins-Einstellung ist der Admin-Wert, der den übergeordneten blockiert, der in der höchsten Prioritäts-Admin-Quelle, außer für allowedMcpServers während die MCP-Server-Sperre aktiv ist. Unter der Merge-Opt-in managedSourcesBehavior sagt wie Claude Code verwaltete Quellen kombiniert, welcher Quellenwert stattdessen gilt.

• forceLoginOrgUUID: Claude Code ehrt einen übergeordneten Wert, wenn die höchste Prioritäts-Admin-Quelle keine Organisations-UUID setzt. Gateway-Anmeldung überprüft diesen Schlüssel nicht, daher ist er nur für Flotten wichtig, die auch First-Party-Anthropic-Anmeldungen verwenden. Eine Organisations-UUID in der höchsten Prioritäts-Admin-Quelle blockiert den übergeordneten Wert und ist der, den Claude Code erzwingt, daher setzen Sie forceLoginOrgUUID dort.
• allowedMcpServers: Claude Code ehrt eine übergeordnete Zulassungsliste, wenn keine Admin-Liste in Kraft ist. allowManagedMcpServersOnly blockiert sie nicht, da die Sperre erzwingt, welche Liste auch immer gewinnt, als verwalteter Wert, einschließlich einer übergeordneten Liste, wenn keine Admin-Quelle eine Liste liefert. Eine Liste in der höchsten Prioritäts-Admin-Quelle blockiert die übergeordnete und ist die Liste, die Claude Code erzwingt, daher setzen Sie allowedMcpServers dort, neben der Sperre. Vor v2.1.223 blockierte ein Wert für einen der beiden Schlüssel in jeder Admin-Quelle den übergeordneten.
• availableModels: Claude Code ehrt eine übergeordnete Modelliste, wenn die Gewinnerquelle für verwaltete Einstellungen keine setzt. Wenn Ihre Flotte Modelle einschränkt, setzen Sie availableModels in der Gewinnerquelle.
• strictPluginOnlyCustomization: dieser Schlüssel passiert den Filter unabhängig von jeder Sperre, und er lässt Claude Code die eigene Anpassung des Entwicklers ignorieren, einschließlich schützender Hooks. Keine Sperre blockiert ihn.

Claude Desktop verbinden

Claude Desktop verbindet sich mit demselben Gateway über einen anderen MDM-Schlüssel: setzen Sie bootstrapUrl in Claude Desktops verwalteter Konfiguration auf <listen.public_url>/user/bootstrap, und opt-in die Richtlinie des Benutzers mit einem desktop-Schlüssel. Claude Desktop-Überlagerung behandelt beide Hälften. Erfordert Claude Code v2.1.203 oder später auf dem Gateway-Server.

Claude Desktop meldet den Entwickler über den Identity Provider des Gateways mit demselben Browser-SSO-Schritt an, ruft dann seine Konfiguration vom Gateway statt von Anthropic ab. Modellzugriff und Richtlinie folgen denselben Pro-Gruppen-Regeln wie die CLI. Ein Entwickler, der sowohl die CLI als auch Claude Desktop verwendet, meldet sich bei jedem separat an; die Gateway-Sitzung wird nicht zwischen ihnen geteilt.

Nach der Verbindung sendet Claude Desktop Modellanfragen von jeder aktivierten Registerkarte durch das Gateway. Es zeigt die Cowork- und Code-Registerkarten standardmäßig an. Um die Chat-Registerkarte auch zu aktivieren, setzen Sie chatTabEnabled auf true in Claude Desktops verwalteter Konfiguration, oder im desktop-Block der Richtlinie auf einem Gateway, das Claude Code v2.1.227 oder später ausführt.

CI-Pipelines und Remote-Maschinen

Es gibt keinen Service-Token-Fluss für unbeaufsichtigte Pipelines. Gateway-Anmeldung führt immer den Browser-Gerätefluss aus, daher kann ein CI-Job ohne Entwickler zur Genehmigung der Anmeldung nicht authentifizieren; konfigurieren Sie diese direkt gegen Ihren Anbieter.

Sobald sich ein Entwickler angemeldet hat, verwendet jede Claude Code-Sitzung auf dieser Maschine die Gateway-Sitzung, einschließlich nicht-interaktiver claude -p-Läufe und Sitzungen, die vom Agent SDK gestartet werden. Claude Code wendet die Gateway-Richtlinie auf jede von ihnen an.

Der Gerätefluss trennt die Polling-CLI vom genehmigenden Browser, daher funktioniert eine Remote-Entwicklungsbox ohne Display immer noch: Der Entwickler führt /login über SSH auf der Remote-Maschine aus und öffnet den Überprüfungslink im Browser auf seinem Laptop.

Was auf Entwickler erzwungen wird

Diese Garantien gelten für jede Sitzung, die sich über /login angemeldet hat. Die eingebetteten Sitzungen, die Claude Desktop startet, erhalten ihre Richtlinie wie in Richtlinie an Claude Desktop-Sitzungen liefern beschrieben, und die Telemetrie-Aufzählung sagt, wohin ihre Exporte gehen.

• Modellzugriff: Anfragen für Modelle, die die Richtlinie nicht gewährt, geben 400 zurück, und die /model-Auswahl wird auf die availableModels-Zulassungsliste der Richtlinie gefiltert. Setzen Sie enforceAvailableModels: true in der Richtlinie, damit die Standard-Option zu einem Modell in availableModels aufgelöst wird, anstatt zu Claude Codes integriertem Standard; ohne sie bleibt Standard wählbar und wird bei der Anfrageverarbeitung abgelehnt, wenn dieses Modell nicht gewährt wird.
• Telemetrie-Ziel: In Sitzungen, die sich über /login angemeldet haben, sendet die CLI ihre OTLP/HTTP-Exporte an das Gateway statt an einen lokal gesetzten OTEL_EXPORTER_OTLP_ENDPOINT, es sei denn, eine Richtlinie benennt Ihren Collector als Endpunkt. Das Gateway leitet die Exporte, die es empfängt, an die Ziele in telemetry.forward_to weiter.
  • In den eingebetteten Sitzungen, die Claude Desktop startet, sendet die CLI ihre Exporte an den konfigurierten OTEL_EXPORTER_OTLP_ENDPOINT. Die CLI hängt das Gateway-Sitzungstoken an diese Exporte nur an, wenn dieser Endpunkt auf das Gateway selbst zeigt.
  • Ohne konfiguriertes Ziel für ein Signal akzeptiert das Gateway es und verwirft es.
  • Wenn Sie bereits Claude Code-Telemetrie direkt erfassen, fügen Sie Ihren Collector als forward_to-Ziel hinzu, oder benennen Sie ihn in einer Richtlinie, um das Relay zu überspringen.
• Anmeldedaten: Das Gateway-Token ist die einzige Anmeldedaten der Sitzung. Anthropic-Profile und jede frühere claude.ai-Anmeldung werden ignoriert, während angemeldet, daher müssen sich Entwickler nicht zuerst von claude.ai abmelden. Für einen konfigurierten ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN oder apiKeyHelper-Anmeldedaten siehe Administratorrichtlinie erfordert eine Cloud-Gateway-Anmeldung.
• Verwaltete Einstellungen: Gesperrte Schlüssel können nicht lokal überschrieben werden. Die CLI wendet die Richtlinie beim Start an und wendet Änderungen bei jeder stündlichen Abfrage an, abgesehen von den Änderungen, die nur beim nächsten Start angewendet werden.
• Startup mit dem Gateway unerreichbar: Angemeldete Sitzungen beenden sich beim Start mit einem Fehler nach etwa 10 Sekunden, anstatt ohne ihre Einstellungen zu starten.
• Startup nach dem Gateway beendet die Sitzung: siehe Fail-Closed-Startup erzwingen für die Starts, die abgemeldet vom Gateway öffnen, und die, die beenden, wenn das Gateway mit einem 401 antwortet.
• Entbereitstellung: Eine Sitzung, deren Benutzer im IdP deaktiviert ist, läuft innerhalb von ttl_hours ab, wenn die nächste Aktualisierung fehlschlägt.
• Abmeldung: /logout löscht die Gateway-Anmeldedaten von der Maschine des Entwicklers.
  • Wenn das Discovery-Dokument des Gateways einen revocation_endpoint auf dem eigenen Schema, Host und Port der Gateway-URL bewirbt, sendet /logout auch die gespeicherten Token an diesen Endpunkt, damit das Gateway die Sitzung auf seiner Seite beenden kann. Die Anfrage ist Best Effort, daher wird die Abmeldung auf der Maschine des Entwicklers abgeschlossen, unabhängig davon, ob der Endpunkt antwortet. Die Sperrung erfordert Claude Code v2.1.275 oder später auf der Entwicklermaschine.
  • Der Gateway-Server in der claude-Binärdatei bewirbt keine, daher beendet eine Abmeldung von ihm die Sitzung auf der Maschine des Entwicklers nur. Um Sitzungen serverseitig zu erzwingen, siehe JWT-Geheimnis-Rotation.

Was die Organisation sehen kann

Nutzungstelemetrie trägt die Identität des Entwicklers, Token-Zählungen, Modell und Latenz zum Collector der Organisation. Das Gateway protokolliert oder speichert keinen Prompt- oder Completion-Inhalt. Ob umfangreichere Telemetrie wie Protokolle und Traces erfasst wird, die Befehle und Dateipfade enthalten können, ist die Pro-Ziel-Wahl der Organisation.

Verfügbarkeit und Einschränkungen

Die Tabelle behandelt, welche Claude-Code-Funktionen funktionieren, wenn Entwickler sich über das Gateway verbinden, und was der Gateway-Server selbst unterstützt. Wenn etwas nicht unterstützt wird, gibt die Spalte Notizen die Alternative an.

Das Gateway liefert die anthropic-beta-Werte, die die CLI an jeden Upstream sendet, daher verwalten Operatoren keine Beta-Zulassungsliste. Für Amazon Bedrock, das den Header ignoriert, verschiebt das Gateway die Werte in das anthropic_beta-Feld des Request-Body; die anderen Upstreams erhalten den Header wie gesendet.

Nächste Schritte

Der Schnellstart lässt Sie mit einer minimalen Konfiguration unter Docker Compose. Um es weiter zu bringen:

• Erweitern Sie gateway.yaml über die minimale Konfiguration hinaus, um beispielsweise Pro-Gruppen-RBAC, Multi-Upstream-Failover oder Telemetrie-Ziele hinzuzufügen. Die Konfigurationsreferenz behandelt jede Option.
• Wechseln Sie von Compose zu einer Produktionsbereitstellung auf Kubernetes oder Cloud Run, richten Sie Ihren IdP ordnungsgemäß ein und überprüfen Sie das Sicherheitsmodell. Der Bereitstellungs- und Operationsleitfaden behandelt IdP-spezifische Einrichtung, Container-Image-Anforderungen, Health-Probes und Fehlerbehebung.
• Legen Sie Ausgabengrenzen für einzelne Entwickler oder Gruppen fest, damit eine unkontrollierte Workload Ihre gesamte Verpflichtung nicht verbrauchen kann. Ausgabenlimits behandelt die Admin-API und wie die Durchsetzung funktioniert.
• Für ein vollständiges durchgearbeitetes Beispiel auf AWS mit ECS Fargate oder EKS, Amazon RDS und Secrets Manager siehe Bereitstellung auf AWS.
• Für ein vollständiges durchgearbeitetes Beispiel auf Google Cloud mit Cloud Run, Cloud SQL und Secret Manager siehe Bereitstellung auf Google Cloud.