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.

[!NOTE]

La passerelle Claude apps est conçue pour les organisations qui doivent — ou préfèrent — acheminer l'inférence via leur propre fournisseur cloud, par exemple pour respecter les exigences de résidence des données. Si vous n'avez pas cette exigence et souhaitez accéder à d'autres fonctionnalités telles que l'approvisionnement SCIM ou Claude Code sur web et mobile, Claude Enterprise peut être un meilleur choix. Consultez la page de disponibilité des fonctionnalités pour une comparaison complète de toutes les méthodes de déploiement.

Claude Code utilise une seule connexion à la fois : une connexion via la passerelle remplace une connexion Claude for Teams ou Enterprise. Les sessions de la passerelle ne récupèrent pas les paramètres gérés par le serveur que vous définissez dans la console d'administration claude.ai ; fournissez-les donc depuis le bloc managed de la passerelle. N'incluez pas forceLoginMethod ni forceLoginOrgUUID dans ce bloc, sinon certaines sessions connectées se ferment au démarrage. Consultez Disponibilité et limitations pour savoir ce que perdent les sessions de la passerelle.

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

La présentation des passerelles explique le rôle d'une passerelle et les raisons d'en exécuter une. Claude apps gateway est la passerelle propre à Anthropic, intégrée au binaire claude et testée avec chaque version de Claude Code. Elle transmet donc les valeurs anthropic-beta et les champs de requête envoyés par Claude Code sans que les opérateurs aient à maintenir une liste d'autorisation distincte. Une fois déployée, elle vous offre :

• Identifiants : la clé API en amont ou l'identifiant cloud reste exclusivement dans votre infrastructure. Les développeurs s'authentifient via le SSO de l'entreprise et reçoivent des jetons bearer de courte durée, de sorte que le départ d'un collaborateur se gère dans votre IdP. Lorsque vous désactivez un utilisateur, son accès à la passerelle expire dans les limites de la durée de vie de la session, soit une heure par défaut.
• Contrôle d'accès : vos groupes IdP sont associés à des listes d'autorisation de modèles, à des politiques de paramètres gérés et à des fournisseurs en amont. La passerelle applique l'accès aux modèles côté serveur, rejette les requêtes visant des modèles non autorisés et sélectionne la politique de paramètres gérés de chaque groupe, que la CLI applique au niveau des paramètres gérés. Chaque équipe dispose de modèles, d'outils et de permissions différents, et un développeur ne peut pas remplacer ce que sa politique verrouille.
• Distribution des paramètres : la passerelle distribue elle-même les paramètres gérés aux clients connectés, en lieu et place des paramètres gérés par le serveur issus de la console d'administration de claude.ai.
• Télémétrie : chaque destination configurée reçoit par défaut des métriques OpenTelemetry Protocol (OTLP) comprenant le nombre de tokens, le modèle, l'identité de l'utilisateur et la latence, les logs et les traces étant activables pour chaque destination.
• Routage en amont : les clients communiquent avec la passerelle via l'API Messages d'Anthropic, et la passerelle effectue la traduction pour chaque fournisseur en amont, qu'il s'agisse d'Amazon Bedrock, de Claude Platform on AWS, de l'Agent Platform de Google Cloud, de Microsoft Foundry ou de l'API Anthropic, avec basculement entre eux. Vous pouvez changer de région, de fournisseur ou d'ordre de basculement sans que les développeurs ne le remarquent ni n'aient à reconfigurer quoi que ce soit.

[!NOTE]

Le plan de données propre à la passerelle n'envoie rien à l'infrastructure d'Anthropic, sauf si l'API Anthropic est configurée comme fournisseur en amont. Vous contrôlez la destination de la télémétrie, des logs d'audit, des paramètres gérés et de l'identité IdP de vos développeurs, et la passerelle n'envoie aucune de ces données à Anthropic. Pour connaître le trafic restant que le processus CLI peut envoyer et la manière de le bloquer, consultez Posture de conformité.

Pour savoir quelles fonctionnalités de Claude Code fonctionnent via la passerelle et ce que le serveur lui-même prend en charge, consultez Disponibilité et limitations ci-dessous. Pour les décisions relatives au coût, au contournement, à l'exécution de plusieurs passerelles et aux plateformes serverless, consultez 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 ; la page Autres passerelles LLM explique comment configurer Claude Code pour l'utiliser.

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

Les changements incompatibles apportés au protocole sont annoncés à l'avance, mais la rétrocompatibilité indéfinie n'est pas garantie.

[!NOTE]

Un jeton de connexion à la passerelle identifie le développeur qui a approuvé la connexion, et non le programme qui l'utilise. Claude Code se connecte sans identifiant client ni secret qui lui soient propres, de sorte qu'une passerelle n'a aucun moyen de vérifier quel programme se connecte. N'importe quel client peut définir User-Agent et d'autres champs de requête ; utilisez-les donc pour le routage ou les métriques, et non comme preuve qu'une requête provient de Claude Code.

Démarrage rapide

