Le rôle de la passerelle

Dans l’architecture de référence, la passerelle est le seul composant qui parle à tous les autres : le poste, l’hôte d’exécution, le serveur d’inférence, votre annuaire et votre SIEM. Le poste ne joint ni le moteur d’inférence ni l’hôte d’exécution ; il ne connaît que l’adresse de la passerelle (livre blanc sécurité V3, section 3.1).

Cette page décrit ce que la passerelle tient, et ce qu’elle ne fait pas.

Ce que tient la passerelle

La passerelle authentifie, applique la politique du projet, pilote la session, journalise et révoque (livre blanc sécurité V3, sections 3.1 et 6). Elle forme, avec le bac à sable, le périmètre de confiance du produit : les droits sont portés par ces deux composants, et non par le modèle ou par l’agent.

Fonction	Ce que cela recouvre	Section de cette page
Authentifier	l’identité vient de votre annuaire ; l’agent n’en a aucune	Les identités et les rôles
Appliquer la politique	chaque action est évaluée avant son exécution, hors du poste	La politique du projet
Piloter la session	elle ouvre le bac à sable et lui parle par un canal de contrôle unique	Le pilotage des sessions
Relayer vers le modèle	elle est seule autorisée à joindre le moteur d’inférence	Un seul chemin vers le modèle
Journaliser	chaque session est reconstituable après coup	Le journal
Révoquer	une session ou un utilisateur se retire depuis la console, sans redémarrage	Retirer un accès

Les identités et les rôles

Lemniscate ne gère pas d’identités : il s’appuie sur les vôtres (livre blanc sécurité V3, section 6.1). L’authentification passe par le fournisseur d’identité de votre organisation, en OpenID Connect, ou par des comptes locaux pour les environnements isolés. Chaque session est liée à un utilisateur et à un projet.

Rôle	Ce qu’il fait
Administrateur sécurité	définit les politiques globales et les exports de journaux ; ne voit pas le code
Administrateur de projet	définit les outils actifs, les commandes libres ou à valider, les budgets, les membres du projet
Développeur	lance des sessions dans les projets dont il est membre ; valide les différences et les commandes
Auditeur	lit les journaux et les politiques, en lecture seule, sans accès aux sessions
Agent	aucun compte ; n’accède qu’au bac à sable de la session en cours

Le poste ne détient ni clé ni adresse du moteur

Le poste présente à la passerelle une preuve d’identité qui ne vaut que contre elle : un jeton OIDC émis par votre fournisseur d’identité, vérifié localement contre ses clés publiques. Au moment de relayer un appel de modèle, la passerelle retire les en-têtes authorization et x-api-key de l’appelant, puis pose à la place la clé du moteur d’inférence, lue dans son propre environnement, si le moteur en déclare une. Le poste ne voit pas cette clé, et rien de ce qui part du poste ne permet de la reconstituer.

La clé du moteur n’est pas en base. La base enregistre le nom de la variable d’environnement qui la porte et l’en-tête HTTP dans lequel la déposer ; la valeur reste dans l’environnement du processus. Une copie de la base ne livre donc aucune clé. Une variable absente produit une erreur 500 dont le message nomme la variable manquante.

Retirer un accès

Comme chaque personne a sa propre preuve d’identité, un accès se retire sans toucher aux autres postes. L’administrateur révoque depuis la console, par session ou par utilisateur. La révocation prend effet sans redémarrage, elle est journalisée, et la révocation d’une session détruit son bac à sable (livre blanc sécurité V3, sections 4.5 et 6.1).

La passerelle tient une liste de révocation : un sujet qui y figure est refusé, et le motif reste au journal des décisions. La révocation est contrôlée avant la résolution de l’endpoint, pour qu’un sujet révoqué ne puisse pas sonder par les codes de retour quels endpoints existent. Aucune de ces opérations ne demande de redéployer la passerelle : elle relit la base à chaque requête.

La politique du projet

La politique est écrite par l’administrateur dans la console, évaluée par la passerelle avant chaque action, et n’est pas interprétée par le modèle (livre blanc sécurité V3, section 5.1). Elle fixe les outils actifs, les commandes libres, les commandes soumises à validation et les budgets. Par défaut, aucune commande n’est libre.

Chaque commande est évaluée côté services de la passerelle avant son exécution : un poste ne peut ni contourner la politique ni la désactiver. Toute modification de politique est journalisée, avec l’ancienne valeur, la nouvelle et son auteur. Ce que la politique distingue est décrit dans Les garde-fous d’exécution ; la façon de l’écrire est dans Régler la politique des postes depuis la console.

Le pilotage des sessions

La passerelle ouvre un bac à sable sur l’hôte d’exécution pour chaque session, avec une copie de travail du dépôt, et lui parle par un canal de contrôle unique qu’elle ouvre elle-même. L’hôte d’exécution ne prend pas l’initiative d’une connexion, et aucun flux ne circule dans l’autre sens (livre blanc sécurité V3, sections 3.2 et 3.3). Les étapes d’une session sont décrites dans Le cycle d’une session agentique.

