google/mantis : des skills de revue de sécurité pour agents de codage, à manipuler avec précaution

Un orchestrateur de skills, pas un scanner

Mantis ne détecte pas les vulnérabilités lui-même. Le dépôt se présente comme un ensemble de skills destinés à un agent de codage, c'est-à-dire des instructions que l'agent lit et exécute dans votre terminal. Le problème visé est celui de la revue de sécurité assistée par IA : un agent sait lire du code, mais sans cadre il improvise, mélange les étapes et produit des rapports invérifiables. Mantis fournit ce cadre sous forme de commandes slash, par exemple /mantis-plan, /mantis-reproduce et /mantis-patch, que l'opérateur tape une par une. La cible est donc l'équipe sécurité applicative ou matérielle qui possède déjà un agent de codage et veut structurer une campagne de revue, pas le développeur qui cherche un linter de plus. Le README précise que l'ensemble est « a starting point rather than a rigid set of instructions » et invite à l'adapter à sa propre pile logicielle ou matérielle, y compris pour du RTL, de l'Infrastructure as Code ou des pipelines ML.

Le pipeline séquentiel et ses contrats entre étapes

L'architecture décrite est séquentielle et découplée : chaque skill correspond à une étape, et le README renvoie au fichier README_AGENTS.md pour le détail des étapes, du flux et des contrats inter-étapes. Trois noms de skills reviennent dans le matériel fourni : planification, reproduction, correction. La reproduction et la correction sont les étapes qui exécutent du code, et c'est là que le dépôt place ses avertissements les plus forts. Le README indique que ces deux skills sont explicitement instruits d'exécuter les charges utiles dans des conteneurs isolés avec le réseau désactivé, par exemple --network none. Il ajoute aussitôt que l'agent reste non déterministe et peut, selon la formulation du dépôt, contourner les contraintes prévues si l'environnement local le permet. Autrement dit, l'isolation est une instruction donnée au modèle, pas une garantie technique imposée par Mantis. Cette distinction est le point le plus important du projet : la barrière de sécurité vient de votre infrastructure, pas du code de Mantis.

Mise en route : npx, Docker et gVisor

L'installation se fait par une seule commande, documentée dans le README : npx skills add google/mantis. Le prérequis est un environnement CLI configuré, sans recommandation de logiciel particulier puisque le projet se veut agnostique. Le dépôt cite Gemini CLI et Antigravity CLI comme environnements utilisés, et mentionne les SDK Google ADK et Antigravity. Pour l'exécution des charges générées, le README liste Docker pour les conteneurs de test et gVisor pour renforcer l'isolation. L'installation de gVisor y est donnée sous la forme sudo runsc install -- --network=none && sudo systemctl restart docker, avec une alternative : déclarer le runtime dans /etc/docker/daemon.json sous la clé runtimes, avec runsc comme chemin et runtimeArgs contenant --network=none. Le README recommande enfin de démarrer en mode interactif, en tapant les commandes slash une à une et sans les drapeaux --yolo ou --dangerously-skip-permissions, afin que l'agent demande une approbation humaine avant toute écriture de fichier ou exécution de code.

Faux positifs et règle du filtre négatif

Le dépôt consacre une section aux faux positifs et annonce la couleur : attendez-vous à du bruit. La réponse proposée est un filtre négatif appliqué à l'étape de revue, dont les règles se personnalisent dans /mantis-review. Cette conception part du principe que l'agent produit d'abord un volume de candidats, puis qu'une passe de validation élimine ce qui ne tient pas. Le README est clair sur un point qui va contre l'intuition : l'échec d'une reproduction automatique ne signifie pas que la vulnérabilité est un faux positif, et une reproduction réussie ne garantit pas que le bug soit exploitable dans tous les contextes. Toute conclusion doit donc être vérifiée manuellement par un expert avant d'être rapportée, et le dépôt déconseille explicitement d'ouvrir en masse des rapports générés par IA auprès de mainteneurs de projets open source. C'est une position honnête, mais elle déplace une charge de travail réelle vers l'équipe qui adopte l'outil.

Ce que Mantis ne fait pas, et ce qui l'entoure

Le cas où Mantis est le mauvais outil est celui d'une intégration en CI sans supervision. Rien dans le matériel fourni ne décrit un mode non interactif durci, et le README insiste au contraire sur l'approbation humaine à chaque étape sensible. Un pipeline qui lancerait /mantis-patch automatiquement sur une branche de production irait directement contre les recommandations du dépôt. Autre limite : l'absence de release publiée dans les données récupérées, ce qui rend difficile de raisonner en termes de versions stables. Sur le plan des alternatives, un outil comme Semgrep suit une logique opposée : des règles écrites à l'avance, exécutées de façon déterministe, qui produisent des correspondances reproductibles sans exécuter de code. Mantis mise sur un agent qui explore, propose et tente de reproduire, ce qui couvre des cas hors du champ des règles statiques, au prix d'un résultat non déterministe et d'une infrastructure d'isolation à sa charge. Les deux approches ne s'excluent pas, mais elles n'ont ni le même coût d'exploitation ni le même type de preuve à l'arrivée.

Coût de maintenance et licence

La maintenance d'un tel ensemble se joue sur deux fronts. D'abord les skills eux-mêmes : le README recommande de les adapter, de les calibrer au risque de son environnement et de les faire évoluer avec l'aide d'une IA, ce qui suppose de versionner ses propres variantes plutôt que de consommer le dépôt tel quel. Ensuite l'environnement d'exécution : gVisor, Docker et les SDK cloud doivent rester à jour, car c'est d'eux que vient la barrière de sécurité. Le dépôt est publié sous Apache-2.0, licence permissive qui autorise la modification et la redistribution, avec les obligations habituelles de conservation des mentions et de l'avis de licence, et sans garantie de la part des auteurs. Ce dernier point compte ici plus qu'ailleurs : le README avertit que l'agent peut générer du code instable ou effectuer des actions inattendues, et qu'il faut l'utiliser uniquement dans des environnements isolés et restreints. Aucune release n'apparaissant dans les données consultées, prévoyez de suivre la branche main et de relire les skills avant chaque mise à jour.

Conclusion éditoriale

Mantis convient aux équipes sécurité qui disposent déjà d'une VM isolée, d'un agent de codage configuré et d'un expert humain pour trier les résultats. Il ne convient pas à celles qui cherchent un scanner SAST à brancher sur une CI sans surveillance. Avant tout essai, vérifiez deux points : que votre agent déclenche bien une approbation humaine sur /mantis-reproduce et /mantis-patch, et que le runtime runsc avec --network=none est réellement enregistré dans /etc/docker/daemon.json.

Sources officielles

1. google/mantis on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README