Le financement de Reco AI Security atteint 140 M$, mais un marché encombré relève la barre

Reco a levé une extension de série B de 55 millions de dollars, portant son financement total à 140 millions de dollars, alors que les entreprises peinent à gouverner les agents d’IA dans des environnements SaaS étendus. Le financement de Reco AI Security donne à la startup davantage de ressources pour transformer sa visibilité existante sur les applications en une plateforme de sécurité des agents.

Cette transition compte davantage que le titre sur le financement. Reco se concentrait auparavant sur la cartographie des applications SaaS, des identités, des autorisations et des risques de configuration. L’entreprise veut désormais relier ces enregistrements aux agents, à leurs propriétaires, aux outils qu’ils appellent et aux données auxquelles ils peuvent accéder.

Cette stratégie place également Reco sur un marché de plus en plus encombré. HiddenLayer, WitnessAI, CrowdStrike et d’autres fournisseurs abordent la sécurité des agents via la surveillance à l’exécution, les contrôles d’identité, la gouvernance des données ou la découverte d’applications. Reco doit démontrer que son contexte SaaS lui procure un avantage durable, et pas seulement un message opportun.

Le financement de Reco AI Security soutient une stratégie élargie pour les agents

Les nouveaux capitaux soutiennent le passage de Reco de la surveillance des applications SaaS à la gouvernance de logiciels autonomes qui agissent par leur intermédiaire.

Cette extension fait suite à une série B de 30 millions de dollars annoncée en février 2026. AT&T Ventures, Forestay Capital et Quadrille Capital ont participé au dernier financement, selon la couverture du financement.

La participation d’AT&T revêt une importance supplémentaire, car l’entreprise de télécommunications est aussi cliente de Reco. Un client-investisseur peut apporter une validation commerciale, même si cette relation ne permet pas d’établir avec quelle constance le produit fonctionne dans d’autres organisations.

Reco prévoit de consacrer ces capitaux au recrutement, aux ventes, aux partenariats et au support client. Ces priorités suggèrent que l’entreprise considère que sa contrainte immédiate relève de l’exécution et de la distribution, plutôt que de l’identification d’un autre marché.

Le PDG Ofer Klein a déclaré à TechCrunch que la valorisation de Reco avait plus que doublé depuis février. Il l’a située dans la tranche supérieure des centaines de millions, sans divulguer de chiffre précis.

Klein a également indiqué que le revenu annuel récurrent avait atteint plusieurs dizaines de millions de dollars et qu’il s’attendait à le tripler en 2026. Il s’agit de déclarations de la direction, et non de résultats audités de manière indépendante. L’entreprise compte plus de 100 clients, les services financiers représentant environ 40 % de son activité.

Ces chiffres donnent à Reco une base crédible dans les entreprises, particulièrement dans un secteur où les acheteurs exigent de longues évaluations de sécurité. Ils laissent toutefois ouvertes d’importantes questions concernant la taille des contrats, les taux de renouvellement, l’ampleur des déploiements et la part des revenus actuels provenant de produits spécifiquement dédiés aux agents.

L’historique de financement montre à quelle vitesse le positionnement de Reco a évolué. L’entreprise a levé 25 millions de dollars de capitaux supplémentaires en 2025, puis annoncé sa série B de 30 millions de dollars en février 2026. Ce tour de février a porté son total déclaré à 85 millions de dollars.

Reco a d’abord décrit son problème central comme la lacune de sécurité du SaaS. L’entreprise ciblait les applications que les équipes de sécurité ne pouvaient pas entièrement inventorier, configurer ou surveiller. Ses documents plus récents placent les agents d’IA, les identités non humaines et les connexions inter-applications davantage au centre.

Cette évolution ne signifie pas que Reco a abandonné la sécurité SaaS. L’entreprise traite plutôt le SaaS comme l’environnement par lequel de nombreux agents d’entreprise reçoivent des autorisations et accomplissent leur travail.

Cette distinction est au cœur de la thèse du financement de Reco AI Security. Un agent crée rarement de la valeur de façon isolée. Il a besoin d’accéder aux e-mails, aux dossiers clients, aux documents, aux systèmes de tickets, aux plateformes de collaboration et aux bases de données internes.

