Le financement de Reco pour la sécurité des agents IA ajoute 55 M$, mais un marché encombré relève la barre

Le financement de Reco pour la sécurité des agents IA a ajouté 55 millions de dollars, alors que la startup s’efforce de sécuriser des agents d’entreprise que les organisations ne parviennent pas toujours à identifier ou à contrôler. Ce financement porte le total des capitaux levés par Reco à 140 millions de dollars. Il intervient également quelques mois seulement après l’annonce d’un tour de série B de 30 millions de dollars.

La rapidité de cet investissement complémentaire constitue le véritable enjeu. Reco ne se contente plus de proposer une meilleure visibilité sur les applications software-as-a-service. L’entreprise cherche à devenir la carte de sécurité des agents, identités, applications, autorisations, données et workflows à l’échelle de l’entreprise.

Ce virage place Reco dans une compétition dense face à WitnessAI, Noma Security, des fournisseurs de cybersécurité établis et des contrôles intégrés aux principales plateformes logicielles. Reco doit désormais démontrer que son approche fondée sur le contexte peut offrir une protection mesurable, et non seulement un inventaire supplémentaire de l’activité liée à l’IA.

Le financement de Reco pour la sécurité des agents IA soutient une expansion plus large

Les nouveaux capitaux soutiennent la transformation de Reco, d’un fournisseur de sécurité SaaS en une plateforme plus vaste de sécurité des agents.

Reco a annoncé ce financement supplémentaire le 29 septembre 2026. Le tour comprend un investissement stratégique d’AT&T Ventures, avec le soutien des nouveaux investisseurs Forestay et Quadrille Capital.

Selon l’annonce de financement de l’entreprise, les fonds financeront les ventes, les partenariats, le développement des canaux de distribution et le support client. Reco indique prévoir d’étendre sa présence en Amérique du Nord et en Europe.

Le tour fait suite à un financement de 30 millions de dollars annoncé en février. Cet investissement antérieur incluait Zeev Ventures, Insight Partners, Boldstart Ventures, Workday Ventures, TIAA Ventures, S Ventures et Quadrille Capital.

Reco affirme que son financement total atteint désormais 140 millions de dollars. Le PDG et cofondateur Ofer Klein a indiqué à TechCrunch que la valorisation de l’entreprise avait plus que doublé depuis février. Il l’a décrite uniquement comme se situant dans le haut des centaines de millions.

Klein a également déclaré que les revenus annuels récurrents avaient atteint plusieurs dizaines de millions de dollars. Il prévoit qu’ils tripleront en 2026, bien que cette prévision n’ait pas été vérifiée de manière indépendante.

L’entreprise compte plus de 100 clients, selon Klein. Les organisations de services financiers représentent environ 40 % de son activité, faisant des entreprises réglementées un élément important de son plan de croissance.

Ces clients achètent plus qu’une passerelle IA conventionnelle. Le produit central de Reco est un graphe de contexte, qui relie les agents aux applications, identités, autorisations et données qui les entourent.

Un graphe de contexte est une carte des relations au sein d’un environnement technologique, mise à jour en continu. Il aide une équipe de sécurité à comprendre non seulement qu’un agent existe, mais aussi à quelles ressources cet agent peut accéder.

Cette distinction est importante, car un agent peut hériter d’accès provenant d’un utilisateur, d’un compte de service, d’une application ou d’un outil connecté. Un assistant apparemment peu risqué peut devenir dangereux lorsque ces privilèges hérités traversent plusieurs systèmes.

Reco affirme que sa plateforme peut identifier les agents via des intégrations directes aux applications, des signaux de navigateur et l’activité réseau. L’entreprise affirme également pouvoir inspecter les prompts et les appels d’outils, puis aider les administrateurs à supprimer les accès inutiles.

En juin, Reco a officiellement lancé sa plateforme étendue de sécurité des agents. À ce moment-là, l’entreprise indiquait compter plus de 230 intégrations d’applications et 1 000 contrôles de détection.