Ce démarrage rapide suit le chemin minimal : enregistrer un client OAuth dans votre IdP, écrire un fichier gateway.yaml, exécuter la passerelle aux côtés de Postgres avec Docker Compose, puis vérifier la connexion de bout en bout. Il utilise un upstream Amazon Bedrock ; Claude Platform on AWS, Agent Platform de Google Cloud, Microsoft Foundry et l'API Anthropic sont également pris en charge en remplaçant le bloc upstreams comme indiqué dans la référence de configuration. À la fin, vous disposez d'une passerelle à laquelle un développeur peut se connecter avec /login.

[!NOTE]

Déployez sur votre réseau privé. Claude Code se connecte uniquement à une passerelle dont l'adresse est privée. Il s'agit d'une mesure de sécurité, car une passerelle de confiance peut envoyer des paramètres qui exécutent des commandes sur les machines des développeurs. Placez la passerelle derrière un load balancer interne ou un VPN et attribuez-lui un nom d'hôte qui se résout uniquement en adresses IP privées. Si votre réseau interne est numéroté à partir d'un espace IPv4 public appartenant à votre organisation, consultez Autoriser une passerelle sur un espace d'adressage public qui vous appartient.

Prérequis

Mettez en place les éléments suivants avant de commencer :

Étapes

1. Enregistrer un client OAuth dans votre IdP

Choisissez d'abord le nom d'hôte de la passerelle, car l'URI de redirection doit y correspondre. Créez une nouvelle application web OIDC et définissez l'URI de redirection sur https://claude-gateway.<your-domain>/oauth/callback, où l'hôte est la même valeur que celle que vous définissez comme listen.public_url à l'étape 3. Notez le client_id et le client_secret. Les instructions propres à chaque IdP se trouvent dans Configuration du fournisseur d'identité.

2. Provisionner une base de données PostgreSQL

Utilisez PostgreSQL 11 ou ultérieur. Le plus petit niveau géré suffit. La passerelle exécute ses propres migrations de schéma au démarrage ; le rôle de base de données doit donc disposer des droits de création et de modification de tables ; consultez store.

3. Écrire gateway.yaml

Les secrets sont lus via l'expansion ${ENV_VAR}, ce qui permet de conserver le fichier lui-même dans le contrôle de version. Utilisez un nom d'hôte public_url qui se résout en une adresse IP privée sur votre réseau, car /login rejette les adresses publiques. La configuration minimale comporte cinq sections, et tous les autres champs ont une valeur par défaut :

listen:
  host: 0.0.0.0
  port: 8080
  # Required unless host is a loopback address. Used for the IdP
  # redirect_uri and the discovery document.
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com        # must serve /.well-known/openid-configuration
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]        # reject id_tokens outside your org
  userinfo_fallback: true                  # for IdPs whose id_token omits email/groups; harmless otherwise

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # also bounds revocation latency on IdP deprovision

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}    # add ?sslmode=require for managed Postgres

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {} # empty: AWS default credential chain
# (IRSA, EC2/ECS task role, env vars, ~/.aws)

# Models are translated per upstream automatically. The built-in catalog
# maps claude-opus-4-8 to us.anthropic.claude-opus-4-8 and so on for every
# Bedrock-supported Claude model. Set false and add a `models:` list to
# expose only specific models.
auto_include_builtin_models: true

Cette configuration suffit pour obtenir une boucle de connexion fonctionnelle avec le catalogue de modèles Amazon Bedrock par défaut. Une fois qu'elle fonctionne, ajoutez le RBAC par groupe et les paramètres gérés via managed.policies, la diffusion de la télémétrie via telemetry, et le basculement multi-upstream, les ARN de débit provisionné ou les régions hors des États-Unis via models.

[!NOTE]

L'upstream Amazon Bedrock nécessite un principal AWS disposant de bedrock:InvokeModel et bedrock:InvokeModelWithResponseStream sur les ARN inference-profile/us.anthropic.* ainsi que sur les ARN sous-jacents foundation-model/anthropic.*. Il nécessite également que le formulaire de cas d'usage unique d'Anthropic ait été soumis pour le compte depuis le Model catalog de la console Bedrock.

Fournissez les identifiants avec IRSA sur EKS, un rôle de tâche ECS ou un profil d'instance EC2 plutôt qu'avec des clés statiques. La référence upstreams contient tous les détails IAM, la matrice des identifiants inter-cloud et les blocs auth pour les autres fournisseurs.

4. L'exécuter

Créez une image de conteneur autour du binaire claude qui respecte les exigences relatives à l'image, puis exécutez-la aux côtés de Postgres. Le fichier Compose référence l'image sous le nom registry.example.com/claude-gateway:2.1.198 ; remplacez-le par votre propre registre et votre propre tag d'image :

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 credentials: in production, omit these and use an instance
      # role. For local Compose testing, pass through your own:
      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: }

La passerelle est un binaire Linux unique qui lit la configuration, se connecte à Postgres et applique ses migrations de schéma, exécute la découverte OIDC auprès de votre IdP, construit les clients upstream et commence à écouter.

