Failproof AI : journaliser et bloquer les appels d'outils de douze harnais d'agents

Le trou que comble un intercepteur placé sur le harnais

Un agent de codage exécute des appels d'outils : lire un fichier, écrire dans un dépôt, lancer une commande shell, ouvrir une requête réseau. Ces appels partent du harnais, pas de votre code applicatif. Selon le README, Failproof s'installe à ce niveau et capture chaque exécution, ce qui permet de reconstituer une session après coup. La partie qui distingue le projet d'un simple collecteur de traces est le blocage : le README écrit que l'outil peut refuser un appel dangereux avant qu'il ne s'exécute. Le public visé est donc celui qui fait tourner des agents avec un accès réel au système de fichiers ou au shell, et qui veut une trace exploitable plus un garde-fou actif. Le README cite douze harnais, répartis en dix CLI de codage et deux passerelles d'assistant, Hermes et OpenClaw. Les événements, les politiques et l'historique de session sont présentés comme identiques quel que soit le harnais, ce qui évite de réécrire les règles à chaque changement d'outil.

Ce que le dépôt laisse voir de l'architecture

Le README ne détaille pas le chemin d'un événement, du harnais jusqu'au stockage. Il indique seulement que le produit s'exécute localement, qu'un tableau de bord local existe et qu'aucun compte n'est requis, avec en complément une offre cloud gratuite qualifiée de généreuse. La page d'accueil renvoie à docs.befailproof.ai pour la référence. Pour les agents qui n'appartiennent à aucun des douze harnais, la documentation mentionne un SDK Python qui fournit le traçage, les sessions et les audits. La conséquence est nette : sans harnais pris en charge, vous obtenez de l'observation, pas de l'application de politiques. Le README est explicite sur ce point et propose de cartographier un hook sur votre runtime après prise de contact. Le dépôt est par ailleurs écrit majoritairement en MDX selon les métadonnées, ce qui suggère que la documentation pèse plus lourd que le code dans l'arborescence visible, sans qu'on puisse en déduire la répartition réelle des sources.

Installation et premiers réglages

Le README ouvre une section Install avec la commande npm, puis la coupe. Le paquet publié s'appelle failproofai sur le registre npm, et le badge de version pointe vers cette page. Le reste de la procédure, les clés de configuration et le lancement du tableau de bord ne figurent pas dans l'extrait fourni : il faut passer par docs.befailproof.ai. Un lecteur qui cherche un fichier de configuration précis, du type .failproofrc ou une entrée dans package.json, ne le trouvera pas ici. C'est une lacune de l'extrait, pas nécessairement du produit, mais elle empêche de juger la friction d'installation. Le seul élément concret disponible côté intégration est la piste du SDK Python pour les agents non couverts, avec un contact par courriel pour le volet application des politiques. Autrement dit, prévoyez de lire la documentation en ligne avant de promettre un déploiement à votre équipe.

Les politiques intégrées et la question du faux positif

Le README annonce 39 politiques intégrées dans le corps du texte, tandis que la description du dépôt en compte 40. Cet écart d'une unité n'est pas anodin pour qui doit documenter un inventaire de contrôles : il faut compter soi-même dans l'interface ou dans la documentation avant de citer un chiffre. Le principe même d'une politique qui bloque un appel d'outil crée un risque de faux positif. Une règle trop large sur l'écriture de fichiers ou sur les commandes shell arrête un agent légitime en pleine tâche, et l'utilisateur découvre la règle au moment où le travail échoue. Le README ne décrit pas de mode observation seule, ni de journal des refus permettant de mesurer combien de blocages étaient justifiés. C'est le point que je vérifierais en premier : existe-t-il un moyen d'enregistrer les décisions sans les appliquer, pour calibrer les politiques sur un dépôt réel avant de passer en mode bloquant. La promesse de latence nulle figure dans le README, sans méthode de mesure associée, donc à traiter comme une affirmation marketing tant que vous ne l'avez pas observée vous-même.

