Nati Hazut, PDG et cofondateur de Bold Security – Série d’entretiens

Nati Hazut est PDG et cofondateur de Bold Security. Il a auparavant cofondé SAM Seamless Network et Polyrize, où il a acquis de l’expérience dans la sécurité des appareils connectés, la gestion des identités, les autorisations dans le cloud et la protection des données. Chez Bold, il met ces enseignements à profit pour sécuriser les interactions entre les employés, les agents d’IA et les données sensibles des entreprises.

Bold Security développe une technologie de protection des données sur les terminaux, qui utilise de petits modèles de langage exécutés directement sur les appareils pour classer les informations sensibles et comprendre comment elles sont utilisées. Sa plateforme permet aux équipes de sécurité d’accompagner les utilisateurs, de réorienter leurs activités ou de bloquer les actions à risque dans les navigateurs, les applications de bureau et les agents d’IA. Dans cet entretien, Hazut évoque l’IA fantôme, l’intelligence embarquée sur les appareils, les agents autonomes et l’évolution du périmètre de sécurité des données d’entreprise.

Vous avez auparavant cofondé SAM Seamless Network et Polyrize, avant de lancer Bold Security avec Hadar Krasner et Omri Mallis. Quelles évolutions de la sécurité des entreprises et de l’IA vous ont convaincu qu’il était nécessaire de créer une nouvelle entreprise de sécurité à partir de zéro ?

La principale conséquence de l’IA, c’est qu’elle a déplacé le lieu où s’effectue le travail. Pendant des décennies, les activités les plus sensibles liées aux données de l’entreprise se déroulaient dans les navigateurs et les applications SaaS, précisément là où se concentrait la pile de sécurité. Aujourd’hui, une part croissante de ce travail s’effectue directement sur l’appareil : les utilisateurs rédigent dans un assistant d’IA de bureau, collent du code source dans une application native ou exécutent des agents qui accèdent directement aux fichiers, aux applications et aux systèmes de l’entreprise sur l’ordinateur portable.

Ce changement a remis en cause les hypothèses sur lesquelles reposaient la plupart des produits de sécurité. L’inspection du réseau ne voit que le trafic qui y transite, tandis que les applications de bureau chiffrent leur trafic et contournent le proxy. Les outils CASB voient les applications cloud autorisées. Les outils DSPM voient les données stockées dans le cloud. Aucun d’eux ne voit un fichier local transféré dans une application d’IA de bureau, ni un agent déplacer des données sans qu’une personne soit devant le clavier.

Nous avons créé Bold parce que le terminal est le seul endroit où tout cela se rejoint. On peut voir les données, l’employé ou l’agent qui interagit avec elles, ce qu’il cherche à faire et où elles sont envoyées. Et l’on peut intervenir avant que des données sensibles échappent au contrôle de l’entreprise.

L’IA fantôme peut prendre des formes très diverses : des employés qui utilisent leurs comptes ChatGPT personnels, des applications de bureau, des extensions de navigateur, des API, des connexions au Model Context Protocol et, de plus en plus, des agents autonomes. Quelles formes d’IA fantôme sont aujourd’hui les plus difficiles à détecter et à contrôler pour les équipes de sécurité des entreprises ?

Il y a un an, tout le monde s’inquiétait de « l’IA fantôme », mais le débat commence à prendre de l’ampleur. Les équipes de sécurité des entreprises prennent la mesure du fait que les employés adoptent de nouveaux outils d’IA plus rapidement que jamais. La question porte donc moins sur le recensement des outils que sur le contrôle des données qui y transitent.

Bien sûr, on ne peut pas contrôler ce qu’on ne voit pas. Or, les canaux les plus difficiles à observer sont ceux qui ne passent jamais par un chemin réseau surveillé. Les applications de bureau lisent directement les fichiers sur l’appareil et chiffrent leur trafic : rien ne transite donc par les outils conçus pour l’inspecter. Les agents ont accès aux informations de l’entreprise et continuent de les utiliser sans qu’un employé ait à leur fournir quelque chose à chaque fois.

