Intégrer Lemniscate à votre stack

Lemniscate fournit l’environnement d’exécution confiné des agents de code, déployé dans votre périmètre. Cette page s’adresse à une équipe qui dispose déjà d’un agent de code (OpenCode, un outil maison), d’un proxy de modèles (LiteLLM) et d’un moteur d’inférence, et qui veut autoriser cet agent sur un périmètre sensible. Lemniscate se pose à côté de cette stack et y ajoute l’exécution confinée, les politiques, le journal et la révocation (livre blanc sécurité V3, section 3.4).

Si rien n’est en place chez vous, le parcours qui vous concerne est Installer l’assistant de code complet.

Ce que vous gardez

• Votre agent. Il continue de porter la boucle de travail : lire la consigne du développeur, interroger le modèle, proposer des modifications et des commandes.
• Votre proxy de modèles et votre moteur d’inférence. La passerelle se raccorde à tout moteur qui expose une API compatible OpenAI, avec le modèle à poids ouverts que vous avez retenu. Le choix du modèle, la provenance de ses poids et sa mise à jour restent de votre ressort (livre blanc sécurité V3, sections 3.4 et 11.1).
• Votre annuaire et votre SIEM. Lemniscate ne gère pas d’identités : l’authentification passe par le fournisseur d’identité de votre organisation (OpenID Connect), ou par des comptes locaux dans un environnement isolé. Les journaux s’exportent vers votre SIEM (livre blanc sécurité V3, sections 6.1 et 7.1).
• Vos dépôts et vos circuits de revue. L’agent n’a pas de compte sur la forge et ne pousse rien. Le développeur intègre la différence validée sous sa propre identité, par ses outils habituels (livre blanc sécurité V3, section 4.3).

Ce que Lemniscate ajoute

Deux éléments s’installent chez vous, chacun sur sa machine.

Les services de la passerelle, sur un hôte Linux : la passerelle, sa base et la console d’administration. La passerelle authentifie, applique la politique du projet, pilote la session, journalise et révoque. Elle est le seul composant qui parle à tous les autres.

L’hôte d’exécution, distinct de l’hôte de la passerelle : il porte un bac à sable par session, créé à la demande et détruit à la fin, sans interface réseau, avec une copie de travail du dépôt comme seul volume en écriture. Il ne conserve aucun état entre deux sessions et n’accepte qu’un canal de contrôle entrant, ouvert par la passerelle.

Ces deux éléments tiennent les sept garanties de session, quel que soit l’agent et quel que soit le modèle (livre blanc sécurité V3, section 4.1) :

Garantie	Ce qu’elle borne
G01	Le périmètre : la copie du dépôt autorisé par la politique du projet.
G02	Les écritures : chaque écriture retenue est validée par un humain, en différence.
G03	Les commandes : la politique de l’administrateur, appliquée par la passerelle.
G04	L’exécution : un bac à sable jetable.
G05	Le réseau : aucune destination accessible, ni externe ni interne.
G06	La traçabilité : consigne, actions proposées, décisions, résultats.
G07	L’arrêt par le développeur et la révocation par l’administrateur, à tout moment.

Votre agent et votre modèle restent hors du périmètre de confiance : ils proposent, et ce sont la passerelle et le bac à sable qui tiennent les droits (livre blanc sécurité V3, sections 3.1 et 8.1).

Ce qui se raccorde à quoi

L’intégration consiste à faire passer par la passerelle les deux choses que votre agent fait hors de lui-même : parler au modèle, et agir sur le code.

De	Vers	Ce qui circule
L’agent	La passerelle	Les échanges avec le modèle, et les actions à exécuter dans le bac à sable.
La passerelle	Votre proxy ou votre moteur	Les requêtes d’inférence, en TLS. Seul l’hôte de la passerelle joint le moteur.
La passerelle	L’hôte d’exécution	Un canal de contrôle unique, ouvert par la passerelle.
La passerelle	Votre annuaire et votre SIEM	L’authentification et l’export des journaux.
Le bac à sable	Aucun réseau	Rien : ni interface réseau, ni résolution de noms.

Cette matrice reprend celle du livre blanc sécurité V3, section 3.3. Elle ne contient aucun flux sortant de votre périmètre.

Les échanges avec le modèle

Ce raccordement a une procédure sur ce site. Il tient en deux déclarations.