L’entreprise fait désormais la promotion de plus de 280 intégrations. Cette couverture élargie étaye l’argument de Reco selon lequel le contexte applicatif lui procure un avantage sur les produits concentrés uniquement sur le trafic des modèles.

L’implication d’AT&T ajoute un poids stratégique, car l’entreprise de télécommunications est à la fois investisseur et client. L’investissement d’un client peut signaler une confiance dans la valeur d’un produit, mais il ne constitue pas une preuve indépendante d’une demande plus large.

Le tour finance donc une expansion précise plutôt qu’une simple continuité. Reco parie que son expérience dans la sécurité SaaS lui fournit la base adéquate pour gouverner les agents dans des systèmes d’entreprise connectés.

Ces capitaux relèvent également les attentes. Reco doit étendre ses intégrations, son support client et sa distribution tout en maintenant la crédibilité de ses affirmations techniques sur de nombreuses plateformes d’agents différentes.

Pourquoi la prolifération des agents en entreprise est devenue un problème de sécurité urgent

Le problème ne réside pas simplement dans le fait que les entreprises déploient davantage d’agents, mais dans la capacité de ces agents à agir au moyen d’autorisations assemblées à travers plusieurs systèmes.

Un agent IA est un logiciel capable de planifier ou d’exécuter des actions afin d’atteindre un objectif. À la différence d’un chatbot qui produit uniquement du texte, un agent peut appeler des outils, récupérer des enregistrements, mettre à jour des applications ou déclencher des workflows.

Cette capacité modifie l’équation de sécurité. Les inventaires d’applications traditionnels suivent généralement les logiciels, utilisateurs, appareils et comptes de service comme des objets distincts. Les agents peuvent relier ces catégories tout en opérant sous une autorité déléguée.

Un employé peut autoriser un agent à lire ses e-mails, rechercher du stockage cloud, mettre à jour des dossiers clients et envoyer des messages. Chaque autorisation peut sembler raisonnable isolément, alors que leur combinaison crée une exposition bien plus importante.

Le risque augmente lorsque la responsabilité est floue. Les agents peuvent être achetés en tant que produits autonomes, développés en interne ou activés au sein de logiciels déjà utilisés par une entreprise.

Un assistant Salesforce, un copilot Microsoft 365, une application Slack ou une extension de navigateur peuvent introduire un comportement de type agent sans événement d’approvisionnement distinct. Les équipes de sécurité peuvent ne découvrir cette capacité qu’après le début de son utilisation par les employés.

C’est cette situation qui est souvent décrite comme une prolifération des agents. Le terme couvre une croissance non maîtrisée du nombre d’agents, de leurs connexions et des autorisations qu’ils accumulent.

Reco affirme qu’un de ses clients du Fortune 100 disposait de 21 000 agents dont l’organisation n’avait pas connaissance. Ce chiffre provient de l’entreprise et n’a pas reçu de validation technique indépendante.

Klein a également décrit un client des services financiers chez lequel Reco aurait identifié un agent créé par un ancien employé. Cet agent pouvait accéder à Salesforce et partager des informations avec un domaine extérieur à la visibilité de l’entreprise.

Ce scénario illustre pourquoi un inventaire seul ne suffit pas. Une équipe de sécurité doit savoir qui a créé un agent, quelles informations d’identification il utilise et ce qui se passe lorsque son propriétaire quitte l’organisation.

Elle doit aussi comprendre les accès indirects. Un agent peut ne pas disposer d’une autorisation directe pour ouvrir une base de données sensible, tout en obtenant un accès équivalent par le biais d’une autre application ou d’un workflow.

Le postulat de Reco est que les relations révèlent ces risques. Son graphe relie les personnes, comptes, agents, applications, autorisations, données et activités observées afin que les défenseurs puissent évaluer un chemin d’accès complet.