Tous ces canaux constituent de nouveaux moyens d’exfiltration de données, et la nature des données qui y transitent est au cœur du problème. Le transfert d’un document public vers un compte d’entreprise autorisé n’équivaut pas au transfert d’une base de données clients ou de code source propriétaire vers un compte personnel. Cette différence n’est visible qu’à l’endroit où se trouvent les données et où l’action a lieu. Ainsi, l’IA fantôme que l’on ne peut pas voir est aussi celle pour laquelle la question des données est la plus importante.

Bold privilégie une approche axée sur les terminaux et exécute l’IA localement sur l’appareil, plutôt que de s’appuyer principalement sur la surveillance du réseau ou du cloud. Qu’est-ce qu’un modèle exécuté sur l’appareil peut comprendre d’une interaction avec l’IA que les solutions traditionnelles de prévention des pertes de données ne peuvent pas saisir ?

Bold se distingue de deux façons. Premièrement, nous utilisons l’IA pour protéger les données sensibles sans avoir à les transmettre à un autre service d’IA pour les analyser. Nos petits modèles de langage s’exécutent directement sur l’appareil, où ils peuvent déterminer quelles données sont sensibles, qui y accède et où elles sont envoyées. Nous pouvons ainsi repérer et bloquer les actions à risque en temps réel, sans la latence ni le coût liés à l’envoi de toutes les données vers le cloud.

Deuxièmement, nous couvrons des canaux qui échappent à la surveillance des outils de sécurité traditionnels. La plupart des acteurs du marché se concentrent encore sur les navigateurs et le trafic réseau, mais les données sensibles transitent de plus en plus par des applications d’IA de bureau, des outils de programmation, des terminaux et des agents autonomes. Ces canaux sont beaucoup plus difficiles à détecter pour les solutions conventionnelles de prévention des pertes de données et de sécurité du cloud.

En intervenant au niveau du terminal, nous pouvons protéger les données dans tous ces environnements et agir avant que des informations sensibles échappent au contrôle de l’entreprise.

Votre technologie est conçue pour comprendre non seulement quelles données sont consultées, mais aussi le contexte et l’intention qui sous-tendent une action. Comment distinguez-vous l’utilisation légitime d’informations sensibles d’un comportement présentant un véritable risque pour la sécurité, sans générer un nombre excessif de faux positifs ?

Ici, le contexte est essentiel. On ne peut pas considérer chaque téléversement de fichier ou chaque accès d’un agent aux données comme un incident de sécurité, sinon plus personne ne pourrait travailler.

Un même fichier peut être banal dans un contexte et poser un grave problème dans un autre. Une liste de clients est tout à fait normale dans l’outil d’assistance, mais constitue un vrai problème si elle est téléversée vers un compte personnel. Le code source a sa place dans le dépôt, pas dans une invite adressée à un outil d’IA grand public.

Un outil qui sait seulement que le contenu correspond à une règle doit signaler les deux cas ou n’en signaler aucun. C’est ainsi que surviennent les faux positifs. Pour distinguer un usage normal de l’IA d’un véritable risque, il faut savoir de quelles données il s’agit, qui les déplace et où elles sont envoyées.

Les agents d’IA introduisent un modèle de sécurité différent, car les logiciels peuvent de plus en plus accéder à des fichiers, appeler des outils, se connecter par l’intermédiaire de serveurs MCP et effectuer des actions avec une intervention humaine limitée. Comment la sécurité des terminaux doit-elle évoluer lorsque l’acteur qui interagit avec des données sensibles de l’entreprise peut être un agent autonome plutôt qu’un employé ?

La sécurité a, dans une large mesure, été conçue pour les personnes, mais les agents peuvent désormais agir à la vitesse d’une machine, ouvrir des fichiers, appeler des outils et déplacer des données sans que quelqu’un approuve chaque étape. La sécurité doit fonctionner à cette même vitesse. De nombreux produits utilisent l’IA pour analyser les incidents après coup. Nous l’utilisons pour comprendre et bloquer les actions à risque en temps réel, y compris celles qui se produisent en dehors du navigateur.