Un seul chemin vers le modèle

Tout ce qui part vers le modèle traverse la passerelle (livre blanc sécurité V3, section 8.2). L’accès au moteur d’inférence est contrôlé au niveau réseau :

• le moteur n’écoute que sur le réseau interne du serveur d’inférence ;
• votre filtrage réseau n’autorise que l’hôte de la passerelle à le joindre ;
• ni les extensions ni les bacs à sable ne connaissent son adresse.

Ce qui en découle pour l’exploitation :

• la règle de pare-feu à écrire pour les postes tient en une destination, la passerelle ;
• un moteur d’inférence se déclare dans la console, et le poste ne change pas de configuration quand vous en changez ;
• aucun composant ne dispose d’une route vers Internet.

La passerelle applique au passage les politiques de l’administrateur, dont la détection de secrets. Celle-ci repose sur des motifs connus (clés de fournisseurs d’infrastructure, jetons d’accès, clés privées, chaînes de connexion) et sur une détection par entropie. La politique fixe la réponse : bloquer, masquer ou alerter. Le blocage est la valeur par défaut. Un secret détecté n’est pas journalisé en clair.

Le journal

La passerelle journalise chaque session : authentification, consigne, fichiers lus et modifiés, actions proposées par l’agent, décisions humaines, exécutions dans le bac à sable, changements de politique (livre blanc sécurité V3, section 7.2). Les journaux sont en ajout seul, chaque entrée contient le condensat de la précédente, et l’export vers votre SIEM suit un schéma d’événements documenté (section 7.1). Par défaut, le journal ne contient ni les requêtes ni le code.

La console montre les actes d’une session dans son onglet Audit ; voir Lire les actes d’une session dans l’onglet Audit.

Les plafonds de dépense

Cette section décrit le profil de construction serverless. Dans l’artefact on-premise, celui qui s’installe dans votre périmètre, la passerelle n’a pas de facturation : le module qui compte la dépense n’est pas dans l’artefact.

En profil serverless, chaque compte porte un plan, et chaque plan porte un plafond mensuel en euros. À chaque requête relayée, la passerelle recalcule la dépense du mois en cours en agrégeant request_logs avec les prix par token des modèles, sur une fenêtre qui commence au premier jour du mois. Dès que la dépense atteint le plafond, la requête est refusée avec un statut 402. Si la base de facturation ne répond pas, la requête est refusée avec un statut 503.

État du compte	Comportement
aucun plan rattaché	refusé, statut 403
plan avec un plafond	refusé au plafond, statut 402
plan sans plafond	pas de refus pour cause de dépense

Après jointure, « aucun plan » et « plan illimité » produisent tous les deux un plafond vide. Seul le rattachement au plan distingue les deux, et ce sont des résultats opposés.

Dans les deux profils, la passerelle écrit une ligne d’usage par requête relayée (sujet, source, modèle, tokens, latence), qui sert à l’exploitation.

L’indirection par endpoint

Le client n’appelle pas un modèle, il appelle un endpoint : un nom que vous publiez et qui désigne un modèle servi par un moteur d’inférence. Quand le corps de la requête est du JSON, la passerelle écrase son champ model par celui de l’endpoint. Un nom d’endpoint décrit un usage, par exemple code-principal ou completion-rapide, et non le modèle du moment.

Rediriger un endpoint vers un autre modèle est donc une modification faite dans la console, qui prend effet sur la requête suivante, sans qu’aucun poste soit reconfiguré. Vous remplacez le modèle quand un meilleur est disponible, et les garanties des sessions restent identiques (livre blanc sécurité V3, section 8.1).

Le chiffrement du trafic entrant

Les flux entre composants sont chiffrés en TLS (livre blanc sécurité V3, section 6.2). La passerelle termine TLS elle-même dès que vous lui donnez un certificat et sa clé, par les variables d’environnement TLS_CERT_FILE et TLS_KEY_FILE. Elle annonce alors au démarrage qu’elle écoute en TLS. Une configuration à moitié posée (une seule des deux variables, ou une paire illisible) est refusée au démarrage.

Sans ces deux variables, elle écoute en clair et l’annonce au démarrage. Ce cas suppose qu’un terminateur TLS placé devant elle chiffre le flux des postes.

Le trajet d’un appel de modèle, de bout en bout

Les sections précédentes décrivent chacune une propriété. L’enchaînement complet montre deux choses : les contrôles ont un ordre, et le refus survient au premier qui échoue.

Quatre choses se lisent sur ce dessin.

