Passerelle Claude apps pour Amazon Bedrock, Claude Platform sur AWS, Google Cloud et Microsoft Foundry

Exécutez Claude Code via Amazon Bedrock, Claude Platform sur AWS, Google Cloud ou Microsoft Foundry derrière une passerelle auto-hébergée avec authentification SSO, accès aux modèles par groupe et télémétrie OTLP.

Claude apps gateway est un service auto-hébergé qui se situe entre les clients Claude Code de vos développeurs et votre fournisseur de modèles. Les développeurs se connectent avec votre fournisseur d'identité (IdP) d'entreprise au lieu de détenir des clés API ou des identifiants cloud. La passerelle détient les identifiants en amont, applique l'accès aux modèles et les paramètres gérés par groupe IdP, et relaye la télémétrie d'utilisation vers votre propre pile d'observabilité.

Elle est incluse dans le binaire claude, donc le même exécutable qui exécute Claude Code sur un ordinateur portable exécute le serveur de passerelle avec claude gateway --config gateway.yaml.

Cette page couvre :

• Pourquoi Claude apps gateway, ce qu'il ajoute par rapport à l'exécution de votre propre solution, et quand quelque chose d'autre convient mieux
• Un démarrage rapide avec les prérequis qui fait passer une passerelle de zéro à un développeur connecté
• Connecter les développeurs, y compris la définition de l'URL de la passerelle via les paramètres gérés
• Disponibilité et limitations couvrant les fonctionnalités Claude Code qui fonctionnent via la passerelle et ce que le serveur supporte

Les pages complémentaires approfondissent le sujet. La référence de configuration couvre chaque option du fichier YAML que le démarrage rapide écrit, et le guide de déploiement couvre la configuration par IdP, le déploiement Kubernetes et Cloud Run, et les opérations.

Pourquoi Claude apps gateway

L'aperçu de la passerelle couvre ce qu'une passerelle fait et pourquoi vous en exécuteriez une. Claude apps gateway est la propre passerelle d'Anthropic, intégrée au binaire claude et testée aux côtés de chaque version de Claude Code, elle transmet donc les en-têtes et les champs de requête que Claude Code envoie sans que les opérateurs maintiennent une liste d'autorisation distincte. Une fois déployée, elle vous donne :

• Identifiants : la clé API en amont ou l'identifiant cloud ne vit que dans votre infrastructure. Les développeurs s'authentifient avec SSO d'entreprise et reçoivent des jetons porteurs de courte durée, donc le déprovisionnement se fait dans votre IdP. Déprovisionner un utilisateur et son accès à la passerelle expire dans la durée de vie de la session, une heure par défaut.
• Contrôle d'accès : vos groupes IdP correspondent à des listes d'autorisation de modèles et à des politiques de paramètres gérés. La passerelle applique l'accès aux modèles côté serveur, rejetant les demandes pour les modèles non accordés, et sélectionne la politique de paramètres gérés de chaque groupe, que l'interface de ligne de commande applique au niveau des paramètres gérés. Différentes équipes obtiennent différents modèles, outils et permissions, et un développeur ne peut pas remplacer ce que sa politique verrouille.
• Livraison des paramètres : la passerelle livre les paramètres gérés aux clients connectés elle-même, remplaçant les paramètres gérés par le serveur de la console d'administration claude.ai.
• Télémétrie : chaque destination configurée reçoit les métriques OpenTelemetry Protocol (OTLP) avec les nombres de jetons, le modèle, l'identité de l'utilisateur et la latence par défaut, avec les journaux et les traces comme des options par destination.
• Routage en amont : les clients parlent l'API Anthropic Messages à la passerelle, et la passerelle traduit pour chaque amont, qu'il s'agisse de Bedrock, de la plateforme Claude sur AWS, de la plateforme Agent de Google Cloud, de Foundry ou de l'API Anthropic, avec basculement entre eux. Vous pouvez modifier les régions, les fournisseurs ou l'ordre de basculement sans que les développeurs le remarquent ou se reconfigurent.

Pour les fonctionnalités Claude Code qui fonctionnent via la passerelle et ce que le serveur lui-même supporte, voir Disponibilité et limitations ci-dessous. Pour les décisions telles que le coût, le contournement, l'exécution de plusieurs passerelles et les plates-formes sans serveur, voir le guide de déploiement.