Chaque connexion peut également accroître les dommages causés par une instruction compromise, une autorisation excessive, un compte abandonné ou une intégration mal configurée. Reco parie que son graphe d’applications existant fournit le contexte nécessaire pour identifier ces combinaisons.

Le financement soutient donc à la fois une expansion produit et un repositionnement sur le marché. Reco doit convaincre les responsables de la sécurité d’une promesse plus large sans perdre la crédibilité acquise autour de la visibilité SaaS.

La prolifération des agents transforme l’inventaire en problème de sécurité

Les entreprises ne peuvent pas gouverner les agents qu’elles ne peuvent pas identifier, surtout lorsque ces agents héritent d’accès de personnes, d’applications et de comptes de service.

La prolifération des agents décrit la croissance incontrôlée des agents d’IA dans une organisation. Elle inclut les agents créés par des développeurs internes, les fonctionnalités activées dans des logiciels commerciaux, les assistants basés sur le navigateur, les flux de travail automatisés et les outils adoptés sans approbation formelle.

Ce phénomène est plus difficile à mesurer que l’adoption traditionnelle de logiciels. Une application peut héberger de nombreuses instances d’agents, et un seul agent peut interagir avec plusieurs systèmes métier. Les définitions varient également selon les fournisseurs, ce qui rend les grands décomptes d’agents difficiles à comparer.

Klein a déclaré que Reco avait découvert 21 000 agents auparavant inconnus chez un client du Fortune 100. Le client n’a pas été nommé, et ni Reco ni TechCrunch n’ont communiqué la méthode de comptage.

Ce chiffre doit donc être considéré comme un exemple rapporté par l’entreprise, et non comme une référence générale. Son importance réside dans la lacune de visibilité qu’il décrit. Une grande entreprise peut approuver d’importantes plateformes d’IA tout en perdant la trace des automatisations individuelles opérant en leur sein.

Reco affirme également avoir trouvé un agent créé par un ancien employé chez un client des services financiers. Cet agent aurait conservé un accès à Salesforce et pouvait envoyer des informations vers un domaine que l’organisation ne pouvait pas surveiller.

Ce scénario relie plusieurs défaillances de sécurité bien connues. L’employé était parti, mais un acteur numérique associé à cette personne restait actif. L’agent disposait également d’un accès applicatif et d’un canal de communication externe.

Un processus conventionnel de départ pourrait désactiver le compte de l’employé sans identifier chaque jeton délégué, flux de travail ou agent connecté. Les administrateurs d’applications pourraient voir une intégration autorisée sans savoir que son propriétaire initial avait quitté l’organisation.

Le risque provient de la combinaison. Un agent, une information d’identification, une source de données et une destination externe peuvent tous paraître acceptables lorsqu’ils sont examinés séparément. Ensemble, ils peuvent créer une voie non approuvée pour des informations sensibles.

Reco appelle la structure de données qui sous-tend son approche un graphe de contexte. Un graphe enregistre les relations entre agents, applications, comptes, personnes, autorisations, outils et ressources de données. Les équipes de sécurité peuvent alors examiner ce qu’un agent peut atteindre, plutôt que de traiter des alertes isolées.

Cette conception ressemble à la cartographie des relations déjà utilisée dans les produits de sécurité des identités, du cloud et du SaaS. Le défi propre aux agents est que les autorisations et les actions peuvent changer au cours d’un flux de travail.

Un employé suit généralement un schéma reconnaissable de connexion et d’utilisation des applications. Un agent peut traiter une instruction, appeler plusieurs outils, récupérer des documents, mettre à jour un enregistrement et envoyer une réponse au sein d’une seule séquence automatisée.

L’agent peut également agir par l’intermédiaire d’une identité humaine, d’un compte de service ou de ses propres identifiants. Cette diversité complique l’attribution de la propriété et des responsabilités.

Reco indique que sa plateforme s’intègre à plus de 280 applications. Klein a également déclaré que l’entreprise peut ajouter des intégrations en quelques jours et utiliser des signaux de navigateur ou de réseau pour trouver des agents au-delà des applications directement connectées.

Ces affirmations comptent, car la couverture de la découverte détermine la qualité de chaque contrôle ultérieur. Un graphe contenant des données incomplètes sur les applications ou les identités peut présenter une vision assurée, mais trompeuse.