Le démarrage est en mode fail-closed pour la configuration, la connexion Postgres, la découverte OIDC et la construction des clients upstream. Si l'un de ces éléments est inaccessible ou mal configuré, la passerelle se termine avec une erreur au lieu de servir du trafic dans un état dégradé.

Un démarrage réussi ne valide pas le chemin d'inférence, car les identifiants d'instance d'Amazon Bedrock et d'Agent Platform de Google Cloud sont résolus lors de la première requête, et non au démarrage.

Surveillez stderr pour suivre la séquence de démarrage. Les lignes de log utilisent le format [gateway] <timestamp> <level> <message>, les événements d'audit sont du JSON sur une seule ligne avec un champ evt, et une bannière de démarrage, omise ci-dessous, s'affiche entre les lignes de migration et d'écoute. Une base de données vierge affiche une ligne migration N applied par migration de schéma ; une base de données déjà migrée n'en affiche aucune. Vous devriez voir, dans l'ordre :

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

La passerelle journalise également un avertissement indiquant que access_control.allow_cidrs est vide. C'est attendu ici, car rien ne limite les adresses clientes que la passerelle sert tant que vous n'avez pas défini de liste d'autorisation. La référence access_control indique les plages recommandées.

Si le démarrage se termine avant la ligne claude gateway listening on, la dernière ligne de stderr indique le problème :

• un Postgres inaccessible
• un rôle Postgres sans permission DDL
• un document de découverte OIDC inaccessible ou invalide
• une violation du schéma de configuration avec le chemin du champ fautif

Corrigez-le et redémarrez.

Si vous disposez déjà d'un ingress qui termine TLS, ignorez Compose et exécutez directement le binaire avec claude gateway --config gateway.yaml. Définissez public_url sur l'origine de l'ingress et liez listen à une adresse de loopback ou interne au cluster.

5. Vérifier la surface d'authentification

Trois vérifications confirment que la passerelle peut authentifier un utilisateur réel avant que vous ne la partagiez avec un développeur.

Les exemples utilisent l'URL publique de la passerelle ; pour la configuration Compose locale sans ingress, remplacez-la par http://localhost:8080 dans les deux premières vérifications. La troisième vérification ouvre verification_uri_complete, qui est construit à partir de public_url ; pour Compose en local, définissez donc public_url: http://localhost:8080 dans gateway.yaml, et ajoutez http://localhost:8080/oauth/callback comme seconde URI de redirection sur le client OAuth de l'étape 1, car la passerelle construit le redirect_uri de l'IdP à partir de public_url. Le lien de vérification s'ouvre alors dans votre navigateur local.

Dans Windows PowerShell, exécutez curl.exe ; la commande curl seule est un alias de Invoke-WebRequest et rejette ces flags.

Premièrement, récupérez le document de découverte, ce qui confirme que la passerelle est opérationnelle, que la configuration est valide et que toutes les vérifications de démarrage ont réussi :

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

La réponse inclut des champs supplémentaires, tels que response_types_supported et scopes_supported.

Deuxièmement, demandez une autorisation d'appareil, ce qui confirme que le flux de connexion par appareil fonctionne et que Postgres est accessible et inscriptible :

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
}

Troisièmement, testez la partie navigateur en ouvrant verification_uri_complete dans un navigateur et en confirmant le code. Vous devriez être redirigé vers la page de connexion de votre IdP, puis, après vous être connecté, revenir sur la passerelle avec une confirmation de connexion.

Utilisez la première vérification qui échoue pour localiser le problème :

• La première vérification échoue : le démarrage ne s'est pas terminé ; consultez stderr
• La deuxième vérification échoue : Postgres n'est pas accessible depuis la passerelle ou le rôle ne peut pas écrire ; vérifiez la chaîne de connexion et les droits accordés
• La troisième vérification n'atteint pas l'IdP : vérifiez que l'URI de redirection de l'IdP correspond exactement à https://<gateway>/oauth/callback
• La troisième vérification atteint l'IdP mais revient avec une erreur : lisez le log d'audit de la passerelle, qui consigne chaque rejet d'authentification avec sa raison, par exemple email domain not allowed

6. Connecter un développeur

Cette dernière étape se déroule sur une machine de développeur, et non sur le serveur. Définissez forceLoginMethod sur "gateway", forceLoginGatewayUrl sur le public_url de votre passerelle et parentSettingsBehavior sur "merge" dans le fichier de paramètres gérés de cette machine, puis exécutez /login, appuyez sur Enter sur l'écran Cloud gateway et terminez la connexion dans le navigateur. La section Définir l'URL de la passerelle ci-dessous couvre ces trois clés et leur distribution sur chaque machine de développeur.

Connecter les développeurs

Les développeurs se connectent depuis leur propre ordinateur portable avec une seule connexion dans le navigateur, en utilisant leur compte professionnel d'entreprise. Ils n'ont besoin ni d'un compte claude.ai, ni d'une clé API, ni d'un abonnement, car les requêtes vers le 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 déployez via MDM, et cette section couvre ce que l'administrateur configure.