Ce modèle s’apparente à une gouvernance des identités appliquée aux logiciels autonomes. Au lieu de se demander uniquement si une personne doit détenir une autorisation, le système se demande si un agent doit l’exercer.

La différence devient importante lorsque les agents opèrent en continu. Un humain peut ouvrir un dossier client plusieurs fois au cours d’une journée de travail. Un agent peut examiner des milliers de dossiers ou exécuter des actions répétées en quelques minutes.

La vitesse réduit le temps dont dispose une équipe de sécurité pour réagir. Elle augmente également l’impact potentiel d’une instruction erronée, d’un identifiant compromis ou d’un prompt malveillant.

L’injection de prompt ajoute une autre couche de risque. Cette attaque place des instructions hostiles dans un contenu lu par un système IA, dans le but de rediriger son comportement ou d’exposer des informations.

Les agents y sont particulièrement exposés, car ils consomment des données externes et disposent d’outils. Une instruction injectée devient plus lourde de conséquences lorsque le système qui la reçoit peut envoyer des e-mails, modifier des fichiers ou appeler une interface de programmation d’application.

Des chercheurs étudiant le déploiement des agents ont documenté des faiblesses persistantes lors de tests adverses. Une étude de sécurité à grande échelle a analysé 1,8 million de tentatives d’injection de prompt soumises dans le cadre d’une compétition publique.

Les chercheurs ont rapporté plus de 60 000 attaques réussies ayant entraîné des violations de politiques. Ces résultats comprenaient des accès non autorisés aux données, des actions financières interdites et des manquements à la conformité réglementaire.

Un produit de sécurité commercial ne peut pas éliminer chaque défaillance au sein d’un modèle sous-jacent. Il peut toutefois restreindre les ressources auxquelles le modèle peut accéder et surveiller les actions qui s’ensuivent.

Cela crée une demande pour des outils couvrant la découverte, la gestion des autorisations, la surveillance à l’exécution et la réponse. Cela explique aussi pourquoi les acheteurs sont confrontés à des promesses qui se chevauchent de la part d’une liste croissante de fournisseurs.

Pour les équipes qui construisent des systèmes IA autour de documents internes, la conception des accès compte autant que la qualité de la récupération. Une base de connaissances consultable ne reste sûre que lorsque son automatisation respecte les limites de propriété et d’autorisation.

La pression immédiate repose sur les responsables de la sécurité des systèmes d’information. Ils doivent soutenir une adoption rapide de l’IA sans permettre à chaque département de créer sa propre structure d’accès indépendante.

Les développeurs ressentent également cette pression. Des exigences de sécurité ajoutées après le déploiement peuvent les contraindre à repenser les appels d’outils, les flux d’identité, les points de contrôle d’approbation et les journaux d’audit.

Les acheteurs en entreprise ont donc besoin de preuves qu’une plateforme de sécurité des agents peut découvrir de véritables déploiements sans bloquer l’expérimentation légitime. Le nouveau financement de Reco lui donne davantage de ressources pour rechercher cet équilibre.

Le graphe de contexte de Reco fait face à un marché de la sécurité encombré

Le principal adversaire de Reco n’est pas une entreprise en particulier, mais un marché dense offrant des promesses similaires par différentes voies techniques.

Certains fournisseurs surveillent le trafic circulant entre les utilisateurs, les modèles et les applications. D’autres mettent l’accent sur la protection à l’exécution, les contrôles des identités non humaines, les tests de modèles, la sécurité des données ou la gestion de la posture applicative.

Reco aborde le problème par les relations. Son graphe est conçu pour révéler comment un agent se connecte aux identités, logiciels, autorisations et informations dans l’ensemble de l’entreprise.

L’entreprise affirme que cette couverture SaaS existante lui permet d’ajouter un contexte qu’une passerelle IA plus restreinte pourrait manquer. Une passerelle observe généralement les requêtes traversant un point de contrôle particulier, mais l’activité peut se produire en dehors de ce parcours.