Les équipes de sécurité devraient demander ce que Reco considère comme un agent, quels signaux permettent d’en identifier un et comment les instances dupliquées sont traitées. Elles devraient également demander si la découverte se poursuit après le déploiement et à quelle vitesse le graphe reflète les autorisations révoquées.

Le défi plus large de la gouvernance des agents affecte déjà l’adoption. Google Cloud a rapporté que 79 % des responsables technologiques interrogés considéraient la sécurité, la gouvernance ou les opérations comme leur principal obstacle à la mise à l’échelle de l’inférence.

Le même rapport a révélé que 35 % des décideurs IT de haut niveau citaient une sécurité insuffisante pour les accès à plusieurs systèmes comme principal frein au déploiement d’agents. Ces chiffres issus d’un rapport sponsorisé par un fournisseur nécessitent du contexte, mais ils étayent le problème central : les agents deviennent utiles en franchissant les frontières entre systèmes.

Reco positionne l’inventaire comme premier point de contrôle. La tâche plus difficile pour l’entreprise consiste à montrer que la découverte mène à une application fiable des politiques lorsque les agents changent d’outils, d’autorisations et de comportement.

Le graphe SaaS de Reco fait face à des rivaux de la sécurité à l’exécution

Reco est en concurrence avec une autre voie de sécurité, qui privilégie ce qu’un agent fait pendant son exécution plutôt que de commencer par les relations entre applications.

Le marché de la sécurité des agents d’IA ne possède pas de frontière produit établie. Les fournisseurs utilisent un langage similaire tout en protégeant différentes parties de la pile technologique.

Reco commence par les applications d’entreprise et les identités qui les relient. Sa plateforme vise à identifier les agents, à les associer à des propriétaires, à cartographier les autorisations, à inspecter les appels d’outils et à restreindre les accès inutiles.

HiddenLayer aborde le problème sous l’angle des charges de travail d’IA et de la sécurité à l’exécution. La sécurité à l’exécution consiste à observer les comportements et à y répondre lorsqu’un modèle ou un agent est en fonctionnement.

HiddenLayer a levé une série B de 100 millions de dollars en septembre 2026. L’entreprise a indiqué qu’elle étendrait les protections pour les agents en production et les outils de codage autonomes qui écrivent, révisent ou livrent du code.

Sa stratégie de sécurité à l’exécution se concentre sur la détection de la manipulation des prompts, du mauvais usage des outils et des actions non autorisées au moment où ils se produisent. HiddenLayer couvre également la découverte de modèles, la simulation d’attaques et les risques de la chaîne d’approvisionnement de l’IA.

CrowdStrike apporte son expertise historique des terminaux et de la détection-réponse. Ses produits de sécurité des agents relient les prompts et l’activité des agents à l’exécution en aval sur les appareils et les infrastructures.

Les contrôles du cycle de vie des agents de l’entreprise comprennent la découverte, l’identité, la protection de la chaîne d’approvisionnement logicielle et le confinement à l’exécution. CrowdStrike affirme que les agents exigent une autorisation continue, car ils peuvent exécuter du code, accéder à des fichiers et déplacer des informations sensibles.

Ces approches se chevauchent, mais leurs points de départ diffèrent.

Reco demande quels agents existent, qui en est propriétaire et quelles ressources SaaS ils peuvent atteindre. Les fournisseurs axés sur l’exécution demandent ce qui se passe lorsqu’un agent traite des instructions et exécute des actions. Les fournisseurs de solutions pour terminaux examinent l’activité des appareils et des charges de travail générée par ces actions.

Une entreprise aura probablement besoin d’éléments des trois approches. Un parcours de contrôle complet pourrait découvrir un agent grâce à la télémétrie SaaS, vérifier son identité, limiter ses autorisations, inspecter ses appels d’outils et arrêter les comportements dangereux à l’exécution.

La question commerciale est de savoir quel fournisseur deviendra le principal plan de contrôle. Les équipes de sécurité résistent généralement à l’ajout de consoles distinctes pour chaque nouvelle catégorie de risque. Les plateformes établies peuvent intégrer des protections pour les agents aux contrats existants et aux flux de travail opérationnels.

