La série A de Mave lève 28 millions de dollars pour des enquêtes IA dans les outils de sécurité existants

Mave a levé 28 millions de dollars lors d’un tour de série A afin d’automatiser les enquêtes de sécurité sans obliger les entreprises à centraliser au préalable leurs données de sécurité. Annoncée le 22 octobre, la série A de Mave soutient un pari architectural précis : un logiciel peut relier les éléments de preuve entre les outils existants tout en laissant aux personnes le contrôle des réponses aux conséquences importantes. Ce financement porte le total levé à 34 millions de dollars.

La tension se situe entre la collecte d’informations et l’aboutissement à une décision défendable. Une organisation peut posséder des produits de sécurité performants tout en dépendant d’analystes pour concilier des constats contradictoires. Mave propose d’automatiser ce travail de liaison, plaçant son produit entre les systèmes qui signalent une activité suspecte et les personnes responsables d’agir.

Des concurrents tels que Dropzone AI poursuivent déjà des enquêtes automatisées ; Mave arrive donc dans une compétition établie pour gagner la confiance des équipes de sécurité. Son opportunité repose sur sa capacité à faire fonctionner ensemble des outils fragmentés. Les questions importantes portent sur la qualité des enquêtes, les autorisations opérationnelles et la question de savoir si l’automatisation réduit réellement le travail une fois l’examen humain pris en compte.

Ce que finance réellement la série A de Mave

L’investissement soutient une couche d’enquête couvrant les systèmes existants, avec une expansion auprès des entreprises parallèlement au développement technique.

Red Dot Capital Partners a dirigé le tour, avec la participation de Lumir Growth Partners. Un précédent tour d’amorçage de 6 millions de dollars avait été mené par Dell Technologies Capital et Emerge Ventures. Le reportage de CTech sur le financement des enquêtes de sécurité indique que la recherche en IA, les produits destinés aux entreprises et l’expansion internationale figurent parmi les usages prévus du capital.

La distinction entre le nouveau tour et le financement total est importante. Mave a annoncé 34 millions de dollars de financement cumulé, et non une série A de ce montant. L’annonce établit le soutien des investisseurs et les priorités de dépenses. Elle ne démontre pas les performances du produit face à des approches concurrentes dans des conditions comparables.

Mave a été fondée en 2025 par son CEO Raziel Oren et son CTO Guy Eshel. L’entreprise reste donc jeune dans son histoire opérationnelle, alors même qu’elle cible des environnements d’entreprise exigeants. Le financement fournit des ressources pour le développement et la distribution, tandis que les clients ont toujours besoin de preuves que le système convient à leurs opérations de sécurité particulières.

La série A de Mave soutient également un travail qui dépasse le développement de modèles. Le déploiement en entreprise exige des connexions fiables, une gestion des autorisations, de la documentation, de l’assistance et un comportement prévisible lorsqu’un outil sous-jacent évolue. Ces responsabilités comptent, car un produit d’enquête hérite de dépendances de chaque système qu’il touche.

Une démonstration convaincante peut montrer un logiciel construisant un récit cohérent d’une activité suspecte. Un déploiement durable doit continuer à produire des résultats utiles après des modifications de politiques d’accès, des mises à niveau d’outils et des restructurations organisationnelles. Les investisseurs financent la capacité à résoudre ces problèmes, mais l’annonce de financement ne peut pas démontrer qu’ils le sont.

Il existe également une implication commerciale. Un produit qui fonctionne avec des systèmes existants permet potentiellement aux acheteurs de tester l’automatisation sans s’engager dans le remplacement d’une infrastructure plus large. Cela rend la proposition initiale plus facile à évaluer, même si la charge de déploiement réelle dépend des intégrations et contrôles requis par chaque organisation.

L’interprétation la plus solide du tour est donc précise. Les investisseurs soutiennent une tentative d’automatiser le travail d’enquête entre les produits de sécurité. Cela met les fournisseurs sous pression pour expliquer où commence leur automatisation, quelles dépendances elle introduit et comment les clients peuvent vérifier les décisions qui en résultent.

Cela donne aussi à Mave la marge nécessaire pour poursuivre conjointement son développement technique et commercial. Développer les ventes avant que le déploiement ne devienne reproductible peut mettre à rude épreuve les ressources de support. Se concentrer exclusivement sur la recherche peut rendre difficile l’adoption d’un produit pourtant efficace. Les priorités de dépenses annoncées reflètent ces deux dimensions de la construction d’une entreprise de sécurité destinée aux entreprises.

Les responsables de la sécurité font face à un problème de coordination