Quand le harnais devient le mauvais point d'ancrage

Le modèle repose sur le harnais. Si votre agent est un service que vous avez écrit, qui appelle un modèle via une API et exécute ses propres outils, aucun des douze points d'ancrage ne s'applique. Le SDK Python vous donnera des traces, des sessions et des audits, mais pas le refus avant exécution, puisque celui-ci doit venir d'un hook dans votre runtime. Dans ce cas, la valeur du projet se réduit à de l'observabilité, terrain où les bibliothèques de traçage génériques sont déjà installées chez beaucoup d'équipes. Autre cas défavorable : une organisation qui interdit toute dépendance à un service cloud, même en offre gratuite. Le README insiste sur l'exécution locale et l'absence de compte, ce qui couvre probablement ce besoin, mais l'existence d'une offre cloud dans le même produit demande une vérification de ce qui sort de la machine par défaut. Enfin, un agent qui n'exécute aucun outil sensible n'a rien à bloquer : la couche d'interception n'apporte alors que du journal.

Face à un proxy qui filtre les appels de modèle

Une alternative répandue consiste à placer une passerelle entre l'agent et le fournisseur de modèle, du type proxy LLM, qui journalise les requêtes et applique des règles sur les entrées et les sorties. La différence d'approche est structurelle. Le proxy voit du texte : prompts, réponses, éventuellement paramètres d'appel. Failproof se place sur le harnais et voit des appels d'outils, donc des intentions d'action comme écrire un fichier ou lancer une commande. Un proxy peut refuser une réponse contenant une instruction indésirable, mais il ne peut pas empêcher l'exécution d'une commande shell déjà décidée par l'agent, parce que cette exécution se produit en aval de la passerelle. Inversement, un proxy couvre tous les agents qui passent par lui, quel que soit leur harnais, alors que Failproof exige un harnais de sa liste. Les deux couches ne se remplacent donc pas : l'une filtre ce qui entre et sort du modèle, l'autre intercepte ce que l'agent fait de la réponse. Choisir dépend de l'endroit où vous voulez placer le contrôle.

Licence, versions et coût de suivi

Le badge du README indique MIT plus Commons Clause, et le champ licence du dépôt renvoie NOASSERTION, ce qui signifie que l'outil d'analyse n'a pas su classer le fichier LICENSE. La Commons Clause restreint en général la revente du logiciel ; la portée exacte dépend du texte du fichier, que je n'ai pas. À lire avant toute redistribution ou intégration dans un produit commercial, sans se fier au seul badge. Côté versions, la branche par défaut est main et les publications récentes montrent une cadence rapprochée : v1.0.4-beta.2 le 8 septembre 2026, v1.0.4-beta.4 le 9 septembre 2026, et un paquet distinct failproofai-sdk en 0.0.1b2. Le suffixe beta sur la ligne 1.0.4 et le 0.0.1 du SDK indiquent une interface encore mouvante, en particulier du côté Python. Un déploiement qui épingle une version devra donc prévoir des mises à jour de politiques à chaque montée, puisque le nombre de politiques intégrées fait partie du produit et bouge avec lui.

Conclusion éditoriale

Failproof AI convient aux équipes qui font déjà tourner leurs agents dans les douze harnais pris en charge et qui veulent une couche d'interception avant les appels d'outils, sans héberger de service. Il ne convient pas si vos agents vivent dans un runtime maison : le README précise que l'application des politiques y exige un hook écrit par vous, et le SDK Python ne fournit alors que la trace, les sessions et les audits. Avant d'adopter, vérifiez le fichier LICENSE pour la teneur exacte de la Commons Clause, puis listez les politiques que vous allez réellement activer, puisque la documentation en annonce 39 tandis que la description du dépôt en compte 40.

Sources officielles

1. FailproofAI/failproofai on GitHub
2. Issues
3. Project website
4. README
5. Releases