Micha Rave, PDG et cofondateur de Hush Security – Série d’interviews

Micha Rave, PDG et cofondateur de Hush Security, est un dirigeant expérimenté en cybersécurité et technologie dont la carrière couvre l’ingénierie logicielle, la gestion de produit, le réseau d’entreprise, la sécurité cloud et l’identité. Avant de co‑fonder Hush Security en 2024, il a passé plus de cinq ans chez Proofpoint en tant que Senior Director of Product Management for Cloud Security, où il était responsable des gammes de produits Zero Trust Network Access (ZTNA) et Secure Web Gateway (SWG). Il a auparavant occupé le poste de VP of Product Management chez Meta Networks, se concentrant sur le réseau d’entreprise et la sécurité, et a occupé des fonctions de direction produit et ingénierie chez HARMAN International, Redbend, SanDisk, Hola, Jungo et Elbit Systems. Son parcours combine le développement logiciel pratique à plus de deux décennies d’expérience dans la construction et la commercialisation de produits de sécurité, de réseau, de virtualisation et de technologies embarquées.

Hush Security est une société de cybersécurité axée sur la protection des agents IA et d’autres identités non humaines en remplaçant les identifiants à longue durée de vie et les secrets statiques par un accès basé sur l’identité et contrôlé par des politiques. Sa plateforme découvre les agents IA, y compris les agents fantômes et ceux développés en interne, leur attribue des identités vérifiables et régule leurs interactions avec les systèmes d’entreprise à l’aide d’autorisations limitées, just‑in‑time, de politiques centralisées et de journaux d’activité auditable. L’entreprise a été fondée par des vétérans de la sécurité issus de l’équipe derrière Meta Networks, que Proofpoint a acquise en 2019. En juillet 2026, Hush a levé une Série A de 30 millions de dollars avec Akamai Technologies rejoignant en tant qu’investisseur stratégique aux côtés de Battery Ventures et YL Ventures, portant le financement total à 41 millions de dollars alors que l’entreprise étend sa technologie pour gouverner les agents IA d’entreprise et les infrastructures non humaines.

Avant de fonder Hush Security, vous avez passé des années à concevoir et diriger des produits de sécurité, y compris la sécurité cloud chez Proofpoint. Qu’avez‑vous observé sur le marché qui vous a convaincu qu’il était nécessaire de créer Hush, et comment cette thèse originale a‑t‑elle évolué avec la montée rapide de l’IA agentique ?

Chez Proofpoint, nous avons observé que les entreprises résolvaient l’identité humaine tandis que tout ce qui était non humain fonctionnait encore avec des secrets statiques. Comptes de service, charges de travail, pipelines, tous s’authentifiant avec des clés que personne ne possédait, qui n’expiraient jamais. L’industrie a répondu avec de meilleurs coffres. C’est un meilleur coffre-fort, pas une solution.

La thèse fondatrice était de passer l’accès non humain des secrets à l’identité. Identité de charge de travail vérifiable, identifiants à courte durée de vie émis just‑in‑time, politique appliquée en ligne. Aucun réécriture de code.

L’IA agentique a rendu cela urgent. Un agent est un NHI qui raisonne et décide à l’exécution quels outils appeler. Lui donner une clé statique, c’est accorder à un logiciel autonome un accès permanent à la production, et les agents sont déployés en dehors de tout processus de modification ; un développeur configure un serveur MCP mardi et il touche les données client vendredi.

La thèse n’a pas changé. L’étendue a changé. L’accès basé sur l’identité était la bonne réponse pour les charges de travail. Pour les agents, c’est la seule solution viable : connaître chaque agent existant, accorder à chacun la moindre agence par défaut, et auditer chaque action. Les humains ont un IdP. Les agents en ont également besoin et c’est Hush.

Hush soutient que les agents IA d’entreprise devraient disposer de leurs propres identités et permissions déléguées plutôt que d’hériter simplement des droits d’accès des humains qui les utilisent. Pourquoi les systèmes traditionnels de gestion des identités et des accès (IAM) peinent-ils avec les agents autonomes, et que faut‑il changer ?

Le cas évident est un agent agissant pour un utilisateur. Le cas plus difficile est un agent sans aucun utilisateur : une tâche planifiée, un répondant SOC autonome, un pipeline qui raisonne et agit de façon autonome. Il n’y a personne d’où déléguer, si bien que les équipes se rabattent sur le seul outil dont elles disposent, un compte de service statique avec des permissions étendues et une clé qui n’expire jamais. C’est le même modèle de secret partagé qui se fissure depuis une décennie, désormais attaché à un logiciel qui improvise.