L’argument de Mave cible le travail manuel qui relie les outils de sécurité, plutôt qu’une source d’alertes en particulier.

Un centre des opérations de sécurité, ou SOC, est l’équipe et la fonction opérationnelle chargées de surveiller les menaces et de coordonner les enquêtes. Son travail ne se limite pas à lire des avertissements. Les analystes doivent déterminer quels éléments de preuve sont liés, si un événement est suspect et quelle réponse l’entreprise peut tolérer.

Prenons une enquête illustrative portant sur une connexion suspecte d’un employé. Un système de gestion des identités peut montrer l’activité d’authentification, tandis qu’un produit de sécurité des terminaux enregistre le comportement sur l’appareil de l’employé. Un inventaire des actifs peut identifier le propriétaire de l’appareil. L’analyste doit réunir ces observations afin de porter un jugement sur le même événement.

Cet exemple est hypothétique et ne correspond pas à un incident client Mave divulgué. Il illustre pourquoi la collecte d’une alerte ne résout pas automatiquement une enquête. Chaque observation répond à une question différente, et la relation entre ces réponses détermine si l’événement mérite une escalade.

Un système de gestion des informations et événements de sécurité, ou SIEM, collecte et analyse les événements de sécurité sur une plateforme centrale. La collecte centralisée aide à établir un historique et à rechercher parmi les enregistrements. Toutefois, un acheteur doit encore déterminer si l’enquête inclut un contexte pertinent situé hors de cette plateforme.

La pression s’exerce d’abord sur les responsables de la sécurité, qui doivent expliquer à la fois les menaces manquées et les perturbations opérationnelles. Un traitement plus rapide est attrayant, mais une décision de désactiver un accès peut interrompre un travail légitime. Une enquête automatisée doit étayer le jugement qui sous-tend cette action, plutôt que de simplement fournir sa recommandation plus tôt.

Les analystes font face à une évolution connexe de leurs responsabilités. Si le logiciel recueille les éléments de preuve, leur attention se déplace vers la vérification des hypothèses non résolues et le traitement des exceptions. Ce changement ne crée de valeur que si l’examen du résultat exige moins d’efforts que la reconstitution manuelle de l’enquête.

Les fournisseurs de services de sécurité managés, ou MSSP, exploitent des services de sécurité pour d’autres organisations. Pour eux, l’automatisation des enquêtes soulève des questions de cohérence entre les environnements clients. Une approche qui fonctionne bien dans un environnement standardisé doit être évaluée davantage lorsque les clients utilisent des produits et des politiques d’accès différents.

Cela crée une question d’achat immédiate : quelle partie du travail le produit supprime-t-il réellement ? La récupération d’enregistrements, l’identification des relations, la recommandation d’actions et l’exécution de réponses sont des capacités distinctes. Les combiner dans une présentation commerciale ne doit pas masquer leurs conséquences différentes en production.

À plus long terme, la pression atteint les fournisseurs de plateformes de sécurité. Si une couche d’enquête indépendante devient utile, les clients disposent d’un autre moyen de coordonner leurs produits existants. Les fournisseurs établis doivent alors démontrer pourquoi leurs propres flux de travail connectés offrent de meilleures preuves, une administration plus simple ou une responsabilité plus claire.

Cette issue reste conditionnelle à l’adoption. Le financement de Mave ne démontre pas que les clients déplaceront leurs budgets ou remplaceront leurs processus existants. Il donne à l’entreprise les ressources nécessaires pour défendre l’idée que la coordination mérite sa propre couche de produit, avec des bénéfices mesurables au-delà d’une interface supplémentaire.

Enquêter sur place modifie les dépendances

Éviter un nouveau référentiel central déplace le défi d’intégration vers l’accès en temps réel, l’interprétation cohérente et des preuves reproductibles.

Mave décrit un système qui interroge les outils connectés, recueille le contexte actuel et adapte son enquête à mesure que les preuves émergent. Son approche déclarée évite d’exiger une nouvelle base de données centralisée de télémétrie. La télémétrie désigne les enregistrements d’activité que les systèmes produisent sur leur fonctionnement.

L’annonce de l’entreprise concernant les opérations de sécurité agentiques décrit des agents qui enquêtent et effectuent des tâches autorisées dans les systèmes existants. Ici, les agents sont des composants logiciels qui poursuivent des tâches via des outils connectés. Ces capacités restent des affirmations de l’entreprise, plutôt que des résultats comparatifs établis de manière indépendante.