• La preuve d’identité qui part du poste n’est pas la clé qui arrive au moteur. Ce sont deux flèches distinctes, et entre elles deux gestes de la passerelle.
• Un endpoint inconnu est refusé tôt. La révocation est contrôlée avant la résolution de l’endpoint.
• Chaque verdict, accordé ou refusé, est tracé dans une table distincte, à l’exception du 404 d’endpoint inconnu. Un accord dont la trace n’a pas pu être écrite devient un refus 503. La ligne d’usage s’écrit après une réponse qui a abouti.
• Les verdicts ne sont pas mis en cache. La base est relue à chaque requête, et un changement fait dans la console prend effet à la requête suivante, sans redémarrage. Restent en mémoire un temps : la découverte OIDC et les clés publiques du fournisseur d’identité, et le compteur de sièges de la licence.

Un code ne figure pas sur le dessin : le 500 d’une variable de clé absente (voir plus haut).

Ce que ce diagramme ne montre pas

• Le plan et le plafond du profil serverless, absents de l’artefact on-premise ; voir Les plafonds de dépense.
• Le contrôle du certificat du moteur, qui a lieu sur la flèche sortante et qu’aucun réglage de la passerelle ne désactive. UPSTREAM_TLS_CA_FILE ajoute une autorité de certification sans en retirer.
• Les autres adresses de la passerelle. Le relais n’est pas la seule : deux adresses d’exécution de commandes d’agent existent, avec la même suite de contrôles et sans inférence ; quatre adresses servent la documentation installée sans authentification ; trois adresses servent l’IDE pour la politique de l’organisation, les actes d’agent et la découverte du fournisseur d’identité. La liste complète est dans Ce que la passerelle ne fait pas.
• Le détail du chemin en flux. Pour un flux, la réponse commence à partir vers le poste avant que la ligne d’usage soit écrite : celle-ci l’est à la fin du flux, en tâche de fond, avec une file de reprise si l’écriture échoue. Le dessin réunit les deux chemins en un.
• Ce qui se passe dans la session avant l’appel. La boucle de l’agent, ce qu’elle demande à l’humain et ce qui la borne, est décrite dans Le cycle d’une session agentique.

Ce que la passerelle ne fait pas

• Elle n’a aucune destination hors de votre périmètre. Ses seules destinations sont l’hôte d’exécution, le moteur d’inférence, votre annuaire et votre SIEM (livre blanc sécurité V3, section 3.3).

• request_logs n’est pas le journal des sessions. La table porte l’horodatage, le sujet, l’endpoint, le modèle, la latence et les tokens : des métadonnées d’usage. Le rôle de base de données de la passerelle ne détient que les droits SELECT et INSERT, et le démarrage refuse un rôle capable de réécrire.

• Elle n’expose ni route de santé, ni route de version. Un superviseur qui attend un /health ne trouve rien.

• Elle expose dix adresses, dont cinq répondent sans authentification. Un exploitant qui dimensionne son pare-feu et un auditeur qui compte les points d’entrée doivent les avoir toutes :

  Adresse	Ce que c’est	Authentification
  POST /_agent-execution/commands	lancer une commande d’agent	oui
  POST /_agent-execution/commands/:id/interrupt	interrompre une commande d’agent	oui
  ALL /v	la racine du segment réservé à la documentation	non
  ALL /v/_search	la recherche dans la documentation installée (GET seul)	non
  ALL /v/_mcp	la même recherche, par le protocole des agents (POST seul)	non
  ALL /v/*	les fichiers de la documentation dépliée (GET seul)	non
  GET /ide/policy	la politique de l’organisation, lue par l’IDE	licence
  POST /ide/acts	les actes d’agent déposés par l’IDE	licence
  GET /ide/identity-discovery	la découverte du fournisseur d’identité	non
  ALL /:endpoint/*	le relais d’inférence, attrape-tout posé en dernier	oui

  Le segment /v sert la documentation que l’exploitant a dépliée à côté de la passerelle : il est en lecture seule, il ne liste aucun répertoire, il n’appelle aucun modèle de langage, et il est ouvert parce que la documentation qu’on vient chercher est souvent celle qui explique comment s’authentifier. Sans documentation configurée, il répond 501. Les adresses /ide/policy et /ide/acts exigent la licence du déploiement dans l’en-tête Authorization. Chaque adresse de relais et de documentation est détaillée dans Référence : le relais de la passerelle.

Trois services

llm-gateway, gateway-db et gateway-admin sont installés sur un même hôte, distinct de l’hôte d’exécution et du serveur d’inférence (livre blanc sécurité V3, section 6). Ils sont séparés parce qu’ils ne courent pas les mêmes risques.

La passerelle est sur le chemin de chaque requête : elle reste petite, et elle détient la clé du moteur d’inférence. La console est un outil d’administration, réservé aux administrateurs, et elle n’a pas à connaître cette clé : elle ne parle qu’à la base. Vous pouvez la restreindre à votre réseau d’administration. La base est le seul état durable, donc le seul objet à sauvegarder.

Le découpage se lit dans les flux : la console n’appelle pas la passerelle, la passerelle n’appelle pas la console. Elles se rencontrent dans la base. Le schéma d’ensemble est dans Architecture.