Autres implémentations de passerelle

Si vous exécutez déjà une passerelle LLM ou une passerelle API qui répond à vos besoins, continuez à l'utiliser ; Autres passerelles LLM couvre la configuration de Claude Code contre elle.

La guide de compatibilité de la passerelle documente ce que Claude Code attend de toute passerelle : les points de terminaison qu'elle appelle, les en-têtes et les champs de corps à transmettre, et ce qui cesse de fonctionner quand ils sont supprimés. Une passerelle Claude apps en cours d'exécution sert également sa propre référence de protocole à GET /protocol, qui décrit les points de terminaison qu'elle expose aux clients Claude Code : connexion SSO, inférence, livraison des paramètres gérés, découverte de modèles et télémétrie. Récupérez-le avec curl https://claude-gateway.internal.example.com/protocol à partir de n'importe quelle passerelle déployée, comme celle que le démarrage rapide ci-dessous produit.

Les modifications majeures du protocole sont annoncées à l'avance, mais la compatibilité rétroactive indéfinie n'est pas garantie.

Démarrage rapide

Ce démarrage rapide parcourt le chemin minimal : enregistrez un client OAuth dans votre IdP, écrivez un gateway.yaml, exécutez la passerelle aux côtés de Postgres avec Docker Compose, et vérifiez la connexion de bout en bout. Il utilise un amont Amazon Bedrock ; Claude Platform on AWS, Google Cloud's Agent Platform, Microsoft Foundry, et l'API Anthropic sont également supportés en échangeant le bloc upstreams comme indiqué dans la référence de configuration. À la fin, vous avez une passerelle à laquelle un développeur peut se /login.

Prérequis

Ayez ceci en place avant de commencer :

Étapes

listen:
host: 0.0.0.0
port: 8080
# Requis sauf si l'hôte est une adresse de boucle locale. Utilisé pour l'IdP
# redirect_uri et le document de découverte.
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # doit servir /.well-known/openid-configuration
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # rejeter les id_tokens en dehors de votre org
userinfo_fallback: true                  # pour les IdPs dont l'id_token omet email/groups ; inoffensif sinon

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # limite également la latence de révocation lors du déprovisionnement IdP

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # ajouter ?sslmode=require pour Postgres géré

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # vide : chaîne de credentials AWS par défaut
# (IRSA, rôle de tâche EC2/ECS, variables d'env, ~/.aws)

# Les modèles sont traduits par amont automatiquement. Le catalogue intégré
# mappe claude-opus-4-8 à us.anthropic.claude-opus-4-8 et ainsi de suite pour chaque
# modèle Claude supporté par Bedrock. Définissez false et ajoutez une liste `models:` pour
# exposer uniquement des modèles spécifiques.
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
# Identifiants AWS : en production, omettez ceux-ci et utilisez un rôle
# d'instance. Pour les tests Compose locaux, transmettez les vôtres :
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
}

Connecter les développeurs

Les développeurs se connectent à partir de leurs propres ordinateurs portables avec une seule connexion au navigateur, en utilisant leur compte professionnel d'entreprise. Ils n'ont pas besoin d'un compte claude.ai, d'une clé API ou d'un abonnement, car les demandes au modèle passent par la passerelle en utilisant l'identifiant en amont de l'organisation. La connexion est pilotée par les paramètres gérés côté client que vous poussez via MDM, il n'y a donc pas de configuration manuelle du côté du développeur ; cette section couvre ce que l'administrateur configure.

L'interface de ligne de commande empreinte le certificat feuille TLS de la passerelle à la première connexion et l'épingle par nom d'hôte. Elle vérifie cette épingle à nouveau lors de la connexion, lors des rafraîchissements de session silencieux et lors des récupérations de paramètres gérés, tandis que les demandes d'inférence utilisent la validation TLS standard sans l'épingle. Les demandes acheminées via un proxy HTTPS ignorent la vérification de l'épingle, donc ajoutez l'hôte de la passerelle à NO_PROXY pour les garder directes.