Travailler là où l’information réside déjà constitue une proposition attrayante. Les acheteurs peuvent déterminer si la couche d’enquête accède à un contexte utile sans reconstruire l’ensemble du processus de collecte. La question architecturale passe de l’emplacement où tous les enregistrements devraient vivre à celle des preuves que le système peut récupérer lorsqu’il en a besoin.

Ce déplacement crée des dépendances qui méritent d’être examinées. Si un outil connecté devient indisponible, une enquête doit distinguer une recherche incomplète d’une absence d’activité suspecte. Sans cela, une réponse manquante risque de devenir une conclusion injustifiée.

Le même enjeu s’applique aux autorisations. Un accès limité peut être approprié pour des raisons de sécurité, mais il restreint ce que le système peut établir. Une enquête devrait rendre cette limite visible afin que les examinateurs comprennent quelles questions restent sans réponse.

Le temps ajoute une autre complication. Les informations actuelles peuvent aider à expliquer un incident en cours, tandis que les enregistrements historiques aident à reconstituer ce qui s’est produit auparavant. Les acheteurs devraient évaluer la manière dont le produit relie des observations recueillies à différents moments, notamment lorsque l’état d’un compte ou la configuration d’un appareil change au cours d’une enquête.

Une piste d’audit, c’est-à-dire un enregistrement conservé des étapes d’enquête et des preuves, aide les examinateurs à évaluer cette relation. Mave indique enregistrer les requêtes, les preuves, le raisonnement et les actions. La question pratique est de savoir si ces enregistrements permettent à un examinateur de tester la conclusion sans répéter l’ensemble du flux de travail.

Par exemple, une recommandation devrait pouvoir être distinguée de l’observation qui l’étaye. Un enregistrement indiquant qu’un accès a été révoqué est différent d’une preuve montrant que le compte a été compromis. Garder ces éléments séparés aide les examinateurs à identifier si un désaccord porte sur les faits, leur interprétation ou la politique de réponse.

Il s’agit d’un critère d’évaluation, et non d’une affirmation concernant une limitation démontrée de Mave. L’architecture rend ces questions particulièrement pertinentes, car l’enquête dépend de plusieurs systèmes connectés. La fiabilité doit couvrir les connexions et leur interprétation, en plus du modèle linguistique.

Éviter la centralisation n’élimine pas non plus les questions de gouvernance des données. Un acheteur a toujours besoin de clarté sur les informations récupérées, le lieu où le traitement se produit et les enregistrements d’enquête conservés. Ces détails déterminent si la conception répond aux obligations de l’organisation.

Le compromis architectural est donc plus précis qu’un choix entre d’anciennes bases de données et une nouvelle IA. La collecte centralisée et l’enquête en temps réel répondent à des besoins qui se chevauchent. L’opportunité de Mave consiste à montrer que son approche améliore les décisions dans un environnement existant tout en rendant les lacunes restantes inspectables.

Les concurrents font de la qualité des enquêtes le point de comparaison

L’enquête automatisée constitue déjà une catégorie concurrentielle ; Mave doit donc offrir une différenciation que les acheteurs peuvent observer dans leurs propres environnements.

Dropzone AI offre un point de référence utile. La couverture de GeekWire sur ses analystes SOC basés sur l’IA décrit un logiciel conçu pour enquêter sur les alertes et escalader les incidents nécessitant une attention humaine. Cela établit des ambitions produit qui se recoupent, sans démontrer qu’une entreprise soit plus performante que l’autre.

La comparaison importe, car un acheteur en entreprise peut évaluer plusieurs approches pour un travail similaire. Une promesse générale de réduire les investigations répétitives n’identifie pas les conditions dans lesquelles un système mérite d’être préféré. La couverture des intégrations, la qualité des preuves et l’adéquation opérationnelle deviennent centrales dans cette décision.

L’accent mis par Mave sur les investigations à travers les systèmes existants lui donne un positionnement concret. Toutefois, un positionnement ne devient différenciant que si sa mise en œuvre produit un avantage. Les acheteurs doivent voir si le produit gère leurs combinaisons particulières d’outils, de dossiers incomplets et de flux de travail inhabituels.

Les affirmations des concurrents méritent également la même rigueur d’attribution que celle appliquée à Mave. Edward Wu, PDG de Dropzone, a déclaré à CRN que son produit réalise des investigations sans intervention humaine pour fournir le service sous-jacent. Il a aussi décrit une fonction interne de contrôle qualité humain examinant le travail achevé.

La discussion de CRN sur les investigations entièrement logicielles met en évidence une distinction utile entre fournir un service et en contrôler la qualité. Il s’agit de la description par Wu de l’approche de son entreprise. Cela n’établit pas comment Mave organise ses propres opérations.

