HOL Guard : un antivirus open source pour agents d’IA contre les serveurs MCP et compétences malveillants
HOL Guard, de hashgraph-online, est une couche de sécurité locale pour agents d’IA. Elle examine commandes shell, fichiers, paquets et appels MCP avant exécution, repère secrets, injection de prompt et risques de chaîne, puis autorise ou bloque.
Les agents d’IA quittent la fenêtre de discussion. Au cours de l’année écoulée, les assistants de programmation ont appris à exécuter des commandes shell, à lire et écrire des fichiers locaux, à installer des dépendances et à appeler des outils externes via des serveurs Model Context Protocol (MCP). Cette montée en puissance pose une question simple et incisive : lorsqu’un programme que l’on peut orienter par une simple invite détient les droits de votre terminal, qui garde la porte ? HOL Guard, projet open source de hashgraph-online, répond par un positionnement sans détour : un antivirus open source pour agents d’IA. Il ne cherche pas à rendre le modèle plus docile. Il place devant chaque action une couche locale, indépendante du modèle, qui examine l’action avant qu’elle ne s’exécute. L’idée s’inscrit dans la lignée de la défense en couches des postes de travail ; seul l’objet inspecté change, du fichier exécutable à chaque geste de l’agent. Le principe de fonctionnement est l’examen avant exécution. Les actions visées sont les commandes shell, les accès aux fichiers, les installations de paquets et les appels d’outils MCP. Les risques recherchés sont l’exposition de secrets, les opérations destructrices, l’injection de prompt et les menaces de chaîne d’approvisionnement. Selon la politique définie par l’utilisateur, l’outil autorise l’action, la bloque ou demande une approbation. La documentation du projet range la surface protégée en six familles : commandes shell et accès aux fichiers, installations de paquets, plugins, compétences et configuration des agents, serveurs et outils MCP, invites et résultats d’outils, enfin approbations et preuves. La dernière famille mérite l’attention. Chaque décision laisse un reçu local, et l’historique se consulte en ligne de commande comme dans un tableau de bord local. Une décision de sécurité cesse d’être une fenêtre contextuelle éphémère pour devenir une trace que l’on peut réexaminer, ce qui aide aussi bien l’analyse d’incident que l’ajustement des politiques.
Sur le plan architectural, HOL Guard assume une approche locale d’abord. Il fonctionne sans compte et se branche aux agents de trois façons : les hooks natifs que chaque agent expose, des proxys MCP gérés, et des intégrations au lancement. La documentation reconnaît sans détour que la couverture dépend des événements exposés par chaque agent, et elle tient une matrice de prise en charge qui consigne, pour chaque intégration, le niveau d’application, la remise des approbations et le comportement en cas d’échec. Cette franchise est en soi une qualité d’ingénierie. L’état le plus dangereux pour un outil de sécurité est celui où l’utilisateur se croit pleinement protégé alors qu’une catégorie entière d’événements n’offre aucun point d’accroche. Pour les plugins, les compétences et la configuration, Guard dresse l’inventaire des artefacts locaux et examine tout élément nouveau ou modifié avant son lancement. Cela vise une menace apparue à plusieurs reprises ces derniers mois : des compétences malveillantes et des serveurs MCP empoisonnés, inoffensifs en apparence jusqu’au moment où un agent les charge.
Le seuil d’adoption est bas. Il faut Python 3.10 ou plus récent et pipx. Après pipx install hol-guard, l’utilisateur lance hol-guard init. L’assistant de premier lancement repère les agents pris en charge sur la machine et demande confirmation avant chaque changement, qu’il s’agisse d’ouvrir le tableau de bord, d’installer les intégrations ou de se connecter à des services cloud facultatifs. La liste des agents pris en charge est longue : Codex, Claude Code, GitHub Copilot CLI, Cursor, Cline, Gemini CLI, Grok, Hermes, Kimi Code, Pi, OpenClaw, OpenCode, Antigravity, Devin et d’autres, Paseo étant couvert par l’intermédiaire de ses fournisseurs natifs. Les équipes qui ont besoin de davantage peuvent recourir à Guard Cloud, facultatif, qui ajoute historique partagé, politique d’équipe et gestion de flotte. Le même dépôt fournit aussi un analyseur de plugins, publié sous le nom plugin-scanner, qui inspecte une extension avant son installation. Une évaluation honnête doit aussi nommer les limites. Premièrement, l’analogie avec l’antivirus est une commodité de communication, pas une équivalence technique. L’antivirus classique s’appuie sur des signatures et la surveillance du comportement, alors que le risque propre aux agents naît au niveau sémantique. La détection d’injection de prompt est probabiliste par nature : zéro oubli est impossible. Deuxièmement, la couverture des hooks fixe le plafond. Un événement que l’agent n’expose pas est un événement que Guard ne voit pas. Troisièmement, les flux d’approbation engendrent de la lassitude. Une politique trop lâche devient décorative, une politique trop stricte finit désactivée. Quatrièmement, les verdicts de chaîne d’approvisionnement dépendent de la qualité et de la fraîcheur du renseignement externe. Rien de tout cela n’est un défaut : ce sont des contraintes que subit tout outil de cette catégorie. L’essentiel est de savoir si le projet les expose honnêtement dans sa documentation. D’après le matériel public, c’est le cas. Il affiche en outre les signes habituels de rigueur : licence Apache-2.0, intégration continue, image de conteneur et badge OpenSSF Scorecard.
Notre conseil pratique est de traiter Guard comme une couche de la défense en profondeur, jamais comme la seule. Un développeur isolé peut l’activer sur l’agent qu’il utilise le plus, observer le journal des blocages pendant une semaine, puis durcir sa politique par paliers. Une équipe conservera l’isolation des secrets, le moindre privilège et le cloisonnement, et laissera Guard fournir un point de contrôle auditable avant l’action. À plus long terme, la sécurité des agents quitte le terrain de l’alignement des modèles pour rejoindre un problème de type système d’exploitation, celui des permissions et de l’audit. L’intérêt de HOL Guard est de transformer ce basculement en un outil concret, installable aujourd’hui, dont on relit les journaux demain. C’est plus proche d’une sécurité utilisable que n’importe quel appel abstrait à la vigilance.
Sources
FAQ
Qu’est-ce que HOL Guard, et faut-il un compte ?
C’est une couche de sécurité locale d’abord pour agents d’IA, publiée en open source par hashgraph-online. Elle examine les commandes shell, les accès aux fichiers, les installations de paquets et les appels d’outils MCP avant leur exécution. Elle fonctionne en local sans compte, et la ligne de commande comme le tableau de bord local gèrent la protection, les approbations et l’historique. Guard Cloud est facultatif et ajoute historique partagé, politique d’équipe et gestion de flotte.
Comment se branche-t-il aux agents, et la couverture est-elle complète ?
Il s’appuie sur les hooks natifs des agents, des proxys MCP gérés et des intégrations au lancement. La couverture dépend des événements que chaque agent expose : on ne peut donc pas la supposer complète. La matrice de prise en charge officielle consigne l’application, la remise des approbations et le comportement en cas d’échec pour chaque intégration. Lisez-la avant le déploiement.
Comment l’installer et le mettre à jour ?
Il faut Python 3.10 ou plus récent et pipx. Lancez pipx install hol-guard, puis hol-guard init. L’assistant de premier lancement repère les agents pris en charge et demande confirmation avant chaque changement. Utilisez hol-guard status pour vérifier l’installation et hol-guard update pour la mise à jour.