Un agent peut travailler dans une application de bureau, un terminal ou un autre outil qu’il découvre en accomplissant une tâche. La sécurité doit suivre les données et les actions dans ces différents environnements, qu’elles soient le fait d’une personne ou d’un agent.

Cela soulève aussi une question que les équipes de sécurité n’avaient pas eu à se poser auparavant. Lorsqu’un incident à risque survient, la personne a-t-elle agi délibérément ou l’agent s’est-il trompé ? Ces situations appellent des réponses différentes. Si un employé prend une mauvaise décision, on l’accompagne pour le corriger. Si un agent fait quelque chose que personne ne lui a demandé, on l’arrête.

C’est au niveau du terminal qu’on peut faire la différence, car c’est là que les données, le processus et l’action se trouvent réunis.

De nombreuses entreprises ont réagi aux risques liés à l’IA générative en limitant ou en interdisant certains outils. Pensez-vous que les organisations s’orientent vers un modèle où presque tous les outils d’IA pourraient être autorisés, à condition que des contrôles encadrent les données auxquelles ils peuvent accéder et leur destination ?

Les interdictions générales ne résoudront pas le problème. Les employés peuvent trouver un nouvel outil d’IA et commencer à l’utiliser en quelques secondes, et la plupart ne cherchent pas à contourner les mesures de sécurité. Ils veulent simplement travailler plus efficacement.

La vraie question est de savoir ce qu’il advient des données de l’entreprise lorsqu’ils utilisent ces outils.

Si quelqu’un utilise un compte personnel d’IA pour une tâche sans risque, il suffit peut-être de l’orienter vers le compte de l’entreprise. En revanche, s’il s’apprête à envoyer du code source, des informations sur des clients ou des identifiants vers un endroit où l’entreprise ne l’autorise pas, l’équipe de sécurité doit intervenir.

C’est, selon moi, la direction que prend la situation. Laisser aux personnes la liberté d’utiliser l’IA, tout en encadrant les données. Savoir quelles données sont consultées, où elles sont envoyées et à quel moment il faut intervenir.

L’exécution locale de l’IA peut offrir des avantages en matière de latence et de confidentialité, mais les terminaux disposent aussi de capacités de calcul et d’une mémoire limitées. Quels compromis techniques avez-vous dû faire pour créer des modèles capables de classifier sémantiquement les données et d’appliquer des mesures en temps réel directement sur les appareils des employés ?

On ne peut pas installer un modèle gigantesque sur l’ordinateur portable de quelqu’un, épuiser son processeur et sa mémoire, puis prétendre qu’il s’agit de sécurité. Si votre produit de sécurité rend l’ordinateur pénible à utiliser, les employés le détesteront et l’équipe informatique le désactivera.

Les compromis sont donc bien réels. Le modèle doit comprendre suffisamment bien les données pour distinguer ce qui est anodin de ce qui est sensible, tout en étant assez rapide, léger et fiable pour fonctionner en continu en arrière-plan.

Il a d’abord fallu créer des modèles capables de classifier efficacement différents types de données sur différents ordinateurs sans les ralentir. Nous avons déjà réalisé ce travail d’ingénierie, afin que les clients n’aient pas à faire eux-mêmes ces compromis.

Tout au long du développement, l’expérience utilisateur a été notre priorité absolue. Notre produit utilise environ 20 % des ressources informatiques consommées par les agents non dotés d’IA de nos concurrents historiques, tout en prenant des décisions localement au moment où une action se produit. Il n’est pas nécessaire que les données sensibles quittent l’appareil pour déterminer si elles sont sensibles.

Bold peut détecter les outils d’IA, les comptes et l’activité des agents, puis accompagner les utilisateurs, les rediriger ou bloquer les actions à risque. Comment déterminez-vous si le système doit simplement avertir l’utilisateur ou interrompre automatiquement une action ?

Imaginez comment réagirait un bon collègue. Si vous vous apprêtiez à coller un brouillon dans votre compte ChatGPT personnel, il se pencherait vers vous et dirait : « Hé, on a un compte d’entreprise pour ça. » Si vous vous apprêtiez à téléverser la base de données clients sur votre Drive personnel, il vous retiendrait par le bras.