L’avantage de Reco réside dans son contexte couvrant les applications cloud. Si son graphe cartographie déjà les personnes, les comptes, les autorisations et les connexions SaaS, l’ajout d’agents peut offrir aux clients une voie plus rapide vers une gouvernance utilisable.

Son inconvénient est que la cartographie des accès ne révèle pas automatiquement chaque action nuisible. Un agent peut disposer d’une autorisation légitime pour lire un document et envoyer un e-mail. Le problème de sécurité apparaît lorsqu’un contenu malveillant ou trompeur l’amène à combiner ces capacités.

C’est là que l’injection de prompt devient pertinente. Une injection de prompt survient lorsqu’un contenu non fiable modifie les instructions d’un agent, pouvant rediriger ses outils ou exposer des données.

Une instruction malveillante peut être dissimulée dans une page web, un document, un message ou la réponse d’un outil. L’agent peut la rencontrer au cours d’une tâche par ailleurs approuvée.

Le contexte applicatif aide à estimer les dommages potentiels, mais l’inspection à l’exécution permet d’identifier la séquence dangereuse. Reco affirme pouvoir inspecter les prompts et les appels d’outils, ce qui le rapproche de ce domaine d’analyse à l’exécution.

Le marché testera la profondeur de cette inspection sur différents modèles et applications. Il évaluera également si Reco peut réagir assez vite sans bloquer l’automatisation légitime.

Les acheteurs de solutions de sécurité devraient résister aux affirmations générales selon lesquelles un seul graphe, une seule passerelle ou un seul capteur d’endpoint résout à lui seul le risque lié aux agents. Chacun ne voit qu’une partie différente du flux de travail.

Une évaluation pragmatique doit suivre un agent, de sa création à sa mise hors service, en passant par l’authentification, la sélection des outils, l’accès aux données et l’exécution. Les acheteurs peuvent alors identifier les étapes qui restent invisibles ou dépendent d’un autre produit.

Le produit de Reco sera le plus solide lorsque ses relations entre applications conduiront directement à des décisions applicables. Une équipe de sécurité devrait pouvoir identifier un agent abandonné, comprendre ses accès, révoquer une connexion risquée et confirmer que l’action a pris effet.

Le financement donne à Reco le temps de construire cette démonstration. Il ne fait pas disparaître la pression exercée par les grandes plateformes ou les spécialistes de la sécurité de l’IA bien financés.

Le financement valide la demande, pas le leadership catégoriel de Reco

L’intérêt des investisseurs confirme que les entreprises investiront dans la sécurité des agents, mais il ne détermine pas quelle architecture technique l’emportera.

Au moins deux douzaines d’entreprises vendent désormais une forme de sécurité des agents IA, selon l’examen par TechCrunch des profils publics d’entreprises. Leurs produits couvrent la validation des outils, l’accès aux données, l’identité, la surveillance à l’exécution, la sécurité des prompts et la découverte de l’IA fantôme.

Cette densité crée un environnement d’achat difficile. Les RSSI doivent évaluer les produits avant que les définitions communes, les référentiels d’évaluation et les modes de déploiement ne se soient stabilisés.

Les fournisseurs peuvent décrire une même fonctionnalité avec des termes différents. L’inventaire des agents d’une entreprise peut ressembler à la découverte de l’IA fantôme d’une autre. Les graphes de contexte, graphes de connaissances, graphes d’identité et graphes d’actifs peuvent se chevaucher largement.

Le problème inverse existe également. Des formulations similaires peuvent masquer d’importantes différences techniques. La « sécurité des agents » peut désigner la surveillance des prompts, la protection des modèles, la gouvernance des autorisations, le contrôle des serveurs Model Context Protocol ou le confinement de l’activité sur les endpoints.

Model Context Protocol, couramment appelé MCP, est une norme permettant de connecter des systèmes d’IA à des outils et à des données externes. MCP étend les capacités des agents, mais crée aussi une couche d’intégration supplémentaire que les défenseurs doivent examiner.

Reco doit démontrer où sa plateforme contrôle les comportements et où elle se contente de signaler les risques. La visibilité a de la valeur, mais les équipes de sécurité doivent à terme approuver, restreindre, isoler ou supprimer un agent.

L’entreprise doit également étayer ses exemples clients. La découverte rapportée de 21 000 agents inconnus est frappante, mais les lecteurs ne peuvent évaluer le résultat sans définition ni méthodologie.