Publiez l'empreinte SHA-256 attendue aux côtés de l'URL de la passerelle pour que les développeurs aient quelque chose à comparer. L'invite /login affiche les 16 premiers caractères de l'empreinte en hexadécimal minuscule sans deux-points. Pour imprimer l'empreinte complète sous cette forme à partir du fichier de certificat, exécutez :

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

Quand le certificat tourne, chaque développeur voit à nouveau l'invite de confiance, traitez donc les rotations comme un événement planifié et republier l'empreinte. Si votre politique de passerelle inclut des paramètres qui nécessitent une approbation, le développeur voit également ce dialogue d'approbation à nouveau après avoir accepté le nouveau certificat, car Claude Code associe la mémoire d'approbation au certificat épinglé.

Une passerelle peut retourner le champ optionnel email dans sa réponse de jeton pour nommer le compte qu'une connexion a utilisé. Quand elle le fait, le développeur confirme le compte avant que Claude Code ne sauvegarde l'identifiant. Après une connexion confirmée, /status affiche le compte.

La confirmation nécessite Claude Code v2.1.275 ou ultérieur sur la machine du développeur ; un client en dessous de cette version ignore le champ. Le serveur de passerelle dans le binaire claude ne retourne pas le champ, donc ses connexions se complètent sans la confirmation.

Une fois le développeur connecté, le sélecteur de modèle affiche les modèles dans la liste d'autorisation availableModels du développeur. Les paramètres gérés s'appliquent au démarrage et se rafraîchissent toutes les heures, et la télémétrie s'achemine vers votre collecteur.

Les sessions se rafraîchissent silencieusement avant l'expiration de ttl_hours. Quand un rafraîchissement échoue après le déprovisionnement IdP, Claude Code invite le développeur à se reconnecter.

Définir l'URL de la passerelle

Trois clés vont dans le fichier de paramètres gérés par système d'exploitation que vous déployez via MDM ou directement sur le disque. forceLoginMethod et forceLoginGatewayUrl ouvrent /login directement sur l'écran Cloud gateway avec l'URL remplie, et parentSettingsBehavior: "merge" permet à Claude Desktop de livrer la liste d'autorisation de sortie de la passerelle aux sessions Claude Code qu'il lance, expliqué dans Livrer la politique à Claude Desktop sessions :

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

Le développeur appuie sur Entrée pour se connecter. L'invite d'empreinte TLS de première connexion apparaît toujours. Une fois le fichier sur une machine, un développeur qui n'a pas complété la connexion à la passerelle voit l'un des messages décrits sous La politique d'administrateur nécessite une connexion Cloud gateway. Les développeurs qui sélectionnent un fournisseur cloud via une variable d'environnement telle que CLAUDE_CODE_USE_BEDROCK n'ont pas besoin de la connexion à la passerelle.

Un développeur ne peut pas configurer cela manuellement. Le sélecteur de connexion n'a pas d'option de passerelle, et forceLoginGatewayUrl est ignoré dans les fichiers de paramètres propres d'un développeur. forceLoginMethod seul, sans URL, laisse le développeur à un message « Contactez votre administrateur informatique ». Les clés de connexion appartiennent au fichier que vous poussez vers les machines, pas au bloc managed.policies[].cli de la passerelle, qui ne atteint que les clients déjà connectés.

Autoriser une passerelle sur l'espace d'adresses publiques que vous possédez

Certaines organisations numérotent leur réseau interne à partir d'un bloc IPv4 public qu'elles possèdent, comme l'espace d'adresses propre d'un opérateur ou un /8 hérité, donc leur passerelle ne peut pas avoir d'adresse privée. Listez ces blocs dans le paramètre géré gatewayInternalNetworks. /login accepte alors une passerelle à l'intérieur d'un bloc listé quand la machine du développeur s'y connecte à partir d'une adresse à l'intérieur du même bloc. Cela nécessite Claude Code v2.1.268 ou ultérieur sur la machine du développeur ; les versions antérieures ignorent la clé et appliquent la règle d'adresse privée.

Ajoutez la clé à la même source de paramètres gérés que les clés de connexion : le fichier de paramètres gérés, le profil MDM, ou la politique de registre. Claude Code l'ignore dans les paramètres utilisateur, projet et gérés par serveur.

Cet exemple déclare un bloc. Remplacez 203.0.113.0/24 par votre propre bloc. C'est une plage de documentation, et Claude Code refuse celles-ci.

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