Les extensions de navigateur, assistants intégrés et intégrations directes aux applications compliquent le modèle de la passerelle. Une organisation peut avoir besoin de plusieurs méthodes de découverte pour voir les agents introduits par différents canaux.

Reco indique compléter ses intégrations directes avec des signaux de navigateur et de réseau. Cette combinaison vise à identifier l’activité au-delà des applications prises en charge tout en préservant le contexte plus riche des systèmes connectés.

L’approche semble différenciante, mais les concurrents poursuivent des formes de visibilité adjacentes. WitnessAI surveille les interactions IA en entreprise et a étendu ses contrôles pour couvrir les agents, les outils et les serveurs Model Context Protocol.

Model Context Protocol, souvent appelé MCP, est une norme permettant de connecter des systèmes IA à des sources de données et à des outils. Elle simplifie l’intégration, mais chaque connexion peut introduire une nouvelle limite d’autorisation et de confiance.

WitnessAI a levé 58 millions de dollars dans le cadre d’un financement stratégique en janvier 2026. Ses contrôles IA pour entreprises visent à observer quelles données entrent dans les systèmes d’IA et ce que les agents font au nom des utilisateurs.

Noma Security représente une autre approche. L’entreprise positionne son produit sur le développement d’IA, l’utilisation des applications et la sécurité des agents, avec des contrôles couvrant les modèles, les données, l’infrastructure et les comportements à l’exécution.

Noma a annoncé une levée de série B de 100 millions de dollars en juillet 2025. Son expansion dans la sécurité a montré qu’un intérêt substantiel des investisseurs avait atteint cette catégorie avant le dernier tour de table de Reco.

Les fournisseurs établis comptent également. CrowdStrike et d’autres fournisseurs de sécurité des terminaux peuvent observer les processus et les comportements sur les appareils où opèrent les agents.

Les entreprises spécialisées dans l’identité peuvent étendre leurs produits d’identité non humaine aux identifiants des agents. Les fournisseurs de cloud peuvent appliquer des autorisations au sein de leurs plateformes, tandis que les grands éditeurs SaaS peuvent ajouter des contrôles autour de leurs propres assistants.

Ces acteurs établis disposent de canaux de distribution, de télémétrie déjà déployée et de budgets de sécurité existants. Les start-ups doivent prouver que leur visibilité interplateforme apporte suffisamment de valeur pour justifier une couche de gestion supplémentaire.

L’argument le plus solide de Reco est qu’aucun fournisseur d’application unique ne voit l’ensemble de l’écosystème de l’entreprise. Un contrôle intégré à Salesforce ne peut pas cartographier pleinement ce qui se produit lorsqu’un agent accède à Microsoft 365, Slack ou un outil externe.

Le même argument s’applique aux frontières du cloud. Les entreprises utilisent souvent plusieurs plateformes d’infrastructure en parallèle de centaines de produits SaaS, ce qui fragmente la supervision.

Un graphe peut relier ces fragments si ses intégrations capturent suffisamment d’informations fiables. Cette condition introduit le défi technique central de Reco.

Le graphe n’est utile qu’à la hauteur de ses données. Des applications manquantes, des autorisations obsolètes, une propriété ambiguë ou des journaux d’activité incomplets peuvent produire une image trompeuse du risque.

Reco affirme pouvoir ajouter de nouvelles intégrations en quelques jours. La rapidité du travail d’intégration favorise la couverture, mais les acheteurs doivent examiner la profondeur de chaque connecteur.

Un connecteur qui répertorie les comptes apporte moins de valeur en matière de sécurité qu’un connecteur qui identifie les autorisations déléguées, les actions des agents et les comportements inhabituels. Le nombre d’intégrations ne décrit pas ces différences.

Le langage commun du marché complique encore l’évaluation. De nombreuses entreprises promettent désormais la découverte des agents, la surveillance continue, l’accès à privilèges minimaux, des contrôles à l’exécution et la sécurité MCP.