Ce total pourrait inclure des assistants intégrés, des instances d’agents, des flux de travail, des outils, des comptes de service ou des observations répétées. Chaque interprétation a des implications de sécurité différentes.

Un nombre plus réduit d’agents disposant d’accès étendus pourrait présenter davantage de risques que des milliers d’automatisations limitées. La taille brute de l’inventaire ne devrait pas se substituer à l’analyse de l’exposition.

Reco indique que les clients des services financiers représentent environ 40 % de son activité. Cette concentration lui donne accès à des acheteurs exigeants, soumis à des contrôles stricts en matière d’audit, d’identité et de données.

Elle peut aussi relever les attentes. Les banques et autres institutions réglementées ont besoin de pistes d’audit claires, d’une application cohérente des règles, de contrôles régionaux et d’un comportement d’intégration prévisible.

La gouvernance des agents doit s’étendre à la mise hors service et à la gestion des changements. Lorsqu’un employé change de rôle, chaque autorisation déléguée et chaque agent associé doivent être examinés. Lorsqu’une application modifie ses fonctionnalités d’IA, l’organisation doit détecter les nouvelles identités et connexions.

La même exigence s’applique aux systèmes de connaissances. La sortie d’un agent n’est contrôlée qu’à hauteur des documents, messages et bases de données qu’il peut récupérer. Les équipes qui créent des flux de travail internes basés sur l’IA ont besoin de limites d’accès claires autour de leur base de connaissances, et non simplement d’un relevé du modèle ayant généré une réponse.

Une autre incertitude concerne les faux positifs. Les signaux du navigateur et du réseau peuvent élargir la découverte, mais une détection étendue peut aussi classer une automatisation ordinaire comme un agent.

Les équipes de sécurité ignoreront les alertes si la plateforme ne peut pas les hiérarchiser selon un impact crédible. Le graphe de Reco doit distinguer un assistant à faible risque d’un flux de travail abandonné disposant d’un accès en écriture aux systèmes clients.

Les faux négatifs ont le coût inverse. Un agent qui évite les signaux connus du navigateur, du réseau ou des applications peut rester absent du graphe. Les organisations devraient tester la manière dont Reco gère les agents personnalisés, les API internes, les modèles locaux et les plateformes d’automatisation.

L’accès aux données constitue une autre préoccupation pratique. Une plateforme qui cartographie les applications et les identités d’entreprise peut traiter des métadonnées très sensibles. Les clients devront examiner la conservation, l’hébergement régional, l’accès administratif et le périmètre des prompts collectés.

L’inspection des prompts peut améliorer la détection, mais elle peut aussi exposer du contenu confidentiel à un autre système de sécurité. Reco doit clarifier les limites de collecte et les contrôles de masquage.

Ces questions ne remettent pas en cause la logique du financement. Elles définissent le travail qui doit lui succéder.

Les preuves les plus solides viendront de déploiements démontrant une exposition réduite, des enquêtes plus rapides et une application fiable des politiques. La croissance des revenus et le nombre de clients comptent, mais les résultats de sécurité détermineront si Reco devient une infrastructure pérenne.

Pourquoi les outils de sécurité existants ne peuvent pas simplement absorber le problème

La sécurité des agents combine des contrôles familiers dans des séquences inédites, ce qui rend l’intégration plus importante que l’ajout d’un nouveau produit isolé.

La gestion des identités et des accès détermine déjà qui peut entrer dans les systèmes d’entreprise. La prévention des pertes de données surveille déjà les informations sensibles qui quittent les périmètres approuvés. La détection sur les endpoints observe déjà les processus, les fichiers et l’activité réseau.

Les outils de sécurité SaaS répertorient déjà les applications et les risques de configuration. Les produits de sécurité des modèles testent les prompts, les données d’entraînement et le comportement d’inférence.

Les agents traversent ces catégories parce qu’ils traduisent le langage en actions. Ils peuvent s’authentifier comme des identités, communiquer comme des utilisateurs, appeler des logiciels comme des applications et modifier leur comportement selon le contenu récupéré.

Les contrôles traditionnels peuvent toujours aider. Le défi consiste à relier leurs observations en une seule décision avant qu’un flux de travail automatisé ne s’achève.