Claude Code valide la liste à /login avant de contacter une passerelle :

• Chaque entrée est un bloc IPv4 écrit comme sa première adresse et un préfixe de /8 à /32.
• La liste contient au maximum quatre blocs, et aucun deux ne se chevauchent.
• Aucun bloc ne chevauche l'espace d'adresses privées : 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, et 100.64.0.0/10. /login accepte déjà une passerelle là sans cette clé.
• Aucun bloc ne chevauche l'espace qui n'est jamais le réseau d'une organisation : 198.18.0.0/15 et 192.0.0.0/24, que les clients VPN et NAT64 détiennent comme adresses locales ; les plages de documentation 192.0.2.0/24, 198.51.100.0/24, et 203.0.113.0/24 ; et les plages réservées 0.0.0.0/8, 192.88.99.0/24, et multicast 224.0.0.0/4. Vous pouvez déclarer des blocs à l'intérieur de 240.0.0.0/4, que certains grands réseaux utilisent comme espace unicast interne.

Les blocs de managed-settings.json et ses fichiers drop-in managed-settings.d/ se combinent en une liste, et ces limites s'appliquent à la liste combinée. Pour réduire un bloc, remplacez son entrée plutôt que d'en ajouter une deuxième qui se chevauche dans un drop-in ; /login refuse le chevauchement.

Si une entrée casse une règle, ou la valeur n'est pas une liste de chaînes, Claude Code refuse chaque nouvelle connexion à la passerelle sur cette machine et nomme le problème dans le message. La connexion à une passerelle sur une adresse privée échoue aussi, et les connexions existantes continuent de fonctionner. Essayez la valeur sur une machine avant de la déployer. Claude Code liste également une valeur mal typée parmi les paramètres gérés invalides qu'il rapporte.

Avec une liste valide, /login applique trois vérifications à une passerelle dont l'adresse est à l'intérieur d'un bloc listé :

• Chaque adresse à laquelle le nom d'hôte de la passerelle se résout est à l'intérieur de ce bloc. Claude Code refuse un nom qui a aussi des enregistrements en dehors, y compris les adresses privées et IPv6.
• La machine du développeur se connecte de l'intérieur du même bloc. Claude Code refuse une machine derrière NAT, à l'intérieur d'un conteneur ou WSL2, ou sur un VPN dont le pool d'adresses se situe en dehors du bloc, et nomme l'adresse à partir de laquelle la machine s'est connectée.
• La connexion est directe. Si HTTPS_PROXY s'applique à l'hôte de la passerelle, /login refuse et nomme l'entrée NO_PROXY à ajouter.

Quand les trois passent, l'invite de confiance ajoute une ligne nommant l'adresse de la machine, l'adresse de la passerelle, et le bloc déclaré qui contient les deux.

La clé ne change rien pour les autres passerelles : la connexion à une sur une adresse privée fonctionne comme avant, et la connexion à une sur une adresse publique en dehors de chaque bloc listé est refusée comme avant.

Un bloc déclaré restreint qui peut se connecter mais ne prouve pas où se trouve une machine, donc déclarez uniquement l'espace d'adresses que votre organisation contrôle. Un bloc partagé avec d'autres locataires, comme une plage publique d'un fournisseur cloud, laisse n'importe qui dedans passer la même vérification.

Livrer la politique à Claude Desktop sessions

Claude Desktop exécute ses onglets Cowork et Code, plus l'onglet Chat quand vous l'activez, sur des sessions Claude Code intégrées et envoie leurs demandes de modèle à travers la passerelle. Il transmet la politique à chacune de ces sessions, construite à partir de la configuration que la passerelle lui sert à /user/bootstrap : la liste d'autorisation des modèles, les outils désactivés, et la liste d'autorisation de sortie dérivée du bloc cli de la politique correspondante, plus la superposition desktop.

D'autres clés cli, telles que hooks, env, et les règles de permission délimitées comme Bash(npm *), ne sont accessibles qu'aux clients qui se connectent via /login. Claude Desktop lit l'URL de la passerelle à partir de sa propre configuration gérée et se connecte avec son propre flux, séparé des clés forceLoginMethod et forceLoginGatewayUrl dans Définir l'URL de la passerelle.