Pour les acheteurs, cette distinction ouvre une question plus large sur ce que l’automatisation signifie sur le plan opérationnel. Un produit peut automatiser la récupération de preuves tandis que des personnes réalisent le raisonnement complexe. Un autre peut automatiser l’investigation tout en exigeant un examen approfondi du client. Les deux configurations nécessitent une communication claire avant que les clients comparent leurs résultats.

La même prudence s’applique aux affirmations de rapidité. Un verdict rapide a une portée limitée sans compréhension du périmètre de l’investigation. Si un système vérifie moins de sources pertinentes, un délai d’exécution plus court n’indique pas nécessairement un meilleur travail.

Les comparaisons doivent également tenir compte des cas non résolus. Un produit qui identifie clairement l’incertitude peut être plus utile qu’un autre fournissant une réponse assurée sans preuves suffisantes. Évaluer uniquement les investigations achevées ferait passer cette différence inaperçue.

Ces considérations maintiennent le cadre concurrentiel sur des bases solides. Mave et Dropzone n’ont pas besoin de suivre des architectures identiques pour se disputer la même responsabilité opérationnelle. La concurrence pertinente porte sur l’approche qui aide une équipe de sécurité à prendre des décisions défendables avec moins d’effort total.

Cela explique également pourquoi les flux de travail existants restent une référence importante. Un nouveau produit doit améliorer ce que les clients font déjà, y compris l’examen humain qu’il introduit. Les financements et les démonstrations aident les entreprises à entrer dans cette discussion ; les résultats des déploiements déterminent si elles y restent.

La série A de Mave donne à l’entreprise des ressources pour concourir selon ces critères. Elle ne justifie pas de qualifier l’entreprise de leader de catégorie ni de supposer que son architecture produit des résultats supérieurs. Ces jugements exigent des preuves comparables que le financement ne fournit pas à lui seul.

La traçabilité aide, mais n’établit pas l’exactitude

Un dossier d’investigation lisible favorise la responsabilité, tandis que la conclusion sous-jacente nécessite toujours un examen indépendant.

Mave indique être déployé dans plus de 200 SOC et permettre aux équipes de gouverner l’exécution automatique et les approbations humaines. Ces déclarations décrivent des déploiements rapportés et un contrôle prévu. Elles ne fournissent pas une mesure commune de l’exactitude des investigations ni ne montrent dans quelle mesure chaque déploiement utilise le produit.

Un nombre de déploiements peut désigner des organisations aux modalités opérationnelles très différentes. Un déploiement limité et un flux de travail largement adopté représentent des niveaux de dépendance distincts. Sans ce contexte, ce chiffre établit plus clairement une portée déclarée qu’une profondeur opérationnelle.

L’incertitude technique dépasse les libellés de déploiement. Le National Institute of Standards and Technology identifie la confabulation, c’est-à-dire la génération assurée de contenu faux, comme un risque de l’IA générative. Son profil sur les risques de l’IA générative avertit également que les explications générées peuvent conduire les personnes à faire confiance à des résultats incorrects.

Ces orientations constituent un cadre général de risques, plutôt qu’une évaluation de Mave. Leur pertinence concerne la manière dont les acheteurs interprètent une investigation générée par l’IA. Une explication qui paraît cohérente nécessite des observations étayantes, en particulier lorsque la réponse proposée affecte l’accès ou la disponibilité des systèmes.

La traçabilité répond à une partie de ce problème. Les examinateurs peuvent inspecter ce que le logiciel a vérifié et comparer la conclusion aux preuves. Toutefois, un enregistrement des étapes ne peut établir que toutes les questions nécessaires ont été posées ni que chaque observation a reçu la bonne interprétation.

Les contrôles d’approbation répondent à un problème différent. Ils déterminent qui peut autoriser une action, mais leur valeur dépend de ce que reçoit l’examinateur. Si les preuves à l’appui ne sont pas claires, une étape d’approbation humaine peut devenir un geste administratif plutôt qu’un contrôle significatif.

Une évaluation utile examine donc comment le produit communique l’incertitude. Les informations manquantes, les observations contradictoires et les identités ambiguës doivent rester visibles. L’acheteur doit savoir si le système s’interrompt, demande davantage de contexte ou présente une conclusion circonscrite.

Les autorisations exigent une attention similaire. L’autorité de lire des dossiers diffère de celle d’isoler un appareil ou de désactiver un compte. Les clients doivent comprendre comment ces responsabilités sont séparées et comment les exceptions affectent une investigation en cours.