Le CLI relève l'empreinte du certificat TLS feuille de la passerelle lors de la première connexion et l'épingle par nom d'hôte. Il vérifie à nouveau cet épinglage lors de la connexion, lors des actualisations silencieuses de session et lors des récupérations de paramètres gérés, tandis que les requêtes d'inférence utilisent la validation TLS standard sans l'épinglage. Les requêtes acheminées via un proxy HTTPS ignorent la vérification de l'épinglage ; ajoutez donc l'hôte de la passerelle à NO_PROXY pour qu'elles restent directes.

Publiez l'empreinte SHA-256 attendue avec l'URL de la passerelle afin que les développeurs disposent d'une référence de comparaison. L'invite /login affiche les 16 premiers caractères de l'empreinte en hexadécimal minuscule, sans deux-points. Pour afficher 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'

Lorsque le certificat change, chaque développeur voit à nouveau l'invite de confiance ; traitez donc les rotations comme un événement planifié et republiez l'empreinte. Si la politique de votre passerelle inclut des paramètres qui nécessitent une approbation, le développeur voit aussi à nouveau cette boîte de dialogue d'approbation après avoir accepté le nouveau certificat, car Claude Code associe la mémoire des approbations au certificat épinglé.

Une passerelle peut renvoyer le champ facultatif email dans sa réponse de jeton pour nommer le compte utilisé lors d'une connexion. Dans ce cas, le développeur confirme le compte avant que Claude Code n'enregistre les identifiants. 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 de version antérieure ignore le champ. Le serveur de passerelle intégré au binaire claude ne renvoie pas ce champ, ses connexions se terminent donc sans confirmation.

Une fois le développeur connecté, le sélecteur de modèle affiche les modèles de sa liste d'autorisation availableModels. Les paramètres gérés s'appliquent au démarrage et sont actualisés toutes les heures, et la télémétrie est acheminée vers votre collecteur.

Les sessions sont actualisées silencieusement avant l'expiration de ttl_hours. Lorsqu'une actualisation échoue après le déprovisionnement dans l'IdP, Claude Code demande au développeur de se reconnecter.

Définir l'URL de la passerelle

Trois clés figurent dans le fichier de paramètres gérés propre à chaque OS, que vous déployez via MDM ou directement sur le disque. Pour une machine sans paramètres gérés, consultez plutôt Définir l'URL de la passerelle dans les paramètres utilisateur. forceLoginMethod et forceLoginGatewayUrl ouvrent /login directement sur l'écran Cloud gateway avec l'URL préremplie, et parentSettingsBehavior: "merge" permet à Claude Desktop de transmettre la liste d'autorisation de sortie de la passerelle aux sessions Claude Code qu'il lance, comme expliqué dans Transmettre la politique aux sessions Claude Desktop :

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

Le développeur appuie sur Enter pour se connecter. L'invite d'empreinte TLS de première connexion apparaît toujours. Une fois le fichier présent sur une machine, un développeur qui n'a pas terminé la connexion à la passerelle voit l'un des messages décrits sous Administrator policy requires a Cloud gateway sign-in. 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 se connecter à la passerelle.

Le sélecteur de connexion ne propose pas d'option de passerelle, et dans les paramètres gérés, forceLoginMethod seul, sans URL, laisse le développeur face à un message « Contact your IT administrator ». Les clés de connexion doivent figurer dans le fichier que vous déployez sur les machines, et non dans le bloc managed.policies[].cli de la passerelle, qui n'atteint que les clients déjà connectés.

Définir l'URL de la passerelle dans les paramètres utilisateur

Sur les machines sans paramètres gérés, demandez à chaque développeur d'ajouter forceLoginMethod et forceLoginGatewayUrl à son propre fichier de paramètres utilisateur, ~/.claude/settings.json. Cela nécessite Claude Code v2.1.295 ou ultérieur sur la machine du développeur. Cet exemple désigne une passerelle à l'adresse claude-gateway.internal.example.com :

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

Lorsque le développeur exécute /login dans l'invite Claude Code, l'écran Cloud gateway s'ouvre sur cette adresse et il appuie sur Enter pour se connecter. L'invite d'empreinte TLS de première connexion apparaît toujours. Ces limites s'appliquent aux clés définies de cette manière :

• Paramètres utilisateur uniquement : Claude Code lit les deux clés depuis ~/.claude/settings.json, et non depuis le .claude/settings.json ou le .claude/settings.local.json d'un projet.
• Les paramètres gérés les désactivent : dès que les paramètres d'un administrateur atteignent la machine via un fichier de paramètres gérés, un plist macOS ou une politique HKLM Windows, ou un policy helper, Claude Code ignore une passerelle désignée dans les paramètres utilisateur.

Autoriser une passerelle sur un espace d'adressage public qui vous appartient

Certaines organisations numérotent leur réseau interne à partir d'un bloc IPv4 public qu'elles possèdent, comme l'espace d'adressage propre d'un opérateur ou un ancien /8, si bien que leur passerelle n'a pas d'adresse privée. Listez ces blocs dans le paramètre géré gatewayInternalNetworks. /login accepte alors une passerelle située dans un bloc listé lorsque la machine du développeur s'y connecte depuis une adresse située dans ce 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 des adresses privées.