Nous essayons de procéder de la même manière et constatons que l’accompagnement permet, dans au moins 90 % des cas, d’orienter efficacement les utilisateurs vers une solution de remplacement sûre. Dans la plupart des cas, il s’agit d’une personne qui utilise par erreur le mauvais compte ou qui ne connaît pas la politique de l’entreprise concernant les emplacements où les données peuvent être stockées.

La décision de bloquer revient en définitive au client, et chaque entreprise fixe cette limite différemment. Notre rôle est de lui fournir le contexte et l’assurance nécessaires pour faire le bon choix. Pour les flux à risque plus complexes, cela signifie apporter le contexte évoqué précédemment, en l’évaluant à l’aune de l’historique propre à l’utilisateur et même de celui de son groupe de pairs.

Votre carrière vous a mené de la sécurisation des appareils connectés chez SAM à la gestion des identités et des autorisations cloud chez Polyrize, puis à la protection des interactions entre les personnes, les agents d’IA et les données d’entreprise chez Bold. Comment votre vision de la frontière fondamentale de la sécurité a-t-elle évolué au fil de ces trois générations de cybersécurité ?

Ma compréhension des principes fondamentaux s’est affinée. Le fil conducteur consiste à rapprocher la sécurité du lieu où l’action se déroule et à la rendre évolutive.

Chez SAM, nous avons apporté une sécurité de niveau entreprise à des routeurs aux ressources très limitées. Cela nous a appris à déployer efficacement des technologies avancées à la périphérie. Chez Polyrize, nous nous sommes attachés à protéger les données dans les environnements cloud et SaaS grâce à la visibilité et à la gestion de la posture de sécurité. Comprendre l’exposition est essentiel, mais cela ne permet pas nécessairement d’empêcher une action risquée.

Bold réunit ces enseignements. Nous intégrons l’intelligence au terminal, là où les personnes et les agents d’IA interagissent avec les données, et fournissons aux équipes de sécurité le contexte nécessaire pour comprendre les risques et intervenir en temps réel.

La sécurité des réseaux et du cloud reste importante, mais le terminal permet de voir l’activité dans les applications de bureau, les fichiers locaux, les comptes personnels et les agents qui s’exécutent sur l’appareil. J’ai appris que le lieu et le moment où la sécurité intervient comptent autant que son degré d’intelligence.

À l’horizon de trois à cinq ans, alors que les employés travailleront aux côtés d’agents d’IA de plus en plus autonomes, à quoi pensez-vous que le terminal d’entreprise ressemblera ? Pourrait-on en arriver à ce que chaque appareil dispose effectivement de sa propre couche de sécurité intelligente, qui décide en continu quels humains et quels agents peuvent interagir avec certaines données ?

Je pense que c’est exactement là où nous allons.

Le terminal devient une couche de sécurité intelligente qui comprend les données présentes sur l’appareil, sait si une personne ou un agent interagit avec elles et décide localement de ce qui doit ou ne doit pas se produire.

C’est d’autant plus important que les agents gagnent en autonomie. Une personne pourrait en avoir plusieurs qui travaillent simultanément en son nom, dans des fichiers, des applications et des systèmes d’entreprise. La sécurité ne peut pas dépendre de l’approbation de cette personne à chaque étape, car elle ne sera de plus en plus souvent pas là pour surveiller leurs activités.

Les données doivent toujours être protégées, mais le nombre d’acteurs qui y accèdent dépassera largement celui d’une seule personne devant son clavier. Les systèmes de sécurité devront communiquer avec les agents, prendre des décisions et réagir de manière autonome au fil des actions. Les personnes qui exploitent ces systèmes superviseront de plus en plus les contrôles et les décisions, au lieu d’examiner chaque événement individuellement. C’est sur le terminal que ces décisions peuvent être prises, tandis que les données restent sous le contrôle de l’entreprise.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent en savoir plus sur la protection des données sur les terminaux et l’adoption sécurisée de l’IA en entreprise peuvent consulter Bold Security.