Les paramètres transmis par un processus de lancement sont des paramètres parents. Claude Code ignore les paramètres parents sur toute machine qui a une source gérée déployée par un administrateur, sauf si la source qui livre la politique définit parentSettingsBehavior: "merge".

Quelles machines ont besoin de l'opt-in

Les machines qui exécutent uniquement Claude Desktop en ont besoin. Claude Desktop applique la liste des modèles et la liste des outils désactivés aux sessions intégrées elle-même, mais la liste d'autorisation de sortie ne les atteint que comme paramètres parents, sous la forme de règles de domaine WebFetch et de règles de réseau sandbox. Sans l'opt-in, ces sessions s'exécutent sans la restriction de sortie, et rien ne vous avertit. La passerelle rejette toujours les demandes d'inférence pour les modèles que la politique n'accorde pas.

Les machines où les développeurs se connectent via /login n'en ont pas besoin ; chaque session Claude Code récupère sa politique auprès de la passerelle.

Les flottes dont policyHelper fournit des paramètres gérés ne peuvent pas l'utiliser : Claude Code ne fusionne jamais les paramètres parents sur ces flottes, car il lit les paramètres gérés à partir de la sortie du helper seule.

Définir l'opt-in

Déployez l'extrait de paramètres gérés à partir de Définir l'URL de la passerelle, miroir-le vers toute source côté client qui surclasse le fichier, puis vérifiez.

Restreindre les paramètres parents

Une fois que vous déployez parentSettingsBehavior: "merge", tout processus hôte qui lance Claude Code peut fournir des paramètres parents, non seulement Claude Desktop mais aussi une application SDK Agent ou une extension IDE.

Claude Code filtre les paramètres parents par rapport à une liste d'autorisation de clés restrictives, mais certaines clés autorisées peuvent accorder l'accès plutôt que de le restreindre. À moins que vous définissiez les verrous allowManaged*Only, les règles d'autorisation de permission et les listes d'autorisation sandbox fournies par l'hôte s'appliquent toujours. Les règles de refus et de demande de votre politique restent en vigueur de toute façon ; elles sont évaluées avant toute règle d'autorisation.

Claude Code transmet les entrées sandbox.credentials fournies par le parent sous forme dépouillée :

• Entrées deny : transmises avec uniquement leur path ou name et le mode.
• Entrées de fichier avec mode: mask : transmises uniquement sentinelle, comme un masque de fichier entier dont injectHosts est la liste vide, donc le proxy ne substitue jamais la valeur réelle pour une entrée fournie par le parent sur aucune plateforme. Tous les champs de masquage structuré sont également supprimés, donc un modèle d'extraction fourni par le parent ne peut pas déplacer un masque plus strict qu'une autre source définit pour le même chemin.
• Entrées envVars avec mode: mask : non transmises. deny est la seule restriction que le canal parent peut exprimer via les entrées envVars.
• awsPairs et sigv4 : transmises restriction-uniquement. À partir de sigv4, seules les valeurs deny sont conservées, et un parent qui définit un bloc sigv4 du tout épingle les trois formes de demande, streaming, presigned, et sigv4a, à deny. Une paire awsPairs n'est jamais transmise sous une forme qui peut re-signer ; une paire qui nomme l'une des variables AWS conventionnelles est remplacée par une entrée inerte qui maintient l'appairage automatique de AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, et AWS_SESSION_TOKEN supprimé.

Déployer les verrous

Pour garder les paramètres parents aussi proches de restriction-uniquement que le filtre le supporte, ajoutez les cinq verrous allowManaged*Only, et les listes d'autorisation qu'ils gouvernent, aux mêmes sources que l'opt-in de fusion :

{
  "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"]
    }
  }
}

Une politique du système d'exploitation, telle qu'une politique de registre HKLM ou une plist de préférences gérées, surclasse ce fichier, donc livrez l'extrait entier via celui-ci au lieu du fichier. Les paramètres gérés distants de la passerelle surclassent la politique du système d'exploitation et les sources de fichiers mais ne sont accessibles qu'aux clients connectés. Miroir les verrous, les listes d'autorisation, et l'opt-in de fusion dans le bloc cli de la politique et gardez ce fichier déployé, car les machines qui ne se connectent jamais, y compris celles qui exécutent uniquement Claude Desktop, obtiennent leur politique du fichier seul.