Le principe du moindre privilège consiste à n’accorder que les accès nécessaires à une tâche donnée. L’idée est familière, mais son application aux agents adaptatifs reste difficile, car leurs actions peuvent varier selon le contexte.

Les fournisseurs doivent traduire des principes communs en contrôles applicables. Ils doivent montrer quelle action risquée ils détectent, quelle autorisation ils retirent et avec quelle rapidité ils contiennent une menace.

Le graphe de contexte de Reco offre un mécanisme plausible pour répondre à ces questions. Le financement n’établit pas qu’il y répond mieux que les systèmes concurrents.

Cet écart entre une architecture cohérente et des résultats vérifiés déterminera la prochaine étape de l’entreprise. Reco dispose de suffisamment de capitaux pour viser l’échelle, mais la densité concurrentielle de la catégorie empêche le financement de constituer un avantage défendable durable.

Ce que les chiffres de Reco ne prouvent pas encore

Reco a présenté de solides signaux de croissance, mais ses affirmations les plus marquantes concernant le déploiement et les performances proviennent encore de l’entreprise elle-même.

Le nombre de clients communiqué, la fourchette de revenus récurrents, la croissance attendue du chiffre d’affaires et la valorisation non divulguée contribuent tous à expliquer l’intérêt des investisseurs. Aucun ne fournit une mesure complète de l’efficacité en matière de sécurité.

La croissance du chiffre d’affaires peut montrer que les entreprises sont prêtes à payer pour un produit. Elle ne révèle pas si le produit identifie chaque agent, empêche les usages abusifs ou réduit les coûts liés aux incidents.

La découverte de 21 000 agents est tout aussi convaincante, mais difficile à interpréter sans méthodologie. Ce chiffre peut inclure des assistants intégrés, des automatisations, des flux de travail, des intégrations ou d’autres objets logiciels présentant différents niveaux de risque.

Une évaluation utile expliquerait comment Reco définit un agent. Elle distinguerait également les agents actifs en production des systèmes de test, des configurations abandonnées et des fonctionnalités applicatives à faible risque.

Les faux positifs méritent autant d’attention. Si un produit qualifie trop de flux de travail ordinaires d’agents dangereux, les équipes de sécurité risquent de perdre du temps à enquêter sur des alertes de faible valeur.

Les faux négatifs posent le problème inverse. Un connecteur incomplet ou un chemin d’activité chiffré peut laisser l’agent le plus sensible invisible tout en créant un tableau de bord rassurant.

Les acheteurs devraient demander comment Reco valide la découverte dans des applications qui exposent des journaux et des modèles d’autorisations différents. Ils devraient également examiner la manière dont le produit traite les agents développés en interne avec des outils personnalisés.

La remédiation introduit une autre incertitude. Découvrir un accès excessif est utile, mais le réduire sans perturber le travail exige une compréhension précise de la propriété et du contexte métier.

Un agent utilisé pour les rapports de fin de mois peut avoir besoin d’un large accès en lecture pendant une période définie. Retirer cet accès automatiquement pourrait interrompre un processus critique.

Reco affirme que son graphe de contexte aide à prioriser les risques et à permettre une remédiation précise. Les entreprises devraient tester cette affirmation face à des flux de travail complexes plutôt que de considérer le graphe comme un moteur de politique complet.

La même prudence s’applique à l’inspection des prompts et des appels d’outils. La surveillance d’un prompt peut révéler des violations évidentes de politique, mais l’intention peut rester ambiguë.

Un agent peut assembler une séquence nuisible à partir de plusieurs actions individuellement acceptables. Une couche de sécurité doit corréler les comportements dans le temps, entre les outils, les comptes et les applications.

Le contenu chiffré et les règles de résidence des données peuvent également limiter l’inspection. Les organisations réglementées peuvent interdire à un fournisseur de sécurité de conserver des prompts sensibles ou le contenu de documents.