[!WARNING]

gatewayInternalNetworks est destiné aux réseaux internes qui se trouvent être numérotés à partir d'un espace d'adressage public. Il ne rend pas sûre l'exposition d'une passerelle sur internet : une passerelle de confiance peut pousser des paramètres qui exécutent des commandes sur les machines des développeurs.

Maintenez la passerelle inaccessible depuis l'extérieur de votre réseau grâce aux règles de votre pare-feu ou de votre load balancer. Définissez le paramètre access_control.allow_cidrs de la passerelle sur les mêmes blocs que ceux que vous déclarez ici, afin que la passerelle elle-même refuse les clients venant d'ailleurs. Derrière un load balancer ou un ingress, définissez aussi listen.trusted_proxies sur ce frontal, car sinon la passerelle compare allow_cidrs à l'adresse du frontal plutôt qu'à celle du développeur.

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, de projet et gérés par le serveur.

Cet exemple déclare un bloc. Remplacez 203.0.113.0/24 par votre propre bloc. Il s'agit d'une plage de documentation, que Claude Code refuse.

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

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

• Chaque entrée est un bloc IPv4 écrit sous la forme de sa première adresse et d'un préfixe allant de /8 à /32.
• La liste contient au plus quatre blocs, et aucun ne chevauche un autre.
• Aucun bloc ne chevauche l'espace d'adressage privé : 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 dans ces plages sans cette clé.
• Aucun bloc ne chevauche un 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 utilisent 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 la plage 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 de ses fichiers complémentaires managed-settings.d/ sont combinés en une seule liste, et ces limites s'appliquent à la liste combinée. Pour restreindre un bloc, remplacez son entrée plutôt que d'en ajouter une seconde qui le chevauche dans un fichier complémentaire ; /login refuse le chevauchement.

Si une entrée enfreint une règle, ou si la valeur n'est pas une liste de chaînes, Claude Code refuse toute nouvelle connexion à une passerelle sur cette machine et indique le problème dans le message. La connexion à une passerelle sur une adresse privée échoue aussi, et les connexions existantes continuent de fonctionner. Testez 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 signale.

Avec une liste valide, /login applique trois vérifications à une passerelle dont l'adresse se trouve dans un bloc listé :

• Toutes les adresses vers lesquelles le nom d'hôte de la passerelle se résout se trouvent dans ce seul bloc. Claude Code refuse un nom qui possède aussi des enregistrements en dehors, adresses privées et IPv6 comprises.
• La machine du développeur se connecte depuis l'intérieur du même bloc. Claude Code refuse une machine derrière un NAT, dans un conteneur ou WSL2, ou sur un VPN dont le pool d'adresses se situe en dehors du bloc, et indique l'adresse depuis 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 indique l'entrée NO_PROXY à ajouter.

Lorsque les trois vérifications réussissent, l'invite de confiance ajoute une ligne indiquant 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 passerelle sur une adresse privée fonctionne comme avant, et la connexion à une passerelle sur une adresse publique en dehors de tout 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 ; ne déclarez donc que l'espace d'adressage que votre organisation contrôle. Un bloc partagé avec d'autres locataires, comme la plage publique d'un fournisseur cloud, permet à quiconque s'y trouve de passer la même vérification.

Transmettre la politique aux sessions Claude Desktop

Claude Desktop exécute ses onglets Cowork et Code, ainsi que Chat lorsque vous l'activez, sur des sessions Claude Code intégrées et envoie leurs requêtes de modèle via la passerelle. Il transmet une politique à chacune de ces sessions, construite à partir de la configuration que la passerelle lui fournit à /user/bootstrap : la liste d'autorisation des modèles, les outils désactivés et la liste d'autorisation de sortie dérivés du bloc cli ou code de la politique correspondante, ainsi que la surcouche desktop.

Les autres clés du bloc, comme les hooks, env et les règles de permission ciblées telles que Bash(npm *), atteignent les clients qui se connectent via /login. Sous code, elles atteignent aussi la session de l'onglet Code lorsque les conditions pour l'onglet Code sont réunies. Elles n'atteignent pas les sessions Cowork ou Chat. Claude Desktop lit l'URL de la passerelle depuis sa propre configuration gérée et se connecte avec son propre flux, distinct des clés forceLoginMethod et forceLoginGatewayUrl de 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 disposant d'une source gérée déployée par un administrateur, sauf si la source qui fournit la politique définit parentSettingsBehavior: "merge".

Quelles machines ont besoin de l'activation

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

Une liste d'autorisation de marketplaces de plugins n'atteint elle aussi les sessions intégrées que sous forme de paramètres parents. Lorsque vous désactivez les marketplaces de plugins ajoutées par l'utilisateur dans la configuration gérée de Claude Desktop, Claude Desktop 2.16120.0 ou ultérieur masque les marketplaces que votre organisation n'a pas provisionnées et refuse les installations depuis celles-ci. Pour empêcher les sessions intégrées de charger les plugins déjà installés depuis ces marketplaces, il leur envoie une liste strictKnownMarketplaces sous forme de paramètres parents. Sans l'activation, Claude Code ignore cette liste, et ces plugins continuent de se charger.

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 parcs dont le policyHelper fournit les paramètres gérés ne peuvent pas l'utiliser : Claude Code ne fusionne jamais les paramètres parents sur ces parcs, car il lit les paramètres gérés uniquement à partir de la sortie du helper.