Les systèmes à l’autre bout aggravent la situation. La plupart des API internes, bases de données et serveurs MCP n’effectuent pas de véritable autorisation. Ils vérifient simplement que vous détenez un jeton valide, pas ce que vous êtes autorisé à faire avec. La possession équivaut à la permission.

Ce qui doit changer : chaque agent reçoit sa propre identité, émise cryptographiquement, qu’un humain soit ou non derrière lui. L’accès est accordé par action, à courte durée de vie et limité, avec une politique appliquée en ligne plutôt que confiée au système cible. Lorsqu’il y a un utilisateur, les permissions de l’agent sont l’intersection de ce que l’utilisateur peut faire et de ce que cet agent est autorisé à faire pour cette tâche. Lorsqu’il n’y en a pas, l’identité et la politique propres à l’agent constituent l’intégralité du récit. Les humains ont le principe du moindre privilège. Les agents ont besoin du principe de moindre agence.

Vous utilisez le concept de “least agency” lorsque vous discutez de la sécurité de l’IA. En quoi l’agence minimale diffère‑t‑elle du principe traditionnel de cybersécurité du moindre privilège, et comment les organisations peuvent‑elles déterminer exactement ce qu’un agent IA doit être autorisé à faire pour une tâche particulière ?

Les agents n’ont pas de comportement fixe. Donner à l’un un accès en lecture à un CRM et un accès en écriture à l’e‑mail, ce n’est pas accorder deux permissions, c’est accorder chaque chemin entre les deux. Le moindre privilège délimite ce qu’un agent peut toucher. Il ne dit rien sur ce qu’il doit en faire.

Le principe de la moindre agence ajoute la dimension manquante : quelles actions, pour quelle tâche, immédiatement. Un agent qui triage les tickets doit pouvoir lire et commenter. Il n’a pas besoin de fermer, de supprimer ou de toucher à la facturation, même si le jeton le permet. Lorsque la tâche se termine, l’accès se termine.

Déterminer ce qui est autorisé commence par l’observation, pas par des suppositions. Exécutez l’agent, observez ce qu’il appelle réellement, et laissez cela définir la ligne de base. Ensuite, restreignez en vous basant sur trois paramètres : la tâche pour laquelle il existe, l’utilisateur pour lequel il agit (jamais plus que ce que cet utilisateur pourrait faire) et le rayon d’impact de chaque action, car publier un commentaire et effectuer un paiement ne devraient pas partager le même chemin d’approbation.

Le principe du moindre privilège détermine qui reçoit les clés. Le principe de la moindre agence décide ce qu’ils peuvent faire une fois à l’intérieur.

Nous « prêtons » souvent notre identité à notre agent, mais nous ne voulons pas que l’agent dispose du même niveau d’autorisations que nous – c’est la définition de la moindre agence.

Hush a récemment levé une $30 million de série A, portant le financement total à 41 millions de dollars, avec Akamai qui rejoint en tant qu’investisseur stratégique aux côtés de Battery Ventures et YL Ventures. Que apporte l’implication d’Akamai au‑delà du capital, et comment prévoyez‑vous que ce partenariat influence l’expansion de Hush dans la sécurité des agents IA d’entreprise ?

Akamai se trouve sur le chemin du trafic de la plupart des entreprises du monde, et c’est exactement là que la sécurité des agents doit être appliquée. Vous ne gérez pas un agent depuis un tableau de bord après coup. Vous le gérez en ligne, au moment où il appelle un outil ou une API. Akamai a construit son activité sur ce modèle.

Au‑delà du capital, ils apportent trois éléments : une distribution aux RSSI qui se demandent déjà comment contrôler les agents et le trafic MCP ; la validation que l’identité des agents constitue une véritable catégorie, et non une simple fonctionnalité ; et des décennies d’expérience dans la sécurisation du trafic machine‑à‑machine à l’échelle mondiale, ce que le trafic agent‑à‑outil est sur le point de devenir.

Le Model Context Protocol (MCP) devient rapidement une couche importante pour connecter les agents IA aux outils et aux données d’entreprise. Du point de vue de la sécurité, quels nouveaux risques le MCP introduit‑il, et comment les organisations devraient‑elles envisager l’identité et l’autorisation entre l’agent, le serveur MCP et la ressource sous‑jacente ?