Prenons l’exemple d’un agent commercial préparant une mise à jour pour un client. Il peut récupérer les informations d’un compte dans Salesforce, rechercher des notes de réunion, lire des tickets de support, créer un document et envoyer un e-mail.

Chaque action peut être autorisée. Le flux de travail combiné peut néanmoins exposer des informations au mauvais destinataire si l’instruction, l’identité ou la destination change.

Un graphe au niveau applicatif peut montrer la portée potentielle de l’agent. La télémétrie à l’exécution peut montrer la séquence qu’il a réellement exécutée. Les contrôles d’identité peuvent vérifier le compte et restreindre ses autorisations.

Les contrôles de données peuvent identifier les contenus protégés. La surveillance des endpoints ou du cloud peut contenir l’activité en aval lorsque le flux de travail dépasse les API SaaS.

Aucune couche ne remplace les autres. La compétition émergente porte donc sur la coordination.

L’empreinte d’intégration de Reco lui offre une voie vers cette coordination. L’entreprise affirme que sa plateforme couvre plus de 280 applications et peut ajouter de nouvelles intégrations en quelques jours.

Cette étendue peut aider les acheteurs à éviter des projets de découverte distincts pour chaque application. Toutefois, le nombre d’intégrations révèle peu de choses sur leur profondeur.

Un connecteur peut exposer les utilisateurs et les autorisations. Un autre peut fournir des événements de configuration, des inventaires d’agents, des enregistrements de prompts et une application des règles en temps réel. Les acheteurs devraient évaluer les objets accessibles et les actions prises en charge pour chaque système critique.

CrowdStrike soutient qu’une protection efficace nécessite visibilité, identité et réponse à l’exécution. HiddenLayer met l’accent sur des tests continus, car les revues à la conception ne peuvent prévoir chaque interaction en production.

Le modèle de Reco est compatible avec ces arguments s’il devient la couche relationnelle reliant leurs signaux. Il les concurrence s’il prétend remplacer des contrôles opérant plus près de l’exécution.

Les partenariats compteront donc autant que les fonctionnalités produit. Reco a annoncé un partenariat avec ServiceNow autour de la même période que le financement, signalant une intégration avec les processus de sécurité et de flux de travail existants.

L’entreprise a également travaillé avec des fournisseurs de sécurité des données. Ces connexions peuvent aider les équipes de sécurité à comprendre non seulement quelle ressource un agent a consultée, mais aussi si cette ressource contenait des informations réglementées ou confidentielles.

Après un incident, un système coordonné devrait répondre à plusieurs questions. Quel agent a agi, qui en était responsable, quelle instruction a initié le flux de travail, quels outils ont été exécutés, quelles données ont été déplacées et quelle politique l’a arrêté ?

Il devrait également préserver les preuves sans obliger les analystes à reconstituer l’événement à travers plusieurs consoles. Cette exigence donne une opportunité aux produits fondés sur des graphes, mais seulement si leurs enregistrements restent complets et à jour.

Le modèle opérationnel compte aussi pour les employés. Les travailleurs du savoir continueront à adopter des assistants qui réduisent les tâches répétitives. Bloquer chaque outil non approuvé peut pousser davantage l’utilisation hors des systèmes surveillés.

Les organisations ont besoin d’un processus pour examiner, approuver et restreindre les accès sans faire attendre chaque expérimentation pendant un long cycle d’approvisionnement. Un registre consultable des flux de travail approuvés peut soutenir ce processus.

Les équipes peuvent appliquer la même discipline à leurs propres flux de travail IA. Elles devraient identifier les sources de données, les résultats attendus, les points d’approbation humaine et les identifiants utilisés à chaque étape.

L’opportunité de Reco est de rendre cette discipline applicable dans l’ensemble du SaaS d’entreprise. Son risque est de devenir un tableau de bord supplémentaire décrivant la prolifération des agents sans la réduire.

Trois signaux montreront si le pari de Reco fonctionne

Le prochain test consiste à déterminer si Reco transforme son financement en contrôle mesurable, intégrations défendables et adoption durable par les entreprises.

Le premier signal sera constitué par les preuves issues des déploiements en production. Reco devrait fournir des définitions plus claires des agents, des identités et des connexions risquées, accompagnées de méthodes de mesure reproductibles.