Définir l'activation

Déployez l'extrait de paramètres gérés de Définir l'URL de la passerelle, reproduisez-le dans toute source côté client prioritaire sur le fichier, puis vérifiez.

1. Déployer l'activation dans le fichier de paramètres gérés

L'extrait ci-dessus inclut déjà parentSettingsBehavior: "merge", donc le fichier que vous déployez sur les machines le contient.

2. Reproduire l'extrait dans toute source prioritaire sur le fichier

Claude Code ne lit parentSettingsBehavior que depuis la source sélectionnée. L'ajout d'une clé de politique quelconque à une source peut faire de cette source la source sélectionnée ; dans une source côté client, reproduisez donc l'extrait entier plutôt que parentSettingsBehavior seul. Paramètres gérés côté client couvre les parcs qui fournissent la politique via une stratégie de groupe ou des profils de configuration. Un plist managed-preferences sur macOS ou une politique HKLM sur Windows est prioritaire sur le fichier managed-settings.json, et les paramètres gérés à distance de la passerelle elle-même sont prioritaires sur les deux ; sur les machines qui se connectent à la passerelle, définissez donc aussi parentSettingsBehavior dans le bloc cli ou code de la politique de la passerelle.

3. Vérifier quelle source est sélectionnée

Sur une machine qui n'exécute que Claude Desktop, appelez resolveSettings() de l'Agent SDK et lisez policyOrigin sur l'entrée managed de sa liste sources. La valeur désigne la source côté client sélectionnée, plist, hklm ou file, qui est la source devant contenir l'extrait.

Les sessions Cowork et Chat ne récupèrent pas la politique de la passerelle, donc le bloc de la passerelle n'est pas la source sélectionnée pour elles.

Une session de l'onglet Code la récupère lorsque les paramètres de la politique sont sous code et que les conditions pour l'onglet Code sont réunies. Les paramètres code de la passerelle sont alors la source sélectionnée pour cette session.

Restreindre les paramètres parents

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

Claude Code filtre les paramètres parents selon une liste d'autorisation de clés restrictives, mais certaines clés autorisées peuvent accorder un accès plutôt que le restreindre. Sauf si vous définissez les verrous allowManaged*Only, les règles d'autorisation de permission et les listes d'autorisation du sandbox fournies par l'hôte s'appliquent toujours. Les règles deny et ask de votre politique restent en vigueur dans tous les cas ; elles sont évaluées avant toute règle allow.

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

• Entrées deny : transmises avec uniquement leur path ou name et le mode.
• Entrées de fichier avec mode: mask : transmises sous forme de sentinelle uniquement, en tant que masque de fichier entier dont injectHosts est la liste vide, de sorte que 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, afin qu'un motif d'extraction fourni par le parent ne puisse pas remplacer 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 en restriction uniquement. De sigv4, seules les valeurs deny sont conservées, et un parent qui définit un bloc sigv4 quel qu'il soit fixe les trois formes de requête, streaming, presigned et sigv4a, à deny. Une paire awsPairs n'est jamais transmise sous une forme permettant de re-signer ; une paire qui nomme l'une des variables AWS conventionnelles est remplacée par une entrée inerte qui maintient la suppression de l'appariement automatique de AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_SESSION_TOKEN.

Déployer les verrous

Pour que les paramètres parents restent aussi proches que possible d'une restriction pure dans les limites du filtre, ajoutez les cinq verrous allowManaged*Only, ainsi que les listes d'autorisation qu'ils régissent, aux mêmes sources que l'activation de la 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 d'OS, comme une politique de registre HKLM ou un plist managed-preferences, est prioritaire sur ce fichier ; fournissez donc l'extrait entier par ce biais plutôt que par le fichier. Les paramètres gérés à distance de la passerelle sont prioritaires sur la politique d'OS et sur les sources de fichier, mais n'atteignent que les clients connectés. Reproduisez les verrous, les listes d'autorisation et l'activation de la fusion dans le bloc cli ou code de la politique et gardez ce fichier déployé, car les machines qui ne se connectent jamais obtiennent leur politique uniquement depuis le fichier.

Comportement des verrous selon les sources

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

Depuis une source d'administration inférieure à la source retenue, les deux verrous du sandbox s'appliquent toujours, et allowManagedPermissionRulesOnly bloque toujours les règles allow et les additionalDirectories fournies par le parent. Sur Claude Code v2.1.273 ou ultérieur, le verrou des serveurs MCP s'applique aussi depuis une source inférieure à la source retenue, et tant qu'il est actif, la liste gérée allowedMcpServers provient de la source d'administration de plus haute priorité qui en définit une.