La concentration de Reco dans les services financiers pourrait devenir un avantage, car ces clients imposent des exigences de contrôle élevées. Elle pourrait aussi accroître la complexité de mise en œuvre et l’examen des ventes.

Les investisseurs stratégiques présentent un autre compromis. AT&T peut aider à valider les exigences des entreprises et soutenir la distribution, mais un client important ne garantit pas une adoption reproductible dans tous les secteurs.

Le marché encombré accroît également le risque commercial. Les entreprises peuvent retarder leurs achats pendant qu’elles comparent des produits spécialisés aux nouvelles capacités des fournisseurs existants.

Elles peuvent aussi consolider les contrôles sous un fournisseur de sécurité plus important. Une start-up doit alors démontrer soit une couverture supérieure, soit un rôle d’intégration clair au sein d’une pile de sécurité établie.

Les fournisseurs de plateformes pourraient réduire l’opportunité en améliorant leur gouvernance native. Microsoft, Salesforce, ServiceNow, Google et d’autres éditeurs contrôlent déjà d’importantes surfaces de déploiement des agents.

Les contrôles natifs manquent souvent de contexte interplateforme, mais ils peuvent répondre aux besoins fondamentaux des clients sans ajouter un fournisseur distinct. La valeur de Reco doit rester visible après l’amélioration de ces fonctionnalités de base.

La question des frontières de la catégorie se pose également. La sécurité des agents recoupe la sécurité des identités, la sécurité des données, la gestion de la posture SaaS, la sécurité applicative et la gouvernance de l’IA.

Ce chevauchement aide Reco à s’adresser à plusieurs budgets, mais crée davantage de concurrence. Les acheteurs peuvent avoir du mal à déterminer quelle équipe doit gérer l’approvisionnement et quel produit existant doit être remplacé.

Reco doit éviter de devenir un tableau de bord supplémentaire qui identifie le risque mais renvoie la remédiation ailleurs. Sa plateforme devra relier les constats à des changements d’accès pratiques et à des flux de travail de gestion des incidents.

Des études de cas indépendantes renforceraient les affirmations de l’entreprise. Des éléments probants utiles incluraient la couverture de déploiement, le délai de détection d’agents inconnus, les taux de faux positifs et les réductions d’autorisations effectivement réalisées.

Les acheteurs de solutions de sécurité devraient aussi exiger des tests adversariaux. Une évaluation contrôlée peut mesurer si Reco détecte l’injection de prompts, le mauvais usage d’outils, l’abus d’identifiants et les mouvements de données entre applications.

Le financement donne à l’entreprise le temps de constituer ces preuves. Il n’en élimine pas la nécessité.

Le dernier tour de table de Reco doit donc être interprété comme un pari sur le calendrier du marché et l’architecture. Le verdict sur l’efficacité opérationnelle reste ouvert.

Les acheteurs en entreprise ont besoin de résultats, pas d’un inventaire supplémentaire d’agents

La plateforme de sécurité des agents gagnante reliera la découverte à des contrôles applicables et à des réductions mesurables du risque d’accès.

Un inventaire est le point de départ, car une entreprise ne peut pas gouverner des agents qu’elle ne voit pas. Pourtant, la découverte ne devient utile que lorsqu’elle modifie une décision de sécurité.

Une plateforme utile devrait identifier le propriétaire d’un agent, son objectif, ses identifiants, ses outils, les données auxquelles il peut accéder et ses actions récentes. Elle devrait aussi montrer comment ces éléments se combinent pour former un chemin risqué.

Ce chemin compte davantage qu’une vulnérabilité isolée. Un agent avec une faible limite de sécurité des prompts présente un niveau de risque, tandis que le même agent doté d’autorisations financières en présente un autre.

Les acheteurs devraient commencer les évaluations par des scénarios concrets. L’un d’eux pourrait impliquer le départ d’un employé alors qu’un agent conserve un accès via les identifiants délégués de cette personne.

