Gouvernance auto-hébergée à côté de la passerelle des applications Claude : un guide de co-déploiement

Anthropic a livré la passerelle d’applications Claude fin juin 2026. Il s’agit d’un service auto-hébergé regroupé dans le binaire claude (v2.1.195+). Vous l’exécutez avec claude gateway --config gateway.yaml, le sauvegardez avec PostgreSQL, et il place la connexion OIDC devant votre flotte Claude Code : des sessions IdP d’entreprise au lieu de clés API gérées localement. C’est un véritable pas en avant. Pour les équipes qui exécutent Claude Code directement sur Bedrock, Vertex, Foundry ou l’API Anthropic, la passerelle centralise les contrôles d’identité, d’accès aux modèles et de dépenses derrière un seul fichier de configuration.

Cet article parle de ce qui se passe ensuite. Votre patrimoine IA est presque certainement plus que Claude. Vous exécutez probablement des serveurs MCP provenant de plusieurs fournisseurs. Vous pouvez avoir des charges de travail OpenAI ou Gemini, une inférence auto-hébergée via vLLM ou Ollama, des pipelines CI qui ne voient jamais un navigateur et des infrastructures d’agent qui délèguent entre fournisseurs. La passerelle d’applications est réservée uniquement à Claude et à OIDC. Il s’agit d’une décision de portée, pas d’un défaut – mais cela signifie que la question de gouvernance n’a reçu qu’une réponse partially.

Le modèle de co-déploiement décrit ici place une plateforme de gouvernance auto-hébergée aux côtés de la passerelle, lisant à la fois la télémétrie de la passerelle et le reste de votre infrastructure d’agent. Complémentaire, non compétitif : la passerelle gère l’authentification, la plateforme gère la gouvernance.

Ce que fait bien la passerelle d’applications

La passerelle résout un problème spécifique et important : donner à Claude Code une couche d’identité appropriée. Avant que cela n’existe, chaque développeur possédait une clé API ou utilisait des informations d’identification partagées, et il n’existait aucun moyen standardisé d’imposer l’accès aux modèles, les plafonds de dépenses ou les paramètres gérés au niveau organisationnel.

Avec la passerelle en place :

• Les développeurs s’authentifient via votre fournisseur d’identité OIDC (un émetteur par instance de passerelle).
• Les groupes d’IdP sont mappés aux listes autorisées de modèle et aux stratégies de paramètres gérés dans gateway.yaml.
• Les limites de dépenses sont appliquées par utilisateur, par groupe ou par organisation, avec une API d’administration de limites de dépenses.
• La télémétrie est répartie sur OTLP/HTTP, estampillée user.id, user.email et user.groups.
• Les événements d’audit (11 types : config.load, session.mint, auth.denied, inference, etc.) sont émis sous forme de JSON sur une seule ligne sur stderr.

Il s’agit d’une infrastructure bien conçue pour sa portée indiquée. Anthropic publie le protocole de passerelle et invite des implémentations tierces, ce qui constitue une posture inhabituellement ouverte pour un fournisseur de modèles.

Ce qu’il ne couvre pas

Anthropic documente clairement les décisions de portée suivantes. Ce ne sont pas des défauts : ils définissent à quoi appartient une limite de co-déploiement :

• OIDC uniquement. Pas de SAML, pas de LDAP. Si votre IdP utilise SAML, vous avez besoin d’un pont OIDC devant la passerelle.
• Émetteur unique. Un fournisseur OIDC par instance de passerelle. Les déploiements mutualisés nécessitent des instances distinctes.
• Claude seulement. Le catalogue de modèles est composé de modèles Claude. OpenAI, Gemini, l’inférence locale et d’autres fournisseurs ne relèvent pas de la portée de la passerelle.
• Aucun flux de jeton de service. Les pipelines CI/CD sans surveillance n’ont pas de chemin d’authentification non interactif documenté via la passerelle.
• Pas d’interface utilisateur d’administration. La configuration est le fichier YAML ; les changements nécessitent un redéploiement.
• Pas de graphique Helm. La passerelle s’exécute comme un déploiement standard, mais il n’y a pas de graphique packagé.

Au-delà de ces limites documentées, il existe des problèmes de gouvernance pour lesquels la passerelle n’a pas été conçue :

