Galaris : connecter des outils aux agents avec MCP

Blog · Laurent Lécluse · 9 octobre 2026

Un agent devient utile lorsqu’il peut consulter une source, lire un document ou agir dans une application. Chaque connexion pose alors deux questions : quelles fonctions peut-il utiliser, et sur quelles ressources ?

Dans Galaris, je relie les outils à l’identité des agents et aux autorisations de la plateforme. MCP fournit une interface commune pour exposer des fonctions ; les contrôles d’accès restent une responsabilité du logiciel qui les propose.

Un catalogue construit pour l’agent

Les outils natifs sont déclarés dans les modules de Galaris. Une connexion active rattache un outil à un agent ; des réglages par fonction précisent ce qui lui est exposé. Le catalogue effectif tient également compte des capacités du runtime et de la portée éventuelle de la tâche.

Le prompt et la liste d’outils partent de cette même projection d’autorisation. Une fonction non autorisée est omise du catalogue remis à l’agent. Les serveurs MCP externes conservent un espace de noms lié à leur connexion pour éviter les collisions. Ces mécanismes sont décrits dans le guide des packages MCP.

Prenons un exemple pédagogique : un agent chargé d’examiner des dossiers peut avoir besoin de lire leurs pièces, tandis qu’un agent chargé de leur mise à jour dispose aussi de fonctions d’écriture. Cette distinction doit se retrouver dans les fonctions effectivement disponibles et dans les contrôles sur les dossiers concernés.

Vérifier les droits côté serveur

Masquer une commande dans l’interface aide l’utilisateur à comprendre son périmètre. Le contrôle décisif doit aussi avoir lieu côté serveur, au moment où l’opération est demandée.

Dans Galaris, le backend impose les droits par rôles, ou RBAC. Pour certaines commandes MCP d’administration, le serveur revérifie la connexion qui accorde cette capacité, même si la fonction figurait déjà dans le catalogue du runtime. Les lectures et commandes sur les objectifs conservent également leurs contrôles d’appartenance. Ces contrats figurent dans les invariants et le guide développeur.

Cela rend la règle indépendante de la manière dont une demande arrive : un écran, un appel API ou un outil agentique doivent respecter la frontière portée par le service.

La recherche d’outils respecte le même périmètre

Un catalogue peut devenir assez grand pour nécessiter une recherche par pertinence. Cette recherche doit opérer sur les fonctions déjà autorisées.

Galaris applique le filtrage des droits avant la découverte sémantique des outils. Le planner conserve l’inventaire des noms autorisés ; le classement lui apporte ensuite du détail sur les fonctions pertinentes. Un index vectoriel ou un score de proximité n’accorde aucun droit supplémentaire. Cette règle est l’invariant INV-26.

Le même principe est utile dans une recherche documentaire métier : calculer la pertinence dans le périmètre accessible, puis présenter les résultats qui répondent à la question.

Un exemple concret : le navigateur agentique

Le navigateur de Galaris illustre l’articulation entre intégration, droits et isolation. L’agent appelle des fonctions MCP ; le backend valide la demande et contacte un exécuteur distinct qui pilote Chromium.

Chaque session possède un contexte de navigateur isolé, associé à l’agent et à la tâche. Les contextes ne partagent ni cookies, ni cache, ni stockage local. Une autre tâche du même agent ne peut pas reprendre cette session. Le flux du navigateur décrit ces frontières.

Cette isolation traite un risque concret : une connexion ouverte pour une mission ne doit pas devenir implicitement disponible à une autre mission. Le conteneur d’exécution apporte une séparation supplémentaire, avec ses propres limites de ressources.

Encadrer les destinations et les actions réseau

Une fonction de navigation peut aussi atteindre des services internes ou soumettre un formulaire. Galaris fait passer les requêtes du navigateur par un proxy qui consulte l’autorisation côté backend. La connexion de l’agent porte les règles de destination, d’accès aux réseaux locaux et de méthodes HTTP nécessitant une permission.

Les interdictions de configuration sont examinées avant les permissions. Une indisponibilité du contrôle bloque la requête. Lorsqu’une action attend un accord, la décision est conservée ; l’action bloquée doit ensuite être retentée explicitement. Elle n’est pas rejouée automatiquement à la réception de la réponse. Ces règles sont détaillées dans le contrôle réseau du navigateur.

Pour un cas pédagogique de formulaire externe, cela oblige à vérifier l’état de la page avant une nouvelle soumission. L’accord humain autorise l’action ; il ne prouve pas qu’une tentative précédente a échoué sans effet.

Ce que je transpose à vos intégrations

Relier un logiciel à un service externe demande de définir les fonctions utiles, les droits, la portée des données et les conséquences d’une interruption. Le protocole facilite l’échange ; les contrats métier donnent son sens à chaque opération.

Avec Galaris, je travaille cette frontière jusqu’au contrôle serveur et à l’isolation d’exécution. C’est une pratique directement applicable à une connexion entre applications, une automatisation documentaire ou un assistant interne.

Revenir à la stack de Galaris · Comprendre la reprise des missions · Parlons de vos intégrations

Repère technique : sources publiques au commit 7e7bdea8, consultées le 9 octobre 2026. Les exemples sont pédagogiques ; les accès effectifs dépendent des connexions et de la configuration de l’instance.