Le verrou des hooks et l'effet de allowManagedPermissionRulesOnly sur les propres règles du développeur nécessitent par défaut la source retenue ; avec l'activation de fusion managedSourcesBehavior décrite dans comment Claude Code combine les sources gérées, Claude Code applique pour chaque verrou la valeur la plus stricte définie par une source quelconque. Sur les parcs utilisant policyHelper, Claude Code lit les verrous uniquement à partir de la sortie du helper.

Chaque verrou fait ignorer à Claude Code les propres entrées du développeur pour ce paramètre ; incluez donc 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 du sandbox.
• Serveurs MCP : verrouiller sans allowedMcpServers dans aucune source d'administration ni dans les paramètres fournis par le parent charge tous les serveurs que deniedMcpServers ne bloque pas.
• Chemins de lecture : les entrées allowRead ne réautorisent que des chemins situés dans les zones denyRead ; associez-les donc à un denyRead géré.

Paramètres que les verrous ne couvrent pas

Ces paramètres fournis par le parent passent le filtre même avec les cinq verrous définis :

• forceLoginOrgUUID : Claude Code respecte une valeur fournie par le parent lorsque les paramètres gérés qu'il applique ne définissent pas d'UUID d'organisation. La connexion à la passerelle ne vérifie pas cette clé. Un UUID d'organisation dans les paramètres gérés que Claude Code applique bloque la valeur du parent et constitue l'UUID d'organisation que Claude Code impose. Si votre parc épingle une organisation Anthropic, consultez Quelle source gérée fournit les clés de connexion pour savoir où définir forceLoginOrgUUID.
• allowedMcpServers : Claude Code respecte une liste d'autorisation fournie par le parent lorsqu'aucune liste d'administration n'est en vigueur. allowManagedMcpServersOnly ne la bloque pas, car le verrou impose la liste retenue comme valeur gérée, y compris une liste fournie par le parent lorsqu'aucune source d'administration n'en fournit. Une liste dans la source d'administration de plus haute priorité bloque celle du parent et constitue la liste que Claude Code impose ; définissez donc allowedMcpServers à cet endroit, à côté du verrou. Avant la v2.1.223, une valeur pour l'une ou l'autre clé dans une source d'administration quelconque bloquait celle du parent.
• availableModels : Claude Code respecte une liste de modèles fournie par le parent lorsque la source gérée retenue n'en définit pas. Si votre parc restreint les modèles, définissez availableModels dans la source retenue.
• allowedProviders : Claude Code respecte une liste d'autorisation de fournisseurs d'API fournie par le parent lorsque la source gérée retenue n'en définit pas. Si votre parc restreint les fournisseurs d'API que les développeurs peuvent utiliser, définissez allowedProviders dans la source retenue. Nécessite Claude Code v2.1.285 ou ultérieur.
• strictKnownMarketplaces : Claude Code respecte une liste d'autorisation de marketplaces de plugins fournie par le parent lorsque la source gérée retenue n'en définit pas. Claude Desktop 2.16120.0 ou ultérieur en envoie une lorsque sa configuration gérée désactive les marketplaces de plugins ajoutées par l'utilisateur. Si votre parc restreint les marketplaces, définissez strictKnownMarketplaces dans la source retenue. Nécessite Claude Code v2.1.282 ou ultérieur.
• blockedMarketplaces : une liste de blocage de marketplaces fournie par le parent passe et s'ajoute à toute liste de blocage définie par une source gérée, 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 quel que soit le verrou, et elle fait ignorer à Claude Code la personnalisation propre au développeur, y compris les hooks de protection. Aucun verrou ne la bloque.

Si vous définissez managedSourcesBehavior sur "merge", vérifiez quelle valeur de source s'applique pour chaque type de clé.

Comment les clés de hook et de skill des paramètres parents prennent effet

Les clés que votre application transmet dans l'option managedSettings de l'Agent SDK sont des paramètres parents. Sur une machine où un administrateur déploie des paramètres gérés, Claude Code ignore les paramètres parents sauf si l'administrateur autorise un hôte intégrateur à ajouter une politique.

Si vous transmettez disableAllHooks: true dans managedSettings :

• S'arrêtent : les hooks utilisateur, de projet et locaux, ainsi que les hooks déclarés dans le frontmatter d'un agent ou dans l'option settings du SDK.
• Continuent de s'exécuter : les callbacks de hook du SDK de votre application et les hooks d'un administrateur issus des paramètres gérés. Votre application ne peut pas désactiver les hooks de l'administrateur.

La transmission de ces clés dans managedSettings nécessite Claude Code v2.1.309 ou ultérieur, ou l'Agent SDK TypeScript v0.3.309 ou ultérieur.

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 sur <listen.public_url>/user/bootstrap, et activez la politique de l'utilisateur avec une clé desktop. Surcouche Claude Desktop couvre ces deux volets. 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 de SSO dans le navigateur, puis récupère sa configuration auprès de la passerelle plutôt qu'auprès d'Anthropic. L'accès aux modèles et la politique suivent les mêmes règles par groupe que pour le CLI. Un développeur qui utilise à la fois le CLI et Claude Desktop se connecte séparément à chacun ; la session de passerelle n'est pas partagée entre eux.

