Skip to main content
Un harnais désigne l’environnement dans lequel votre agent s’exécute réellement. Failproof AI en prend en charge douze, répartis en deux catégories :
  • CLI de codage (10) — Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI, Goose
  • Passerelles de chat et d’assistant (2) — Hermes (Slack, Telegram, cron), OpenClaw (assistant auto-hébergé)
Les mêmes politiques et le même historique de sessions s’appliquent quel que soit le harnais utilisé par un agent. Une couche d’adaptation mappe les noms d’événements natifs, les noms d’outils et les champs d’entrée d’outils de chaque harnais vers 29 événements canoniques, avant toute exécution de politique. Un agent qui ne s’exécute dans aucun des douze harnais est instrumenté directement via le SDK Python. Il s’agit d’un contrat différent, qu’il convient d’énoncer clairement : le SDK fournit le traçage, les sessions, les évaluations et les audits — il n’applique pas de politiques par lui-même. Pour bloquer une action non sécurisée avant son exécution, un hook d’application est nécessaire à la frontière des outils de votre environnement d’exécution ; contactez-nous et nous vous proposerons un mapping adapté. Chaque intégration normalise ses noms d’événements de hooks natifs, ses noms d’outils et ses champs d’entrée d’outils avant l’exécution des politiques. Une politique ne peut agir que sur les événements exposés par le harnais ; testez le comportement de fin de tour et d’instruction sur le harnais et la version exacts que vous déployez.

​
Capacité d’application

« Bloquer » signifie que le verdict retourné par l’adaptateur courant est consommé par le harnais désigné. Le blocage post-outil peut remplacer le résultat présenté au modèle, mais ne peut pas annuler un effet de bord d’outil déjà survenu. Les capacités dépendent de la version. Effectuez de nouveaux tests après la mise à jour d’un CLI d’agent, notamment lorsqu’une politique repose sur le comportement des prompts, des arrêts, des permissions ou des événements post-outil plutôt que sur le verrou pré-outil commun.

​
Plugin natif Hermes

Hermes est intégré via un plugin natif local au profil plutôt que via une commande shell. L’installation copie le plugin dans chaque profil Hermes par défaut et nommé, l’active dans le config.yaml de ce profil, et migre uniquement les entrées de hooks shell FailproofAI legacy. Cela évite la création d’un processus à chaque hook et permet à instruct() d’atteindre le modèle via le résultat d’outil bloqué natif de Hermes. La première instruction correspondante bloque l’appel en attente. La même requête API reste bloquée ; une itération ultérieure du modèle peut effectuer une nouvelle tentative. Un registre persistant, limité au profil, et un plafond par tour empêchent qu’une instruction consultative ne devienne une boucle sans fin. deny() reste un blocage strict. Exécutez failproofai config --status pour détecter un profil désactivé, incomplet, dupliqué ou nouvellement non configuré.

​
Installer la capture et les hooks de politique

  1. Ouvrez Administration → Clés et créez une clé avec les permissions events:add et policies:pull, nommée selon la machine ou l’environnement.
  2. Sur la machine cible, connectez le CLI local avec la clé affichée et installez les hooks du harnais.
  3. Démarrez une nouvelle session d’agent, puis confirmez ses événements de hook et de session sous Observer → Événements.
  4. Ouvrez Observer → politique pour la même fenêtre temporelle et confirmez qu’une décision de politique est attribuée à la machine.
La connexion commence avec une clé machine. Vérifiez qu’elle inclut à la fois les permissions d’ingestion et de livraison de politiques avant de copier son secret.Le panneau de création de clé API utilisé pour accorder les permissions d'ingestion d'événements et de livraison de politiques.Après l’installation des hooks, le flux Événements devrait afficher de nouveaux événements provenant de la machine et de l’environnement que vous avez connectés.Le flux Événements en direct utilisé pour confirmer qu'un harnais nouvellement installé envoie des données.Enfin, vérifiez que les décisions de politique sont attribuées à la même machine. Cela confirme que le harnais signale bien l’activité des politiques ainsi que les événements de trace.La page Politique utilisée pour vérifier les décisions de politique d'un harnais nouvellement connecté.

​
Ajouter un chemin de session non par défaut

Les chemins supplémentaires sont enregistrés sur la machine, et non dans le Cloud. Après en avoir ajouté un, ouvrez Observer → Sessions, filtrez sur l’environnement de la machine et confirmez que les sessions issues du nouveau chemin apparaissent. Ouvrez une session et vérifiez l’agent, le harnais et les horodatages des événements avant de vous y fier dans un audit.La liste des sessions filtrée sur l'environnement recevant les données du chemin de capture supplémentaire.
Exécutez une nouvelle session après l’installation. Vérifiez à la fois le flux d’événements en direct et une décision de politique effective avant d’élargir le déploiement.