Kindo lance Deep Hat Sift pour réduire les exécutions inutiles d’agents IA

Un agent d’IA qui analyse chaque alerte de sécurité ou entrée de journal génère des coûts, même lorsqu’il conclut qu’aucune action n’est nécessaire. À l’échelle d’une entreprise, ces investigations sans incident peuvent constituer une charge de travail importante à elles seules. Kindo a lancé Deep Hat Sift, un modèle conçu pour déterminer quels événements entrants justifient l’exécution d’un agent, avant que le modèle plus volumineux ne commence à les traiter.

Annoncé le 28 octobre, Sift apprend à partir des verdicts de l’agent auquel il est associé, puis filtre les événements que celui-ci écarterait autrement. Le produit commence par observer, sans rien bloquer : chaque événement parvient toujours à l’agent jusqu’à ce qu’une personne examine le comportement de filtrage proposé et approuve un seuil.

Cette approche introduit un mécanisme de maîtrise des coûts différent du choix d’un modèle de langage moins cher. Au lieu de réduire le coût de chaque investigation, Sift cherche à éviter celles qui ont peu de chances de nécessiter une intervention. Son efficacité dépend à la fois de la qualité de ces décisions et des contrôles encadrant les événements ignorés.

Un modèle de décision en amont du modèle de langage

Kindo décrit Deep Hat Sift comme un modèle de décision de type Système 1 : un modèle rapide et peu coûteux qui répond à une question de sélection plutôt que de générer une réponse. Chaque modèle est associé à une source, à un agent cible et à une tâche de filtrage spécifiques, afin que son apprentissage corresponde à la charge de travail qu’il est censé prendre en charge.

Cette spécificité est importante. Un événement pertinent pour une enquête de sécurité peut ne pas l’être pour un processus de gestion des demandes au service d’assistance. Sift apprend quels événements son agent cible écarte, en utilisant les verdicts renvoyés par l’agent comme signal d’apprentissage. Kindo affirme ainsi éviter un projet distinct d’annotation humaine pour chaque flux.

Le déploiement initial s’effectue en mode observation. Sift évalue les événements entrants tandis que l’agent continue de tous les examiner, ce qui permet au système de comparer ses prédictions aux décisions de l’agent. Avant le début du filtrage, les opérateurs reçoivent un aperçu des événements qui auraient été écartés à partir de leurs propres données.

Une personne doit ensuite approuver un seuil et en justifier le choix par écrit. La décision concernant le niveau de filtrage acceptable revient ainsi à l’équipe responsable du processus, plutôt que de découler automatiquement de l’installation du modèle.

L’échantillonnage et les mécanismes de bascule en mode permissif permettent de repérer les événements manqués

Le filtrage soulève une difficulté de mesure : si un événement ne parvient jamais à l’agent, comment l’équipe peut-elle savoir s’il aurait dû le traiter ? Sift continue d’envoyer à l’agent un échantillon aléatoire des événements qu’il aurait autrement écartés. Les verdicts de l’agent sur cet échantillon permettent de mesurer en continu le taux d’omission.

La page du produit précise le point de référence : le rappel et le taux d’omission sont mesurés par rapport aux jugements de l’agent. Ces indicateurs montrent dans quelle mesure Sift reproduit les décisions de cet agent. Ils ne permettent pas, à eux seuls, d’établir si l’agent lui-même détecte correctement chaque incident de sécurité ou problème opérationnel.

Kindo indique que, si la qualité se dégrade, Sift bascule en mode permissif et renvoie les événements à l’agent pour examen au lieu de continuer à les bloquer. L’entreprise décrit également des plafonds d’activité qui peuvent ramener le système en mode observation lors d’un pic. Les événements filtrés et les décisions d’approbation sont consignés afin que les équipes puissent examiner ce qui a été écarté et pour quelle raison.

« Le filtrage ne commence qu’après l’approbation du seuil par une personne. Et si la qualité se dégrade, le système bascule en mode permissif et laisse tout passer pour que le LLM rende son jugement », a déclaré Troy Presley, ingénieur Deep Hat Sift chez Kindo, dans l’annonce.

Ces mécanismes rendent le compromis visible au lieu de le faire disparaître. Un filtrage plus prudent peut préserver la couverture, mais permet de réduire moins le nombre d’exécutions. Un filtrage plus agressif peut éviter davantage de travail, mais rend l’échantillonnage, la détection des dérives et la qualité de l’agent en aval d’autant plus importants.

Conçu pour les alertes, les tickets et les flux continus de journaux

Le lancement cible les charges de travail caractérisées par un volume entrant élevé et une faible proportion d’événements nécessitant une intervention. Kindo cite les alertes SIEM et de détection des terminaux, les files de tickets, les signalements d’hameçonnage, les journaux système et réseau, ainsi que les flux issus de plateformes telles que Kafka. Parmi les sources de surveillance figurent Splunk, Datadog et New Relic.

Sift intervient en amont de l’agent, sans remplacer ces systèmes sources. Une plateforme de sécurité continue de générer des détections, un système de gestion des tickets conserve sa file d’attente et l’agent reste chargé des cas qui lui sont transmis. Cette nouvelle couche détermine quels événements déclenchent ce traitement supplémentaire par l’IA.

La même approche pourrait s’appliquer aux processus financiers et de conformité qui examinent des flux de transactions ou de règles. Là aussi, sélectionner les événements à examiner ne revient pas à déterminer s’il y a fraude ou si les règles sont respectées. L’agent cible et le processus opérationnel qui l’entoure restent des éléments importants du résultat.

Comment Sift s’intègre à la plateforme de gestion des agents de Kindo

La plateforme plus générale de Kindo relie les agents aux systèmes d’entreprise dédiés à la sécurité, à l’infrastructure et aux opérations informatiques. Elle associe l’exécution au contexte, aux autorisations et à la supervision opérationnelle, offrant aux équipes un espace où gérer le travail une fois le modèle sélectionné.

Le site web de l’entreprise décrit la propriété des agents, les politiques d’accès et l’attribution des coûts par agent, propriétaire et équipe. Sift ajoute un contrôle plus en amont dans ce processus : déterminer si un événement doit déclencher l’exécution d’un agent. Cette approche relie une décision technique de filtrage à la question opérationnelle des charges de travail qui génèrent des coûts d’inférence.

Selon l’annonce de lancement, Deep Hat Sift est disponible dès maintenant sur site, dans un cloud autogéré, dans le cloud de Kindo et dans des environnements isolés de tout réseau. Le calcul des scores s’effectue là où Kindo est installé, tandis que les appels aux modèles sont gérés par la plateforme. Le produit fonctionne avec les agents Kindo.

Les économies dépendront du flux

Kindo n’a communiqué ni pourcentage général d’économies ni référence universelle en matière de précision pour Sift. Sa page produit invite plutôt les équipes à prévisualiser, à partir de leurs propres événements, ceux que le système écarterait. Cette distinction est utile aux acheteurs : le résultat économique dépend du volume d’événements, du coût de chaque exécution évitée, de la proportion d’événements exploitables et du seuil de fonctionnement que l’équipe accepte.

Pour les flux bruités, éviter les exécutions inutiles d’agents pourrait rendre l’analyse continue par l’IA plus abordable. Pour les flux où un événement manqué aurait de graves conséquences, les contrôles d’échantillonnage et d’escalade comptent autant que la facture d’inférence. Deep Hat Sift intègre ces décisions au processus d’exécution des agents : la question centrale n’est plus de savoir quel modèle doit traiter un événement, mais si ce modèle doit le traiter tout court.