• Inventaire et posture du serveur MCP. Quels serveurs MCP sont déployés, quels outils ils exposent et si leurs capacités déclarées correspondent à leur comportement observé — rien de tout cela n’est le travail de la passerelle.
• Application de la stratégie entre fournisseurs. Une stratégie indiquant que « les bases de données de production sont en lecture seule pour tous les agents » doit s’appliquer aux modèles Claude, OpenAI et auto-hébergés. La passerelle régit l’accès au modèle Claude ; il ne régit pas les ressources touchées par ces modèles, ni ce que font les autres modèles.
• Mappage des accès au niveau de la session. La création d’un graphique indiquant quelle session d’agent a atteint quelle base de données, magasin d’objets ou point de terminaison d’API (et si cet accès a été en lecture ou en lecture/write) nécessite de corréler la télémétrie, les hooks et les signaux d’infrastructure. La passerelle relaie OTLP textuellement ; il n’analyse pas ce que décrit la télémétrie.
• Audit inviolable. La passerelle émet des événements d’audit JSON sur stderr. Ces événements doivent atterrir dans un grand livre avec chaîne de hachage et ajout uniquement s’ils doivent prendre en charge les ensembles de preuves de conformité.

Le modèle de co-déploiement

L’architecture est volontairement simple : la passerelle et la plateforme de gouvernance fonctionnent côte à côte dans votre infrastructure, chacune faisant ce pour quoi elle est bonne.

  Developer workstations                   Your infrastructure
  ┌─────────────────────┐
  │ Claude Code          │
  │ (v2.1.195+)         │
  └──────┬──────────────┘
         │
         │ OIDC device flow
         │ /v1/messages
         ▼
  ┌──────────────────────────────┐      ┌────────────────────────────────┐
  │ Claude apps gateway          │      │ Olivares AI (self-hosted)      │
  │                              │      │                                │
  │ • OIDC auth (1 issuer)       │      │ • OTLP receiver (gRPC + HTTP)  │
  │ • Model allowlists           │  ──▶ │ • Claude hooks correlation     │
  │ • Spend limits               │ OTLP │ • gateway.yaml posture         │
  │ • Managed settings           │      │ • Audit event ingest           │
  │ • OTLP fan-out               │      │ • Multi-provider governance    │
  │ • JSON audit on stderr       │  ──▶ │ • MCP server inventory         │
  │                              │ logs │ • Access-edge graph (R/RW)     │
  │ Claude models only.          │      │ • Hash-chained audit ledger    │
  │ OIDC only.                   │      │                                │
  └──────────────────────────────┘      │ ALL providers, ALL surfaces.   │
                                        └────────────────────────────────┘
                                                     ▲
         Other agent traffic ────────────────────────┘
         (OpenAI, Gemini, vLLM, Ollama, MCP servers, CI pipelines)

Deux flux de données relient la passerelle à la plateforme :

Diffusion OTLP. La configuration telemetry.forward_to de la passerelle prend déjà en charge les destinations OTLP/HTTP. Pointez-en un vers le récepteur Olivares OTLP. L’attribut session.id met en corrélation la télémétrie relayée par la passerelle avec les enregistrements d’exécution de session du propre récepteur hooks du connecteur Claude. Les attributs d’identité (user.id, user.email, user.groups) ajoutés par la passerelle figurent dans la liste d’autorisation des attributs de l’opérateur et deviennent des étiquettes d’attribution sur les bords de session et les échantillons de coûts — aucun nouveau code de récepteur n’est nécessaire.

Ingestion d’événements d’audit. Le connecteur claude-apps-gateway lit les événements d’audit JSON de la passerelle. Les 11 types d’événements documentés (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) sont mappés aux observations du SDK : les refus liés à la sécurité deviennent des résultats, les événements d’inférence deviennent des bords d’accès, les menthes de session deviennent des observations d’identité et les événements opérationnels deviennent des compteurs de métriques. Les informations personnelles dans les événements bruts sont hachées SHA-256 avant d’entrer dans une observation ; les emails et les identifiants sont pseudonymes.

Le connecteur claude-apps-gateway inventorie également le gateway.yaml lui-même : l’émetteur OIDC, les mappages groupe d’IdP vers modèle, les fournisseurs en amont, les destinations OTLP et la position de l’administrateur des dépenses. Cet inventaire est constitué de métadonnées structurelles : une topologie et non des informations d’identification.

Résultats de posture issus de la configuration de la passerelle

Le connecteur génère une famille de résultats de posture dérivés de la configuration de la passerelle. Voici les choses qu’un opérateur de gouvernance doit savoir sur le déploiement d’une passerelle :

Ces résultats apparaissent dans la même vue de posture que les résultats de tous les autres connecteurs. Le connecteur MCP peut signaler un outil sans bac à sable. Le connecteur Bedrock peut signaler un garde-corps gap. Le connecteur de passerelle signale qu’il manque une stratégie fourre-tout. Une surface, une vue.

A quoi cela ressemble dans la configuration

Le connecteur Claude exécute un récepteur OTLP sur les ports OpenTelemetry standard et un point de terminaison de hooks pour les hooks PreToolUse/PostToolUse de Claude Code. À côté, le connecteur apps-gateway lit le flux de configuration et d’audit de la passerelle. Les deux connecteurs sont livrés sous Apache-2.0 et importent uniquement à partir du SDK, jamais à partir du cœur du moteur.