Le MCP a rendu la connexion d’un agent à un outil triviale. C’est le risque. Un développeur ajoute un serveur à un fichier de configuration et le modèle peut désormais lire Jira, interroger une base de données ou envoyer des courriels. Aucun examen, aucun inventaire, aucune politique. La sécurité ne le découvre que lorsqu’un problème survient.

Il y a maintenant trois nouveaux problèmes :

1. MCP fantôme – personne ne sait combien de serveurs sont en fonctionnement ni ce qu’ils touchent.
2. Prolifération des identifiants – la plupart des serveurs s’authentifient avec un jeton statique qui accorde l’ensemble de la surface, de sorte que l’agent obtient tout ce que le jeton peut faire.
3. La chaîne effondrée – la ressource ne voit que les informations d’identification du serveur MCP, elle ne peut donc pas déterminer quel agent, agissant pour quel utilisateur, a effectué l’appel. L’identité doit être à la base de chaque interaction, l’accès doit être éphémère, limité et basé sur les autorisations de l’agent et de l’utilisateur.

Hush a été initialement conçu autour de l’idée que les secrets statiques et les identifiants à longue durée de vie constituent une base défaillante pour l’accès des machines. Puisque la plupart des infrastructures d’entreprise reposent encore largement sur des clés API, des jetons et d’autres secrets, comment les entreprises peuvent‑elles passer de manière réaliste à un accès basé sur l’identité, à courte durée de vie, sans reconstruire l’ensemble de leur pile technologique ?

Vous ne reconstruisez pas. Personne qui affirme le contraire n’a jamais rencontré une entreprise. La plupart de ce que nous protégeons précède l’expression identité non‑humaine, et cela ne sera pas réécrit.

Donc nous ne le demandons pas. Hush se déploie sans modifications de code et se place dans le chemin d’accès. La première étape est la découverte : chaque secret, qui l’utilise, ce qu’il atteint, ce qu’il fait réellement à l’exécution. La plupart des entreprises n’ont jamais vu cette vue d’ensemble.

Ensuite, c’est un parcours, pas une migration. La découverte montre quels secrets sont obsolètes, sur‑autorisés ou à haut risque. Corrigez‑les d’abord. Puis remplacez les clés statiques par des identifiants à courte durée de vie, émis par l’identité, un système à la fois. L’application pense toujours qu’elle utilise une clé. La clé cesse simplement d’être à longue durée de vie, et la politique nous est transférée.

Le même modèle couvre un service Java de quinze ans et un serveur MCP déployé la semaine dernière. Commencez là où le risque est présent, prouvez‑le, continuez.

Les agents IA travailleront de plus en plus pour le compte des humains et, dans de nombreux cas, délégueront des tâches à d’autres agents. À mesure que ces flux de travail multi‑agents deviennent plus complexes, comment maintenir une chaîne claire d’identité, d’autorisation, de propriété et de responsabilité pour chaque action qui se produit ?

Le mode d’échec : un utilisateur interroge un orchestrateur, celui‑ci délègue à un second agent, qui appelle un outil via un serveur MCP, qui interroge une base de données avec un compte de service. Quatre sauts plus tard, le journal ne montre qu’un seul élément, un jeton valide. L’interrogateur, le décideur et le responsable ont disparu.

La solution consiste à refuser que l’identité s’effondre à n’importe quel saut. Chaque agent possède sa propre identité cryptographique. Lorsqu’il délègue, il ne transmet pas son jeton. Il émet une délégation limitée : ce sous‑agent, cette tâche, ces actions, au nom de cet utilisateur. Chaque saut transporte la chaîne complète ainsi que ses propres autorisations.

La responsabilité provient de l’application et de l’enregistrement en ligne, au moment de l’action. L’enregistrement du passerelle indique ce qu’il était autorisé à faire, ce qu’il a invoqué, et la chaîne qui le sous-tend.

Les systèmes multi‑agents deviendront plus difficiles à comprendre. La chaîne de responsabilité de chaque action n’est pas nécessaire.

L’injection d’invite et d’autres attaques peuvent potentiellement manipuler un agent IA légitime en le poussant à effectuer des actions que son opérateur n’a jamais prévues. Dans quelle mesure les contrôles d’accès basés sur l’identité peuvent-ils limiter les dommages causés par un agent compromis ou manipulé, même lorsque le modèle IA sous‑jacent se comporte de manière incorrecte ?

