Avant de commencer
- Ouvrez le tableau de bord Failproof AI et créez un compte ou connectez-vous avec votre adresse e-mail professionnelle.
- Accédez à Administration → Keys et créez une clé avec
events:add et policies:pull.
- Copiez le secret à usage unique, puis lisez-le dans un shell sur la machine cible.
read -s le reçoit via une invite qui n’affiche pas les caractères saisis, de sorte qu’il n’apparaît jamais dans une commande :
Installation
Installer et connecter Failproof AI
Cette seule commande constitue l’intégralité de la configuration : elle installe le démon local (une seule fois en root), câble les hooks dans chaque CLI d’agent détectée et connecte cette machine au Cloud. Passer la clé via l’environnement plutôt que par --token l’empêche d’apparaître dans ps, où tous les utilisateurs de la machine peuvent lire les arguments d’une commande. Cela ne la protège pas de l’historique du shell — c’est la lecture avec read -s qui s’en charge. En CI, injectez-la comme secret masqué et désactivez le traçage shell (set -x), sinon la trace l’affichera.Les transcriptions de session sont envoyées par défaut. Ajoutez --no-transcripts pour rapporter l’activité des hooks et les décisions de politique sans le contenu des transcriptions.N’utilisez pas failproofai config --connect <url> ici. Ce flag enrôle une machine déjà configurée et retourne immédiatement — sans démon, sans hooks — de sorte que la machine apparaîtrait dans le Cloud sans rien collecter ni appliquer.
Si cette machine possède déjà un historique d’agent, prévisualisez et importez les sept derniers jours, puis attendez la fin de la livraison. Ignorez cette étape sur une nouvelle machine.Ouvrez Sessions dans Failproof AI et sélectionnez une session importée. Rattacher Failproof AI à un harnais
L’étape précédente a déjà câblé chaque CLI d’agent détectée. Réexécutez-la explicitement pour un harnais particulier si nécessaire, ou pour ajouter un harnais installé ultérieurement. Chacun des 12 est une valeur --cli valide — claude, codex, copilot, cursor, opencode, pi, hermes, openclaw, factory, devin, antigravity, goose.Le blocage d’un appel d’outil avant son exécution est vérifié sur les 12. Les points de contrôle en fin de tour sont vérifiés sur 8 — consultez la capacité d’application pour la matrice par harnais. Choisir ce qu'il faut appliquer
Le câblage des hooks n’active aucune politique. La configuration n’en choisit délibérément aucune — cette décision vous appartient — alors prenez un pack :Le pack est récupéré depuis sa release GitHub, vérifié par somme de contrôle et épinglé au tag exact résolu. Il contient 38 politiques et active les 10 que son manifeste marque comme sûres à activer sans surveillance. Utilisez-les pour observer les décisions de politique locales et tester l’application avant que Failproof AI n’audite vos sessions et rédige des politiques pour vos agents.Lisez n’importe quel pack avant de l’adopter avec failproofai policies show <owner>/<repo>, et consultez les packs de politiques pour n’en prendre qu’une partie.Tant que cela n’est pas exécuté, la seule chose appliquée est block-failproofai-commands — le garde toujours actif qui empêche un agent de désactiver Failproof AI. failproofai policies liste ce qui est activé. Exécutez failproofai config --status. Une configuration saine rapporte la connexion au cloud, l’état du démon et si l’application est en pause.