Une fois connecté, Claude Desktop envoie les requêtes de modèle de chaque onglet activé via la passerelle. Il affiche par défaut les onglets Cowork et Code. Pour rendre également Chat disponible, définissez chatTabEnabled sur true dans le bloc desktop de la politique sur une passerelle exécutant Claude Code v2.1.227 ou ultérieur. Lorsque Cowork est activé, Claude Desktop affiche alors Chat et Cowork ensemble dans un même onglet.

Pipelines CI et machines distantes

Il n'existe pas de flux par jeton de service pour les pipelines sans surveillance. La connexion à la passerelle exécute toujours le device flow dans le navigateur ; un job CI sans développeur pour approuver la connexion ne peut donc pas s'authentifier. Configurez ces jobs directement auprès de votre fournisseur. Déployez forceLoginMethod et forceLoginGatewayUrl sur les machines des développeurs et laissez-les hors des runners CI. Sur une machine dont les paramètres gérés les définissent, une session qui s'authentifie avec ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN ou apiKeyHelper se termine au démarrage.

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 l'Agent SDK. Claude Code applique la politique de la passerelle à chacune d'elles.

Le device flow sépare le CLI qui interroge du navigateur qui approuve ; une machine de développement distante sans écran fonctionne donc aussi : le développeur exécute /login via SSH sur la machine distante et ouvre le lien de vérification dans le navigateur de son ordinateur portable.

Ce qui est imposé 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 Transmettre la politique aux sessions Claude Desktop, et le point sur la télémétrie indique où vont leurs exports.

• Accès aux modèles : les requêtes pour des modèles que la politique n'accorde pas renvoient 400, et le sélecteur /model est filtré selon la liste d'autorisation availableModels de la politique. Cela inclut le modèle sur lequel une session démarre avant que le développeur n'en choisisse un ; consultez Démarrer les sessions sur un modèle autorisé par la politique.
• Destination de la télémétrie : dans les sessions connectées via /login, le CLI envoie ses exports OTLP/HTTP à la passerelle plutôt qu'à un OTEL_EXPORTER_OTLP_ENDPOINT défini localement, sauf si une politique désigne votre collecteur comme endpoint. La passerelle relaie les exports qu'elle reçoit vers les destinations de telemetry.forward_to.
  • Dans les sessions intégrées que Claude Desktop lance, le CLI envoie ses exports au OTEL_EXPORTER_OTLP_ENDPOINT configuré. Le CLI joint le jeton de session de la passerelle à ces exports uniquement lorsque cet endpoint pointe vers la passerelle elle-même.
  • Si aucune destination n'est configurée pour un signal, la passerelle l'accepte et le supprime.
  • Si vous collectez déjà directement la télémétrie de Claude Code, ajoutez votre collecteur comme destination forward_to, ou désignez-le dans une politique pour éviter le relais.
• Identifiants : le jeton de la passerelle est le seul identifiant de la session. Les profils Anthropic et toute connexion claude.ai antérieure sont ignorés pendant la connexion ; les développeurs n'ont donc pas besoin de se déconnecter de claude.ai au préalable. Pour des identifiants ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN ou apiKeyHelper configurés, ou une clé API enregistrée par une connexion antérieure à la Claude Console, consultez Administrator policy requires a Cloud gateway sign-in.
• Paramètres gérés : les clés verrouillées ne peuvent pas être remplacées localement. Le CLI applique la politique au démarrage et applique les modifications à chaque interrogation horaire, à l'exception des modifications qui ne s'appliquent qu'au lancement suivant.
• 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 a mis fin à la session : consultez Imposer un démarrage fail-closed pour les lancements qui s'ouvrent déconnectés de la passerelle et ceux qui se terminent lorsque la passerelle répond par un 401.
• Déprovisionnement : une session dont l'utilisateur est désactivé dans l'IdP expire dans le délai de ttl_hours lorsque l'actualisation suivante échoue.
• Déconnexion : /logout supprime les identifiants de la passerelle de la machine du développeur.
  • Lorsque le document de découverte de la passerelle annonce un revocation_endpoint sur le même schéma, hôte et port que l'URL de la passerelle, /logout envoie aussi les jetons stockés à cet endpoint afin que la passerelle puisse mettre fin à la session de son côté. La requête est envoyée au mieux ; la déconnexion se termine donc sur la machine du développeur, que l'endpoint 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 intégré au binaire claude n'en annonce aucun ; une déconnexion de celui-ci ne met donc fin à la session que sur la machine du développeur. Pour forcer la fermeture des sessions côté serveur, consultez Rotation du secret JWT.

Ce que l'organisation peut voir

La télémétrie d'utilisation transmet au collecteur de l'organisation l'identité du développeur, le nombre de tokens, le modèle et la latence. La passerelle ne journalise ni ne stocke le contenu des prompts ou des complétions. La collecte d'une télémétrie plus riche, comme les logs et les traces, qui peuvent inclure des commandes et des chemins de fichiers, relève d'un 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 la CLI 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 requête ; les autres amonts 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.