Vous ne pourrez pas empêcher l’injection d’invite au niveau du modèle. Les modèles lisent du contenu non fiable par conception. Supposez que l’agent finira par être incité à faire quelque chose de mauvais. La question est ce qu’il peut faire dans ce cas.

L’accès basé sur l’identité limite le rayon d’impact. Un agent manipulé avec le moindre pouvoir ne peut abuser que des actions qui lui ont été accordées pour cette tâche. S’il peut lire les tickets et publier des commentaires, aucune injection ne le fera exfiltrer la base de données client. Le jeton n’a pas cette portée.

L’attribution utilisateur maintient la chaîne intacte : quel utilisateur, quel agent, quelle tâche, à chaque appel. L’agent ne dépasse jamais ce que l’utilisateur pourrait faire, et chaque action est traçable.

La détection d’anomalies capture ce que la politique autorise mais que l’intention n’a pas permis. Un agent qui lit habituellement cinq enregistrements et qui soudainement en extrait cinq mille sort du cadre, même si chaque appel est autorisé. Parce que le passerelle se trouve en ligne et connaît la ligne de base, il peut signaler ou bloquer cela en temps réel.

Le modèle se trompera parfois. L’identité à portée limitée, l’attribution et les lignes de base comportementales rendent les erreurs survivables.

Hush se concentre principalement sur la sécurisation de l’IA, mais comment utilisez‑vous l’IA au sein même de Hush ? Existe‑t‑il des domaines tels que la découverte d’identités non humaines, l’analyse des modèles d’accès, la priorisation des risques ou l’application des politiques où l’IA peut améliorer de façon significative la plateforme de sécurité ?

Nous l’utilisons partout où il mérite sa place.

Dans le produit, la partie difficile n’est pas de trouver les secrets, mais de les comprendre. Une clé apparaît dans le trafic. Identité de charge de travail, intégration de fournisseur, jeton de test de développement, identité morte ? Un LLM lit le contexte d’exécution et les signaux du propriétaire et propose une réponse avec un score de confiance. Il résume ce que fait réellement une identité en langage humain clair, de sorte que la politique soit celle qu’un humain approuvera. Il classe le risque en fonction de la portée réelle et du rayon d’impact, et non d’une sévérité statique. L’application reste déterministe. L’IA aide à rédiger la politique – elle ne reçoit pas de vote à l’exécution.

Chez Hush, la programmation agentique a changé notre rythme. Des fonctionnalités qui prenaient un sprint prennent désormais plusieurs jours, et nous livrons des intégrations à une vitesse qu’une équipe en série A ne pourrait pas se permettre autrement. Les LLM triagent les tickets de support, regroupent les causes racines et font remonter les demandes des clients pour les discussions de feuille de route. Notre propre passerelle MCP se place devant tout cela, aidant nos clients à raisonner et à consommer le NHI et le risque agentique.

Hush affirme que plusieurs entreprises du Fortune 500 utilisent désormais sa technologie, tandis que Kyndryl a déployé Hush en interne et a commencé à la revendre à des clients d’entreprise. Qu’apprenez‑vous de ces déploiements à grande échelle concernant les problèmes de gouvernance réels que les entreprises rencontrent lorsque les agents IA passent de l’expérimentation à la production ?

Personne ne sait ce qu’il possède. Chaque grand déploiement commence de la même façon : la sécurité pense qu’il y a une douzaine d’agents en production, la découverte en trouve des centaines, déjà en contact avec les données client. Le problème de gouvernance n’est pas la politique, c’est d’abord l’inventaire.

Les identifiants sont pires que les agents. Presque chaque agent en production fonctionne avec un compte de service statique qui le précède, avec des permissions accumulées pendant des années pour autre chose. Il n’a pas reçu d’accès limité.

La responsabilité fait défaut. Demandez qui est responsable d’un agent, ou d’un NHI, et vous obtenez au mieux le nom d’une équipe, un contractuel parti, ou le silence.

Et l’acheteur a changé. C’était un problème d’équipe plateforme. Maintenant le RSSI en est responsable parce que le conseil le demande. Cela nous a fait passer des pilotes aux déploiements d’entreprise, et c’est la raison pour laquelle Kyndryl a déployé en interne avant de revendre.

Les agents n’ont pas créé de nouveaux problèmes de gouvernance. Ils ont repris ceux que les entreprises ont ignorés pendant une décennie avec les comptes de service et les ont aggravés.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Hush Security.