Comportement des verrous entre les sources

Définir un verrou ne restreint pas les autres ; chaque clé est documentée dans la référence des paramètres.

À partir d'une source d'administrateur en dessous du gagnant, les deux verrous sandbox s'appliquent toujours, et allowManagedPermissionRulesOnly bloque toujours les règles d'autorisation fournies par le parent et additionalDirectories. Sur Claude Code v2.1.273 ou ultérieur, le verrou serveur MCP s'applique également à partir d'une source en dessous du gagnant, et tandis qu'il est activé, la liste gérée allowedMcpServers provient de la source d'administrateur de plus haute priorité qui en définit une.

Les verrous hooks et allowManagedPermissionRulesOnly's effet sur les règles propres du développeur ont besoin de la source gagnante par défaut ; sous l'opt-in de fusion managedSourcesBehavior dans comment Claude Code combine les sources gérées, Claude Code applique la valeur la plus stricte que toute source définit pour chaque verrou. Sur les flottes policyHelper, Claude Code lit les verrous à partir de la sortie du helper seule.

Chaque verrou fait que Claude Code ignore les entrées propres du développeur pour ce paramètre, donc incluez les listes d'autorisation de votre organisation à côté des verrous :

• Domaines réseau : verrouiller avec une liste de domaines gérés vide bloque tout le trafic sortant en sandbox.
• Serveurs MCP : verrouiller sans allowedMcpServers gérés ou fournis par le parent charge chaque serveur que deniedMcpServers ne bloque pas.
• Chemins de lecture : les entrées allowRead ne réautorisent que les chemins à l'intérieur des régions denyRead, donc associez-les à un denyRead gérés.

Paramètres que les verrous ne couvrent pas

Six paramètres fournis par le parent passent le filtre même avec les cinq verrous définis. Sous le paramètre par défaut premier-gagnant, la valeur d'administrateur qui bloque celle du parent est celle dans la source d'administrateur de plus haute priorité, sauf pour allowedMcpServers tandis que le verrou serveur MCP est activé. Sous l'opt-in de fusion managedSourcesBehavior, comment Claude Code combine les sources gérées dit quelle valeur de source s'applique à la place.

• forceLoginOrgUUID : Claude Code honore une valeur fournie par le parent quand la source d'administrateur de plus haute priorité ne définit pas un UUID d'organisation. La connexion à la passerelle ne vérifie pas cette clé, donc elle ne compte que pour les flottes qui utilisent également les connexions Anthropic de première partie. Un UUID d'organisation dans la source d'administrateur de plus haute priorité bloque la valeur du parent et est celui que Claude Code applique, donc définissez forceLoginOrgUUID là.
• allowedMcpServers : Claude Code honore une liste d'autorisation fournie par le parent quand aucune liste d'administrateur n'est en vigueur. allowManagedMcpServersOnly ne la bloque pas, car le verrou applique quelle que soit la liste qui gagne comme valeur gérée, y compris une liste fournie par le parent quand aucune source d'administrateur n'en fournit une. Une liste dans la source d'administrateur de plus haute priorité bloque celle du parent et est la liste que Claude Code applique, donc définissez allowedMcpServers là, à côté du verrou. Avant v2.1.223, une valeur pour l'une ou l'autre clé dans toute source d'administrateur bloquait celle du parent.
• availableModels : Claude Code honore une liste de modèles fournie par le parent quand la source gérée gagnante n'en définit pas. Si votre flotte restreint les modèles, définissez availableModels dans la source gagnante.
• strictKnownMarketplaces : Claude Code honore une liste d'autorisation de marché de plugins fournie par le parent quand la source gérée gagnante n'en définit pas. Si votre flotte restreint les marchés, définissez strictKnownMarketplaces dans la source gagnante. Nécessite Claude Code v2.1.282 ou ultérieur.
• blockedMarketplaces : une liste de blocage de marché fournie par le parent passe et s'ajoute à toute liste de blocage qu'une source gérée définit, puisqu'une liste de blocage ne peut que restreindre davantage. Nécessite Claude Code v2.1.282 ou ultérieur.
• strictPluginOnlyCustomization : cette clé passe le filtre indépendamment de tout verrou, et elle fait que Claude Code ignore la personnalisation propre du développeur, y compris les hooks protecteurs. Aucun verrou ne la bloque.