Les études de cas clients devraient expliquer l’environnement de départ, le processus de découverte, les contrôles appliqués et la réduction d’exposition obtenue. Les grands chiffres d’inventaire attirent l’attention, mais les résultats de remédiation aident les acheteurs à évaluer la valeur.

Des éléments utiles comprendraient la vitesse à laquelle les organisations identifient les agents sans propriétaire, révoquent les identifiants abandonnés ou réduisent les autorisations excessives. Ils devraient également décrire les taux de faux positifs et les applications couvertes.

Si Reco publie une méthodologie cohérente et une validation indépendante de ses clients, son argument en faveur d’un graphe de contexte deviendra plus solide. Si les futures communications reposent principalement sur des chiffres anonymes spectaculaires, les acheteurs pourraient peiner à comparer le produit.

Le deuxième signal est la convergence concurrentielle. CrowdStrike, HiddenLayer, WitnessAI, les grandes plateformes cloud et les fournisseurs d’identité ajoutent des contrôles qui se recoupent.

Reco doit démontrer que sa base SaaS produit des informations que ses concurrents ne peuvent pas facilement reproduire. Un développement plus rapide des intégrations pourrait l’y aider, notamment à mesure que les entreprises logicielles intègrent des agents dans leurs applications existantes.

La profondeur restera décisive. Reco devrait prouver que ses connecteurs peuvent observer la propriété des agents, les autorisations, les appels d’outils et les changements de politiques sur les plateformes critiques de l’entreprise.

L’entreprise doit également décider quand s’associer et quand concurrencer. L’intégration avec des fournisseurs de runtime et d’endpoint peut rendre Reco plus utile. Chercher à remplacer chaque couche de sécurité étendrait excessivement le périmètre produit et l’opposerait à des plateformes plus importantes.

Si Reco devient une source de confiance pour les relations entre agents et applications, il peut occuper une place claire dans la stack. Si les fournisseurs établis proposent une découverte comparable via des outils que les clients possèdent déjà, la différenciation de Reco se réduira.

Le troisième signal concerne la qualité commerciale après le financement. La direction prévoit que les revenus récurrents annuels triplent en 2026, mais les questions les plus importantes portent sur la rétention et l’adoption du produit.

Les acheteurs devraient surveiller si les clients existants de sécurité SaaS étendent leur usage aux contrôles des agents. Cette expansion soutiendrait l’affirmation de Reco selon laquelle sa base installée offre une voie efficace vers ce nouveau marché.

La composition des nouveaux clients comptera également. Une force continue dans les services financiers pourrait démontrer que Reco répond à des exigences de gouvernance élevées. Une adoption plus large réduirait sa dépendance à un seul secteur.

L’extension de 55 millions de dollars donne à Reco une marge de manœuvre plus longue pour l’ingénierie, le support, les partenariats et les ventes. Elle relève aussi les attentes, puisque l’entreprise a désormais déclaré 140 millions de dollars de capitaux totaux.

Le financement de Reco dans la sécurité de l’IA se comprend mieux comme un pari sur le contrôle des relations. Les agents tirent leur utilité des applications, identités, outils et données qui les entourent. Reco veut que son graphe rende ces relations visibles et gouvernables.

Cette thèse est crédible, mais le marché reste instable. Les spécialistes du runtime peuvent affirmer que les cartes d’accès ne capturent pas les comportements. Les plateformes d’endpoint peuvent soutenir que le confinement doit intervenir là où les actions sont exécutées. Les fournisseurs d’identité peuvent affirmer que l’autorisation continue relève de leur plan de contrôle.

Les acheteurs en entreprise devraient se demander quel produit peut suivre un agent sur toute la séquence, de sa création et son authentification jusqu’à son action et son retrait. Ils devraient également exiger des preuves que les politiques fonctionnent à la fois sur les applications commerciales et les agents développés en interne.

Reco a obtenu les capitaux nécessaires pour défendre son argument. Il doit désormais montrer qu’un graphe en expansion peut faire plus que révéler la prolifération des agents après coup.

Les prochains mois devraient préciser si les clients considèrent Reco comme leur couche centrale de gouvernance des agents ou comme un composant d’une stack de sécurité plus large. Quel résultat serait le plus pertinent pour les agents, les identités et le parc applicatif de votre organisation ?