Aucune de ces questions n’établit un défaut dans le produit de Mave. Elles identifient les preuves nécessaires pour évaluer son rôle prévu. Plus l’action autorisée est conséquente, plus il est justifié d’examiner l’ensemble du parcours, de l’observation à l’autorisation.

Un problème pratique de connaissance se pose également une fois l’investigation terminée. Les équipes doivent préserver les décisions, les exceptions et les explications qui éclairent les examens futurs. Une base de connaissances interrogeable soutient ce travail de documentation, tandis que les contrôles de sécurité régissent l’accès et la réponse opérationnels.

L’incertitude centrale est de savoir si l’automatisation économise des efforts une fois ces responsabilités prises en compte. Un système qui produit davantage de conclusions peut tout de même laisser aux analystes un travail de vérification considérable. Démontrer une automatisation utile exige de montrer quelle quantité de travail d’investigation fiable parvient à son terme.

Surveillez les preuves clients, les limites opérationnelles et l’adoption répétée

Les prochains signaux utiles concernent des résultats démontrés, des contrôles divulgués et la question de savoir si les clients étendent leur dépendance au produit.

Au cours des prochains mois, le premier signal à surveiller est une preuve client détaillée. Un témoignage utile expliquerait l’environnement opérationnel, le périmètre de l’investigation, le flux de travail antérieur et l’intervention humaine restante. Des exemples nommés rendraient les affirmations plus faciles à évaluer qu’un simple nombre agrégé de déploiements.

Les preuves les plus solides incluraient des cas difficiles aux côtés des réussites courantes. Les examinateurs doivent comprendre ce que le logiciel a traité, où il a nécessité une assistance et comment l’équipe a reconnu ces limites. Un résultat soigneusement délimité peut être plus informatif qu’une affirmation générale selon laquelle chaque alerte est investiguée.

De telles divulgations renforceraient l’argument selon lequel l’architecture de Mave crée une valeur pratique à travers les systèmes existants. Des preuves de reconstruction substantielle ou de correction manuelle répétée restreindraient cet argument. La distinction porte sur la quantité de travail fiable que le système achève, plutôt que sur sa capacité à produire un récit d’investigation.

Le deuxième signal est un plus grand niveau de détail concernant les limites opérationnelles. Les acheteurs devraient surveiller la documentation expliquant les autorisations, les connexions indisponibles, les preuves conservées et le comportement d’approbation. Ces détails faciliteraient l’évaluation du comportement de la plateforme en dehors d’une démonstration réussie.

Des limites claires soutiendraient la position de Mave, car les équipes d’entreprise ont besoin d’un comportement prévisible dans des conditions imparfaites. Des descriptions vagues rendraient la charge d’intégration difficile à évaluer. Ce signal concerne un comportement divulgué, plutôt qu’une version particulière d’une fonctionnalité promise par l’entreprise.

Le troisième signal est l’adoption répétée. La preuve que les clients renouvellent, étendent la couverture des investigations ou confient des flux de travail approuvés supplémentaires montrerait une dépendance opérationnelle croissante. La question pertinente est de savoir ce qui a changé dans l’utilisation réelle, parallèlement à toute croissance du nombre de déploiements.

L’expansion doit néanmoins être interprétée avec soin. Un accès supplémentaire peut refléter la confiance, mais les acheteurs doivent savoir quelles responsabilités restent confiées aux personnes. Une image plus complète relierait l’utilisation accrue à l’effort d’examen, à la qualité des escalades et au traitement des exceptions.

Ces signaux suivent un ordre logique. Les preuves clients établissent l’utilité, les détails opérationnels établissent comment cette utilité résiste, et l’adoption répétée indique si la configuration reste précieuse. Aucun n’exige de prédire que Mave remplacera les plateformes établies ou surpassera chaque concurrent.

Pour les responsables de la sécurité qui suivent la série A de Mave, commencez par le flux de travail que votre équipe trouve le plus difficile à achever de manière fiable. Identifiez où se trouvent les preuves, quels jugements exigent une responsabilité humaine et quelle quantité d’examen nécessiterait une conclusion automatisée. Comparez ensuite les affirmations des fournisseurs à cette réalité opérationnelle. Demandez des investigations achevées qui exposent l’incertitude, y compris les cas où le système s’est arrêté ou a escaladé. Examinez si le dossier soutient la réponse proposée et si un autre analyste peut le suivre. L’étape suivante utile consiste à rechercher des preuves répondant à ces questions. Quelle partie de votre processus d’investigation feriez-vous confiance à un logiciel pour accomplir, et que devriez-vous voir avant d’étendre cette confiance ?