GateRook vérifie les requêtes des agents IA en 3 étapes avant tout accès à l’infrastructure

Donner à un agent IA un terminal et le mot de passe d’une base de données permet d’éliminer rapidement la copie manuelle des journaux. C’est aussi un moyen rapide de perdre le contrôle sur ce que l’agent a précisément lu ou modifié. Une phrase comme « ne touche jamais à la production » dans le prompt constitue ici une faible protection : le modèle peut se tromper d’environnement, mal interpréter une instruction découverte ou envoyer un SQL correct à la mauvaise base de données.

GateRook propose de déplacer le contrôle vers une couche d’exécution distincte, située entre le client IA et l’infrastructure. Il s’agit d’une application de bureau locale comprenant une passerelle MCP, des connecteurs vers les bases de données, les journaux, les API et les serveurs, des politiques d’accès et un journal unifié des appels. Le projet est distribué sous licence Apache 2.0. Toutefois, l’article a été rédigé par son auteur : les affirmations concernant ses capacités doivent donc être considérées comme une démonstration de la conception du produit, et non comme un audit de sécurité indépendant.

Pas un terminal, mais un outil spécialisé

Au lieu d’un accès SSH arbitraire, l’agent reçoit, par exemple, un outil de recherche dans les journaux. La requête précise explicitement la connexion, le fichier, la chaîne recherchée, la période, le volume maximal à analyser et le nombre de lignes à renvoyer. L’agent peut vérifier une hypothèse sans pour autant obtenir une ligne de commande universelle.

Un tel contrat est plus utile qu’une autorisation générale permettant de « consulter le serveur ». Le propriétaire voit les arguments réels de l’appel, le secret SSH n’apparaît pas dans la conversation et le volume de lecture est limité à l’avance. Pour les opérations répétitives, des commandes de runbook dotées de paramètres typés sont prévues. Mais l’enveloppe ne garantit rien à elle seule : une commande dangereuse intégrée au runbook restera dangereuse.

Les ressources sont réparties en trois entités. Le Connector décrit la manière de travailler avec MySQL, MongoDB, Redis, SSH ou un autre type de système. La Connection conserve les paramètres d’une ressource précise ainsi que son environnement. L’Endpoint détermine les connexions et les outils visibles par un client IA donné. Les environnements de développement et de production peuvent ainsi être séparés par des points d’entrée différents, sans dépendre de la vigilance du modèle.

Pourquoi une seule approbation ne suffit pas

Un exemple révélateur est celui d’un SELECT ne précisant pas explicitement la base de données. La requête elle-même est sûre du point de vue du type d’opération, mais la connexion donne accès à deux bases. GateRook rejette l’appel avant qu’il n’atteigne le SGBD et en indique la raison : aucune base n’a été sélectionnée. Le « j’approuve » de l’utilisateur ne supprime pas cette condition obligatoire.

Le processus est plus strict pour les écritures. L’agent propose un UPDATE, la passerelle le classe comme une modification et crée une demande de confirmation temporaire. L’humain voit le SQL exact, la connexion, l’environnement et une estimation de l’impact. Après approbation, le noyau vérifie à nouveau la configuration et exécute la requête enregistrée. L’agent ne peut pas remplacer le SQL déjà approuvé par une autre expression.

C’est un détail architectural important : l’autorisation n’est pas liée au nom de l’outil, mais au contenu précis de l’opération. Si l’utilisateur ne répond pas à temps, la demande expire. Si le résultat de l’écriture est inconnu en raison d’un délai d’attente dépassé, la mutation ne doit pas être automatiquement relancée : l’absence de réponse ne signifie pas que la base de données n’a subi aucune modification.

Ce qu’il faut reprendre dans son propre système

La valeur pratique de GateRook ne réside pas uniquement dans l’application prête à l’emploi. C’est un modèle pertinent pour toute infrastructure ouverte aux agents : fournir des outils spécialisés plutôt qu’un shell, séparer les environnements, interdire les requêtes ambiguës, faire confirmer un payload immuable et journaliser la décision avec son résultat.

La passerelle ne remplace toutefois pas les droits propres à l’infrastructure. La production doit être lue au moyen d’un compte distinct doté de grants minimaux, tandis que les écritures doivent être limitées au niveau du SGBD, de l’API et du serveur. Le stockage local des secrets ne signifie pas non plus que les données ne quittent jamais l’ordinateur : les résultats des requêtes autorisées sont transmis au client IA et, éventuellement, au fournisseur du modèle. Il faut donc prévoir du masquage, des limites de sortie et une politique claire de conservation des journaux.

Pour les développeurs, la principale conclusion est simple : le contrôle d’accès des agents ne doit pas rester enfermé dans le texte du prompt. Pour le produit, l’interface de confirmation doit montrer l’action et ses conséquences, et non un bouton Allow impersonnel. GateRook illustre cette approche de manière convaincante, même si une vérification indépendante de l’implémentation, du modèle de menaces et des garanties annoncées reste nécessaire.