Accédez à Admin → enforcement, trouvez la machine et développez sa ligne.
Sélectionnez edit, ajoutez la version de politique approuvée et choisissez l’effet observe ou un effet d’application.
Appliquez la modification, puis attendez le prochain check-in de la machine et confirmez son état de déploiement et de couverture.
Accédez à Observe → policy pour inspecter les décisions en temps réel.
Déployez depuis la CLI avec fp fleet. Examinez le plan résultant avant de l’appliquer — deploy affiche le plan complet et demande confirmation uniquement sur un terminal interactif sans --json. Avec --json, avec --yes, ou lorsque stdin est redirigé (une étape CI, un script, un agent exécutant un sous-shell), la commande s’applique immédiatement sans plan ni confirmation — exécutez donc fp fleet show <machine> au préalable si vous souhaitez vérifier :
fp fleet diff <machine-id> affiche l’écart entre l’intention et la livraison (une machine apparaît comme behind jusqu’à sa prochaine interrogation), fp fleet history <machine-id> liste les générations, et fp fleet rollback <machine-id> <generation> en restaure une — la commande échoue si cette génération référence une politique désactivée ou supprimée depuis.Vérifiez la machine elle-même avec failproofai config --status, et utilisez fp sessions --env production --since 24h et fp events --event-type hook_completed après le déploiement pour confirmer que l’activité remonte bien vers Cloud.
1
Choisir la version et les cibles
Déployez une version approuvée, et non un brouillon modifiable, en commençant par une machine hors production ou un petit groupe de machines dont vous pouvez inspecter les sessions.
2
Observer les décisions
Examinez les correspondances, les raisons, les outils concernés et les faux positifs sans bloquer le travail.
3
Appliquer et vérifier la couverture
Passez en mode d’application une fois que les correspondances observées distinguent clairement les actions non sécurisées des actions valides, puis confirmez que chaque machine concernée a bien récupéré le déploiement et remonte ses décisions.
Les machines doivent disposer de la capacité policies:pull. Le reporting des événements est contrôlé séparément par events:add ; vérifiez les deux lorsque vous attendez une analyse et une application Cloud.
La gestion de l’application est un flux de travail Cloud administratif. Ne traitez pas les routes d’application réservées à root comme des points de terminaison API /v1 ordinaires destinés aux clients.