Connecter Claude Desktop

Claude Desktop se connecte à la même passerelle via une clé MDM différente : définissez bootstrapUrl dans la configuration gérée de Claude Desktop à <listen.public_url>/user/bootstrap, et optez la politique de l'utilisateur avec une clé desktop. La superposition Claude Desktop couvre les deux moitiés. Nécessite Claude Code v2.1.203 ou ultérieur sur le serveur de passerelle.

Claude Desktop connecte le développeur via le fournisseur d'identité de la passerelle avec la même étape SSO du navigateur, puis récupère sa configuration auprès de la passerelle au lieu d'Anthropic. L'accès au modèle et la politique suivent les mêmes règles par groupe que l'interface de ligne de commande. Un développeur qui utilise à la fois l'interface de ligne de commande et Claude Desktop se connecte à chacun séparément ; la session de passerelle n'est pas partagée entre eux.

Une fois connecté, Claude Desktop envoie les demandes de modèle de chaque onglet activé via la passerelle. Il affiche les onglets Cowork et Code par défaut. Pour activer également l'onglet Chat, définissez chatTabEnabled à true dans la configuration gérée de Claude Desktop, ou dans le bloc desktop de la politique sur une passerelle exécutant Claude Code v2.1.227 ou ultérieur.

Pipelines CI et machines distantes

Il n'y a pas de flux de jeton de service pour les pipelines sans surveillance. La connexion à la passerelle exécute toujours le flux d'appareil du navigateur, donc un travail CI sans développeur pour approuver la connexion ne peut pas s'authentifier ; configurez ceux-ci directement contre votre fournisseur.

Une fois qu'un développeur s'est connecté, chaque session Claude Code sur cette machine utilise la session de passerelle, y compris les exécutions non-interactives claude -p et les sessions démarrées par le SDK Agent. Claude Code applique la politique de passerelle à chacune d'elles.

Le flux d'appareil sépare l'interface de ligne de commande d'interrogation du navigateur approbateur, donc une boîte de développement distante sans affichage fonctionne toujours : le développeur exécute /login via SSH sur la machine distante et ouvre le lien de vérification dans le navigateur sur son ordinateur portable.

Ce qui est appliqué aux développeurs

Ces garanties s'appliquent à chaque session connectée via /login. Les sessions intégrées que Claude Desktop lance obtiennent leur politique comme décrit dans Livrer la politique à Claude Desktop sessions, et la puce de télémétrie dit où vont leurs exports.

• Accès au modèle : les demandes pour les modèles que la politique n'accorde pas retournent 400, et le sélecteur /model est filtré à la liste d'autorisation availableModels de la politique. Définissez enforceAvailableModels: true dans la politique pour que l'option Par défaut se résolve à un modèle à l'intérieur de availableModels au lieu du défaut intégré de Claude Code ; sans cela, Par défaut reste sélectionnable et est rejeté au moment de la demande si ce modèle n'est pas accordé.
• Destination de télémétrie : dans les sessions connectées via /login, l'interface de ligne de commande envoie ses exports OTLP/HTTP à la passerelle plutôt qu'à un OTEL_EXPORTER_OTLP_ENDPOINT défini localement, sauf si une politique nomme votre collecteur comme point de terminaison. La passerelle relaie les exports qu'elle reçoit vers les destinations dans telemetry.forward_to.
  • Dans les sessions intégrées que Claude Desktop lance, l'interface de ligne de commande envoie ses exports au OTEL_EXPORTER_OTLP_ENDPOINT configuré. L'interface de ligne de commande attache le jeton de session de passerelle à ces exports uniquement quand ce point de terminaison pointe vers la passerelle elle-même.
  • Sans destination configurée pour un signal, la passerelle l'accepte et le rejette.
  • Si vous collectez déjà la télémétrie Claude Code directement, ajoutez votre collecteur comme destination forward_to, ou nommez-le dans une politique pour ignorer le relais.