# olivares.yaml (abrégé)
connectors:
  - name: olivares.claude
    config:
      grpc_addr: "127.0.0.1:4317"
      http_addr: "127.0.0.1:4318"
      hook_path: "/hooks"
      enforcement: |
        {"rules":[
          {"tool":"Bash","decision":"ask","reason":"shell access requires confirmation"},
          {"resource_kind":"file","mode":"write","decision":"ask"}
        ]}
      gateway: "direct"
      semconv_opt_in: "gen_ai_latest_experimental"

  - name: olivares.claude-apps-gateway
    config:
      config_path: "/etc/claude-gateway/gateway.yaml"
      audit_log_path: "/var/log/claude-gateway/audit.jsonl"

Le champ gateway du connecteur Claude marque chaque échantillon de coût avec la surface de déploiement (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), afin que FinOps puisse répartir les dépenses par chemin de fournisseur. Le champ semconv_opt_in active le profil d’ingestion GenAI indépendant du fournisseur (épinglé à OpenTelemetry semconv v1.41.1), ce qui signifie que OpenAI, Gemini ou tout agent instrumenté OTel alimente la même carte d’accès et le même pipeline de coûts, et pas seulement Claude Code.

Un positionnement honnête

Il y a des choses qui valent la peine d’être directes.

Il ne s’agit pas d’un remplacement de passerelle. Le proxy d’inférence Olivares implémente un sous-ensemble du protocole de passerelle publié de Anthropic (découverte de OAuth, autorisation de périphérique RFC 8628, livraison des paramètres gérés et surface d’administration des limites de dépenses - vues, écritures et application par siège, avec ses divergences par rapport au protocole filaire documentées). C’est utile lorsque ce sous-ensemble est suffisant. Il ne s’agit pas d’un remplacement complet du flux OIDC du navigateur de la passerelle, et sa sémantique de dépenses de groupe diffère délibérément (les gains les plus restrictifs plutôt que les règles de fusion de la passerelle). Si la passerelle Anthropic répond à vos exigences d’authentification, exécutez-la.

Le connecteur est en lecture seule. Le connecteur claude-apps-gateway observe la configuration et la sortie d’audit de la passerelle. Il ne modifie pas gateway.yaml, n’injecte pas de stratégies et n’intercepte pas le chemin /v1/messages. C’est une question de visibilité, pas de contrôle.

Olivares AI est une pré-version. Le produit n’est pas certifié selon SOC 2, ISO/IEC 27001, la loi européenne sur l’IA ou tout autre cadre, et aucun audit n’est en cours. Il est conçu en fonction des objectifs de contrôle examinés par ces cadres, de sorte qu’il est prêt à être audité le moment venu.

La valeur réside dans la combinaison. Une équipe qui exécute uniquement Claude Code sur un seul fournisseur, avec un seul IdP, et aucun serveur MCP d’autres fournisseurs, peut trouver la passerelle seule suffisante. Le co-déploiement gagne sa place lorsque le parc est hétérogène : plusieurs fournisseurs, serveurs MCP de plusieurs fournisseurs, modèles auto-hébergés, pipelines CI, exigences de conformité qui couvrent toute la surface de l’agent. C’est là que « l’authentification Claude » et la « gouvernance successorale » posent des problèmes véritablement différents.

FAQ

Le Olivares AI remplace-t-il la passerelle des applications Claude ?

Non. La doctrine est « et, pas ou ». La passerelle Anthropic possède la session d’authentification Claude Code, le routage d’accès au modèle et la sélection en amont. Olivares AI fait de ce déploiement une surface gouvernée au sein d’un plan de contrôle plus large qui couvre également les fournisseurs non Claude, les serveurs MCP, les modèles auto-hébergés et le reste de votre parc d’agents. Si vous utilisez déjà la passerelle, conservez-la.

Puis-je exécuter Olivares AI sans la passerelle d’applications Claude ?

Oui. Le connecteur claude-apps-gateway est facultatif. Le connecteur principal Claude (connectors/claude) ingère la télémétrie OTLP et s’accroche directement à partir des sessions Claude Code, avec ou sans passerelle en face. Si vous n’utilisez pas la passerelle Anthropic, vous perdez son chemin d’authentification de session OIDC mais vous conservez la gouvernance complète : inventaire de session, mappage de bord d’accès, attribution des coûts, application du hook, posture MCP et vue multi-fournisseurs.

Pour connaître la topologie de déploiement en détail, voir /architecture. Pour la gouvernance du serveur MCP entre fournisseurs, voir /product/mcp. Pour la surface complète du produit, voir /product.