Un autre pourrait vérifier si un agent de support peut récupérer des dossiers clients restreints via un système de connaissances connecté. Un troisième pourrait mesurer le comportement après qu’un document malveillant injecte de nouvelles instructions.

Le produit devrait expliquer à la fois la détection et la réponse pour chaque cas. Un score de risque vague apporte moins de valeur qu’une trace montrant l’identité concernée, la ressource, l’autorisation et l’action recommandée.

Les équipes de sécurité devraient également examiner comment une plateforme sépare l’observation de l’application des contrôles. Le confinement automatisé immédiat convient à certains événements, tandis que d’autres exigent une approbation humaine.

Un agent tentant d’envoyer des données sensibles vers un domaine inconnu peut justifier un blocage automatique. Un nouveau flux de travail interne demandant un accès en lecture plus large peut au contraire nécessiter un examen.

Les développeurs ont besoin de retours utiles du même système. Un contrôle qui ne signale les problèmes à la sécurité qu’après le déploiement encourage les erreurs répétées et ralentit la remédiation.

Des vérifications plus précoces peuvent signaler des périmètres d’outils excessifs, un stockage non sécurisé des identifiants ou l’absence de barrières d’approbation avant qu’un agent n’atteigne la production. La surveillance à l’exécution peut ensuite détecter les comportements que les tests en phase de conception n’ont pas relevés.

Cette combinaison pousse les fournisseurs à couvrir tout le cycle de vie sans revendiquer une protection totale. Aucune plateforme ne peut garantir qu’un système adaptatif se comportera toujours de manière sûre.

Le graphe de Reco pourrait soutenir ce cycle de vie en maintenant le contexte entre le développement et l’exploitation. L’entreprise doit encore démontrer avec quelle constance ce modèle fonctionne en dehors de ses intégrations les plus solides.

Les acheteurs devraient comparer l’approche de Reco aux produits de passerelle, d’identité, de sécurité des terminaux et de sécurité des données déjà présents dans leur environnement. La question pertinente n’est pas de savoir quel fournisseur emploie la terminologie la plus large.

La question est de savoir quelle combinaison comble une lacune de contrôle documentée. Dans certains environnements, Reco pourrait devenir la couche de coordination entre les applications.

Dans d’autres, les contrôles natifs et une plateforme d’identité existante peuvent couvrir les risques les plus prioritaires. Un produit spécialisé à l’exécution peut être plus approprié lorsque l’exposition principale se situe dans des agents personnalisés.

L’approvisionnement devrait donc suivre un inventaire interne des agents, et non le précéder. Les organisations doivent identifier quels systèmes peuvent agir, quelle autorité ils utilisent et quelles informations ils peuvent atteindre.

Cet exercice peut également révéler des lacunes de responsabilité. La sécurité, l’ingénierie, la gouvernance des données, le juridique et les administrateurs d’applications gèrent souvent différentes parties d’un même flux de travail d’agent.

Une plateforme peut relier des objets techniques, mais elle ne peut pas résoudre seule un modèle de responsabilité flou. Les entreprises ont toujours besoin de politiques pour l’approbation, la surveillance, la réponse aux incidents et le retrait de service.

Le démantèlement mérite une attention particulière. Les agents peuvent survivre à leurs projets d’origine par le biais de comptes de service non supervisés, de jetons, de scripts et de connexions applicatives.

L’exemple d’ancien employé rapporté par Reco illustre ce risque. Une entreprise devrait pouvoir révoquer ou transférer chaque autorisation liée à un agent lorsqu’un propriétaire change de fonction.

Les fournisseurs peuvent se démarquer en facilitant la vérification de ces contrôles de cycle de vie. Les preuves devraient être exportables pour les auditeurs et compréhensibles par les responsables d’applications.

Le marché récompensera probablement les produits qui produisent des résultats opérationnels clairs. Parmi les exemples : moins d’agents inconnus, moins d’autorisations excessives, des enquêtes plus rapides et des délais de confinement réduits.

