Skip to main content
Ouvrez Administration → Clés et confirmez que la clé machine est active et dispose de events:add. Ouvrez ensuite Observer → Événements, élargissez la plage temporelle et effacez les filtres d’environnement et d’agent. Si des événements existent, recherchez l’ID de session puis vérifiez Observer → Sessions pour le regroupement. Si aucun événement n’existe, diagnostiquez le démon Failproof depuis la CLI.Le flux d'événements en direct avec ses filtres principaux visibles et des événements d'agent récents qui arrivent.
Effacez les filtres dans Observer → Événements et recherchez l’ID de session SDK exact. Si rien n’apparaît, inspectez le spool du SDK et le démon Failproof sur la machine source.
Ouvrez Admin → Application, sélectionnez la machine et comparez ses versions assignée, signalée et précédente. Confirmez que le périmètre de déploiement inclut la machine et que sa clé dispose de policies:pull. L’ingestion peut fonctionner même lorsque la livraison des politiques ne fonctionne pas.
Ouvrez Admin → Application et inspectez l’heure de dernière activité et la version signalée de la machine. Si la machine est obsolète, traitez cela comme un problème de démon local. N’affaiblissez pas la politique déployée uniquement pour contourner un démon indisponible.
Pour une politique créée dans Cloud, ouvrez Admin → Éditeur de politiques, sélectionnez le brouillon et examinez les erreurs de validation avant de publier. Pour une politique locale, utilisez la CLI pour la valider, puis ouvrez Observer → Politique après une action de test pour confirmer que les décisions arrivent.
Ouvrez Analyser → Audits, sélectionnez l’exécution et vérifiez si l’analyse du modèle s’est effectuée. Comparez ensuite son périmètre et sa fenêtre avec Observer → Sessions et ouvrez des traces représentatives de cette population.Un résultat nul n’est significatif que lorsque l’analyse s’est exécutée avec succès. Si l’analyse a été ignorée ou a échoué, l’exécution ne produit aucun résultat et maintient la fenêtre non analysée ouverte pour une prochaine exécution réussie. Si l’analyse du modèle est désactivée, l’audit ne produit également aucun résultat, car le scan déterministe des credentials et des PII enregistre des statistiques mais ne génère plus de résultats.Le formulaire d'audit où l'environnement, l'agent, la cadence et la fenêtre de balayage définissent la population de sessions.
Ouvrez une session terminée et vérifiez si une évaluation manuelle réussit. Le Cloud hébergé ne dispose actuellement d’aucun contrôle de point de terminaison d’évaluateur dans le tableau de bord ; l’opérateur serveur doit le configurer.
Utilisez le sélecteur d’organisation et confirmez le slug et les permissions attendus avant de comparer les résultats avec la CLI.
Ouvrez Observer → Politique, conservez la décision et la session liée, et identifiez la condition de faux positif. Ouvrez ensuite Admin → Application et revenez à la version précédente pour les machines concernées. Créez une version plus restrictive dans l’Éditeur de politiques, testez-la sur un périmètre restreint, et étendez-la uniquement après que le travail valide réussisse.
Lorsque vous contactez le support, incluez la version de la CLI, le harnais, l’environnement, l’ID de session ou de déploiement pertinent, ainsi que la sortie de failproofai config --status avec les secrets supprimés.