• Identifiants : le jeton de passerelle est le seul identifiant de la session. Les profils Anthropic et toute connexion claude.ai antérieure sont ignorés lors de la connexion, donc les développeurs n'ont pas besoin de se déconnecter de claude.ai d'abord. Pour un identifiant ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, ou apiKeyHelper configuré, voir La politique d'administrateur nécessite une connexion Cloud gateway.
• Paramètres gérés : les clés verrouillées ne peuvent pas être remplacées localement. L'interface de ligne de commande applique la politique au démarrage et applique les modifications à chaque sondage horaire, à part les modifications qui s'appliquent uniquement au prochain lancement.
• Démarrage avec la passerelle inaccessible : les sessions connectées se terminent au démarrage avec une erreur après environ 10 secondes plutôt que de démarrer sans leurs paramètres.
• Démarrage après que la passerelle termine la session : voir Appliquer un démarrage fail-closed pour les lancements qui s'ouvrent déconnectés de la passerelle et ceux qui se terminent quand la passerelle répond avec un 401.
• Déprovisionnement : une session dont l'utilisateur est désactivé dans l'IdP expire dans ttl_hours quand le prochain rafraîchissement échoue.
• Déconnexion : /logout supprime l'identifiant de passerelle de la machine du développeur.
  • Quand le document de découverte de la passerelle annonce un revocation_endpoint sur le schéma, l'hôte et le port propres de l'URL de la passerelle, /logout envoie également les jetons stockés à ce point de terminaison pour que la passerelle puisse terminer la session de son côté. La demande est au mieux effort, donc la déconnexion se complète sur la machine du développeur que le point de terminaison réponde ou non. La révocation nécessite Claude Code v2.1.275 ou ultérieur sur la machine du développeur.
  • Le serveur de passerelle dans le binaire claude n'en annonce aucun, donc une déconnexion de celui-ci termine la session sur la machine du développeur uniquement. Pour forcer les sessions à sortir côté serveur, voir Rotation de secret JWT.

Ce que l'organisation peut voir

La télémétrie d'utilisation porte l'identité du développeur, les nombres de jetons, le modèle et la latence vers le collecteur de l'organisation. La passerelle ne journalise ni ne stocke le contenu des invites ou des complétions. Que la télémétrie plus riche comme les journaux et les traces soit collectée, qui peut inclure les commandes et les chemins de fichiers, est le choix par destination de l'organisation.

Disponibilité et limitations

Le tableau couvre les fonctionnalités Claude Code qui fonctionnent quand les développeurs se connectent via la passerelle, et ce que le serveur de passerelle lui-même supporte. Quand quelque chose n'est pas supporté, la colonne Notes donne l'alternative.

La passerelle livre les valeurs anthropic-beta que l'interface de ligne de commande envoie à chaque amont, donc les opérateurs ne maintiennent pas une liste d'autorisation bêta. Pour Amazon Bedrock, qui ignore l'en-tête, la passerelle déplace les valeurs dans le champ anthropic_beta du corps de la demande ; les autres ammonts reçoivent l'en-tête tel qu'envoyé.

Prochaines étapes

Le démarrage rapide vous laisse avec une configuration minimale s'exécutant sous Docker Compose. Pour aller plus loin :

• Développez gateway.yaml au-delà de la configuration minimale, par exemple pour ajouter RBAC par groupe, basculement multi-amont, ou destinations de télémétrie. La référence de configuration couvre chaque option.
• Passez de Compose à un déploiement de production sur Kubernetes ou Cloud Run, configurez correctement votre IdP, et examinez le modèle de sécurité. Le guide de déploiement et d'opérations couvre la configuration par IdP, les exigences d'image de conteneur, les sondes de santé et le dépannage.
• Mettez des plafonds de dépenses sur les développeurs individuels ou les groupes pour qu'une charge de travail incontrôlée ne puisse pas consommer tout votre engagement. Limites de dépenses couvre l'API d'administration et le fonctionnement de l'application.
• Pour un exemple complet travaillé sur AWS, avec ECS Fargate ou EKS, Amazon RDS et Secrets Manager, voir Déployer sur AWS.
• Pour un exemple complet travaillé sur Google Cloud, avec Cloud Run, Cloud SQL et Secret Manager, voir Déployer sur Google Cloud.