Les annonces de financement ne peuvent pas se substituer à ces résultats. L’extension de 55 millions de dollars de Reco crée une occasion de les publier et de rivaliser sur autre chose que l’étendue des fonctionnalités.

Trois signaux mettront à l’épreuve le pari de Reco sur la sécurité des agents

La prochaine phase de Reco sera jugée sur la profondeur de ses intégrations, des résultats clients vérifiables de manière indépendante et sa réponse à la concurrence des plateformes.

Le premier signal sera la capacité de Reco à transformer l’augmentation de son nombre d’intégrations en contrôles plus approfondis. Les nouveaux connecteurs devraient révéler la propriété des agents, les autorisations déléguées, l’utilisation des outils et l’activité inter-applications.

Un nombre plus élevé d’intégrations ne renforcera l’argument de Reco que si les clients obtiennent un contexte utile grâce à ces connexions. Une couverture d’inventaire superficielle affaiblirait la différenciation de l’entreprise.

Le deuxième signal sera constitué par les preuves issues des déploiements en entreprise. Reco devrait documenter la manière dont ses clients ont réduit le nombre d’agents inconnus, les voies d’accès dangereuses, le temps d’enquête ou les données exposées.

Les témoignages clients doivent inclure suffisamment de méthodologie pour distinguer les résultats mesurables des affirmations promotionnelles. Une validation indépendante aurait plus de poids que des exemples anonymes ou des chiffres agrégés.

Le troisième signal concernera la réponse des concurrents et des fournisseurs de plateformes. WitnessAI, Noma Security, les fournisseurs d’identité, les fournisseurs de solutions endpoint et les grandes entreprises logicielles progressent tous sur des terrains adjacents.

Si les acheteurs adoptent Reco aux côtés de ces produits, son graphe pourrait établir un rôle de coordination distinct. Si les fonctionnalités natives absorbent les mêmes cas d’usage, Reco subira une pression accrue pour démontrer une plus grande profondeur.

Les partenariats offriront un premier indice. Le travail de Reco avec ServiceNow et le soutien d’AT&T suggèrent une stratégie fondée sur la distribution en entreprise et l’intégration aux workflows.

L’exécution compte désormais davantage que la création d’une catégorie. Le marché de la sécurité des agents compte déjà plusieurs fournisseurs très financés aux messages qui se chevauchent.

Reco a établi de manière crédible que les relations SaaS et les autorisations héritées méritent davantage d’attention. Son financement donne à l’entreprise les ressources nécessaires pour porter cette thèse dans de grands environnements réglementés.

La question non résolue est de savoir si la cartographie du contexte peut devenir un avantage en matière d’application des contrôles. Un graphe qui se contente de visualiser la prolifération des agents aura du mal à s’imposer sur un marché rempli de tableaux de bord.

Un graphe qui identifie systématiquement les autorisations cachées, explique l’exposition et permet une remédiation sûre serait plus défendable. C’est la norme que les clients et les concurrents de Reco vont désormais mettre à l’épreuve.

Pour les développeurs et les acheteurs en entreprise, l’étape pratique consiste à suivre les preuves plutôt que la dynamique de financement. Demandez aux fournisseurs de démontrer la découverte, l’analyse des autorisations, le confinement et les contrôles de cycle de vie sur vos applications réelles. Comparez ces résultats avec les protections déjà disponibles dans vos systèmes d’identité, cloud et endpoint. Le financement de Reco pour la sécurité des agents IA fait de l’entreprise un concurrent mieux doté en ressources, mais ne tranche pas le marché. Au cours du prochain trimestre, surveillez la profondeur de ses connecteurs, les résultats clients publiés et les partenariats concurrentiels. Ces signaux montreront si Reco construit une couche de contrôle durable ou rejoint un marché de l’inventaire de plus en plus encombré.