Côté passerelle, vous déclarez votre proxy ou votre moteur comme fournisseur dans la console d’administration : son adresse, et le nom de la variable d’environnement qui porte sa clé. La passerelle ne stocke pas la clé, elle la lit dans son propre environnement au moment de relayer. Vous déclarez ensuite le modèle, puis le point d’appel qui le route. La marche à suivre est dans Déclarer un modèle servi par la passerelle.

Côté agent, vous remplacez l’adresse du proxy par celle de la passerelle, suivie du nom du point d’appel. La passerelle retire ce premier segment et concatène le reste du chemin derrière l’adresse de votre fournisseur : votre agent continue de parler le dialecte de votre moteur. Il s’authentifie avec la clé du compte de son utilisateur, et ne détient plus la clé du moteur. L’interface sur laquelle un programme tiers peut s’appuyer est décrite dans Le relais de la passerelle.

Chaque appel est alors rattaché à un utilisateur et inscrit en base. Ce que ce détour apporte est décrit dans Le rôle de la passerelle.

Les actions sur le code

La cible est la suivante. Votre agent n’exécute plus rien sur le poste du développeur ni sur la machine où il s’exécute lui-même. Pour chaque session, la passerelle charge la politique du projet et ouvre un bac à sable sur l’hôte d’exécution, avec une copie de travail du dépôt. Les lectures, les écritures et les commandes que l’agent propose y sont exécutées, après évaluation par la passerelle. Le résultat revient au développeur sous forme de différence, qu’il accepte ou refuse (livre blanc sécurité V3, section 3.2).

Ce raccordement n’a pas de procédure publiée sur ce site. Le protocole par lequel la passerelle reçoit une commande à exécuter est celui des extensions Lemniscate, et il n’est pas une interface sur laquelle un programme tiers peut s’appuyer. Le branchement d’un agent tiers se prépare avec l’éditeur, sur un premier déploiement restreint à une équipe et un dépôt (livre blanc sécurité V3, section 12).

Les politiques, le journal et la révocation

Ces trois fonctions vivent dans les services de la passerelle et ne demandent rien à votre agent.

• La politique de projet est écrite par l’administrateur dans la console : outils actifs, commandes libres, commandes soumises à validation, budgets. Par défaut, aucune commande n’est libre. La passerelle évalue chaque action avant son exécution, et le modèle ne lit jamais la politique comme une consigne (livre blanc sécurité V3, section 5.1).
• Le journal est en ajout seul. Il reconstitue une session : qui s’est authentifié, quelle consigne a été donnée, ce que l’agent a proposé, ce que le développeur a décidé, ce qui s’est exécuté. Le contenu du code et des échanges en est absent par défaut (livre blanc sécurité V3, sections 7.1 et 7.2).
• La révocation se fait depuis la console, par session ou par utilisateur. Elle prend effet sans redémarrage, détruit le bac à sable et laisse une trace au journal (livre blanc sécurité V3, section 4.5).

Ce qu’il faut de votre côté

• Un hôte Linux pour les services de la passerelle, et un hôte d’exécution distinct. Sur un socle qui admet un moteur de conteneurs sur les postes, le bac à sable peut s’exécuter sur le poste : c’est la variante, l’hôte dédié étant le mode de référence (livre blanc sécurité V3, section 4.4).
• Un moteur d’inférence, ou un proxy placé devant lui, qui expose une API compatible OpenAI et que l’hôte de la passerelle peut joindre.
• Un filtrage réseau qui n’autorise que l’hôte de la passerelle à joindre le moteur et l’hôte d’exécution. Cette règle est la vôtre ; la matrice ci-dessus vous permet de la vérifier avec vos propres sondes (livre blanc sécurité V3, section 11.5).
• Un fournisseur d’identité OpenID Connect, ou la décision d’utiliser des comptes locaux.
• Un agent dont l’adresse du service de modèles se règle.

Le même produit se déploie en mode connecté, isolé, sensible ou classifié. En mode isolé, il est livré sur média, sous forme d’archive signée, et fonctionne sans aucune connexion à l’éditeur (livre blanc sécurité V3, sections 3.4 et 9.3).

Pour continuer

• Découvrir la passerelle : monter les trois services sur un poste et y router un premier appel, pour voir comment ils s’articulent.
• Architecture : les quatre rôles et leurs zones de confiance.
• Le cycle d’une session agentique : ce qui se passe entre la consigne et la différence.
• Vérifier qu’aucune donnée ne sort : la vérification que votre responsable de la sécurité conduit sur les artefacts livrés.