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 supprimez les filtres d’environnement et d’agent. Si des événements existent, recherchez l’ID de session puis consultez Observer → Sessions pour le regroupement. Si aucun événement n’existe, diagnostiquez le daemon 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.
Supprimez 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 daemon Failproof sur la machine source.
Ouvrez Admin → application des politiques, sélectionnez la machine et comparez ses versions assignée, rapportée et précédente. Vérifiez 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 des politiques et inspectez l’heure de dernière connexion et la version rapportée de la machine. Si la machine est obsolète, traitez cela comme un problème de daemon local. N’affaiblissez pas la politique déployée uniquement pour contourner un daemon indisponible.
Pour une politique créée dans le 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 par modèle a été lancé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 si l’analyse s’est terminée avec succès. Si l’analyse a été ignorée ou a échoué, l’exécution ne produit aucun résultat et conserve la fenêtre non analysée pour une future exécution réussie. Si l’analyse par modèle est désactivée, l’audit ne produit également aucun résultat, car le scan déterministe des identifiants 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 du 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 des politiques et revenez aux machines affectées à la version précédente. Créez une version plus précise dans l’éditeur de politiques, testez-la sur un périmètre restreint et élargissez uniquement après que le travail valide réussit.
Lorsque vous contactez le support, incluez la version de la CLI, le harnais, l’environnement, l’ID de session ou de déploiement concerné, ainsi que la sortie de failproofai config --status avec les secrets supprimés.