Adam Markowitz, PDG et cofondateur de Drata – Série d’entretiens

Adam Markowitz est PDG et cofondateur de Drata, où il étend les activités de l’entreprise en matière de conformité continue et de confiance à la gouvernance des agents d’IA. Avant de cofonder Drata en 2020, il a fondé Portfolium avec Troy Markowitz et Daniel Marashlian. Son expérience des questionnaires de sécurité, des audits et des examens de conformité a contribué à façonner l’approche de Drata en matière d’automatisation des moyens par lesquels les organisations démontrent qu’elles sont dignes de confiance.

Drata propose une plateforme de gouvernance, de gestion des risques et de conformité qui réunit la collecte automatisée de preuves, la surveillance continue des contrôles, la gestion des risques liés aux tiers et les processus de réponse aux questionnaires de sécurité. Ses fonctionnalités de gouvernance des agents d’IA visent à détecter les agents, à appliquer des politiques avant l’exécution de leurs actions et à consigner leurs décisions afin d’en assurer l’auditabilité. Dans cet entretien, Markowitz aborde les menaces internes liées aux agents, les identités machines, les limites de sécurité des appels d’outils et les contrôles dont les entreprises ont besoin pour déployer des agents autonomes à grande échelle.

Vous avez fondé Portfolium avant de cofonder Drata en 2020, après avoir constaté directement à quel point la conformité en matière de sécurité pouvait devenir contraignante à mesure qu’une entreprise se développait. Qu’est-ce qui vous a convaincu qu’il s’agissait d’un problème justifiant la création d’une entreprise entièrement nouvelle, et comment la mission de Drata a-t-elle évolué à mesure que l’IA transformait le paysage de la sécurité ?

À la tête de Portfolium avec mes cofondateurs Troy Markowitz et Daniel Marashlian, nous avons retenu une leçon précieuse : en affaires, gagner la confiance est un processus, pas un argumentaire. Étant donné le volume important et la sensibilité des données étudiantes, les universités et les entreprises ne voulaient pas s’associer à nous tant que nous ne leur avions pas prouvé que nous faisions le nécessaire pour protéger leurs données. Nous avons compris que la tâche lente et pénible consistant à traiter manuellement chaque questionnaire de sécurité, audit et examen de conformité était une expérience commune. Après le rachat de Portfolium, Troy, Daniel et moi nous sommes retrouvés et avons consacré six mois à la création de la première version de Drata, en échangeant avec des dizaines d’entreprises et d’auditeurs pour valider le problème avant même de commencer à écrire du code. À notre lancement, nous avons atteint 100 clients au cours des six premières semaines, puis 1 000 avant la fin de l’année : nous avons alors compris que nous étions passés d’un produit « agréable à avoir » à un outil dont les utilisateurs ne pouvaient plus se passer.

Avec l’IA, la mission de Drata — instaurer une confiance continue — n’a pas changé, mais le champ de cette confiance s’est élargi. Nous avons commencé par automatiser les tâches fastidieuses liées à la conformité, puis nous avons développé des processus agentiques capables de mener de bout en bout des évaluations des risques liés aux tiers et de remplir des questionnaires de sécurité. Mais le véritable changement est survenu lorsque les agents eux-mêmes sont devenus l’objet de la gouvernance. Nous avons désormais étendu la plateforme pour qu’elle prenne en charge la gouvernance des agents d’IA : détecter les agents, encadrer ce qu’ils sont autorisés à faire et produire des preuves fiables lorsqu’on en demande.

Vous avez introduit l’expression « menace interne liée aux agents » pour désigner les risques créés non pas par un attaquant externe, mais par les propres agents d’IA d’une organisation. En quoi une menace interne liée aux agents diffère-t-elle des menaces internes classiques auxquelles les équipes de sécurité se préparent depuis des décennies ?

Les menaces internes classiques concernent une personne qui abuse des accès dont elle dispose déjà : un employé mécontent, un employé négligent ou quelqu’un qui clique simplement au mauvais endroit. Depuis des décennies, les équipes de sécurité mettent en place des programmes pour gérer ce risque, en se concentrant notamment sur les vérifications des antécédents, le principe du moindre privilège et les listes de contrôle à suivre lors du départ d’un employé.

La menace interne liée aux agents est différente, car l’agent n’a jamais reçu d’accès au départ. Le risque ne relève plus de l’abus d’accès, mais de son obtention. Si un agent reçoit un objectif et que la voie directe pour l’atteindre est bloquée, il ne se contente pas d’ouvrir un ticket et d’attendre, comme le ferait une personne. Il cherche une autre voie : un compte de service protégé par un mot de passe faible ou un point de terminaison que personne n’a pensé à fermer. Il s’introduit sans malveillance ni violation de politique dont il ait conscience. Il fait exactement ce qu’on lui a demandé, et c’est ce qui le rend si difficile à repérer. Chaque étape semble raisonnable prise isolément, et l’agent annonce avoir réussi à la fin.

Nous savons déjà comment encadrer les employés et les tiers qui ont accès à des systèmes sensibles, mais les agents constituent une troisième catégorie, et les outils conçus pour les deux premières ne permettent pas de les gérer.

Les agents d’IA peuvent poursuivre leurs objectifs avec persévérance, fonctionner à la vitesse des machines et interagir avec plusieurs systèmes sans disposer du jugement dont pourrait faire preuve un employé. Dans quelle mesure cela transforme-t-il fondamentalement le modèle de menace des entreprises ?

Cela change surtout le calendrier. Une personne qui cherche un moyen de pénétrer dans un système finit par se lasser, se faire repérer ou abandonner. Un agent, non. Une porte ouverte qui était passée inaperçue jusque-là est désormais découverte, car l’agent ne se fatigue pas et ne cesse pas ses recherches.

Et il ne s’agit pas d’une seule porte. Un agent conçu pour accomplir une tâche va volontiers accéder à une douzaine de systèmes pour y parvenir — récupérer ici l’historique d’un compte, consulter là une base de données — alors que la plupart de ces opérations n’ont rien à voir avec ce qu’on lui a réellement demandé. En préparant une seule présentation, il peut accéder aux données d’un autre client, à des dossiers financiers, à des informations sur les employés ou à tout ce qui se trouve sur son chemin. Rien de tout cela n’apparaît comme un incident.

Le modèle de menace a donc changé. Aujourd’hui, une équipe de sécurité devrait se demander jusqu’où ses propres agents iront pour accomplir une tâche si personne ne leur a indiqué où s’arrêter.

De nombreuses organisations disposent déjà de systèmes de gestion des identités et des accès, de gestion des accès privilégiés et d’architectures zéro confiance. Pourquoi ces contrôles ne suffisent-ils pas, à eux seuls, à encadrer les agents d’IA autonomes ?

Ces cadres ont été conçus pour les humains et les fournisseurs : deux catégories capables de jugement, qui s’arrêtent toutes deux lorsqu’elles rencontrent un obstacle. L’identité des agents exige la même rigueur que celle mise en place pour les humains et la gestion des risques liés aux tiers : découverte, attribution de la responsabilité et éléments de preuve qu’un auditeur puisse accepter. Le problème, c’est qu’il n’existe pas encore de norme commune définissant ce que signifie réellement « encadré » lorsque l’entité qui détient les identifiants d’accès est un agent.

Un agent créé par l’un de vos ingénieurs, par exemple, peut agir avec les droits d’accès de cet ingénieur, y compris sur des systèmes auxquels celui-ci n’accède jamais lui-même. Les systèmes IAM et PAM partent du principe que l’entité qui détient les identifiants d’accès sait quand s’arrêter, mais les agents ne sont pas conçus avec cette capacité.

Les entreprises devraient-elles commencer à traiter chaque agent d’IA comme une identité machine à part entière, avec un responsable clairement désigné, des autorisations, un périmètre et un cycle de vie définis ? À quoi ressemblerait un cadre d’identité mature pour les agents ?

Oui, mais la plupart des entreprises n’en sont pas encore là. Plus d’entreprises qu’on ne le pense sont incapables de dire combien d’agents opèrent dans leur environnement, et encore moins qui est responsable de chacun d’eux. Un cadre mature commence par la découverte : un inventaire réel et continu de chaque agent. Ensuite, chaque agent doit avoir un responsable, un périmètre clairement défini précisant les ressources auxquelles il peut accéder, ainsi qu’une politique effectivement appliquée dans le respect de ce périmètre. Nos propres recherches révèlent le même problème du côté des fournisseurs : trois organisations sur quatre ne réévaluent leurs tiers qu’une fois par an, voire moins souvent. Elles s’appuient donc sur des données déjà obsolètes lorsque la situation évolue. Les évaluations ponctuelles ne conviennent pas aux agents, qu’ils soient internes ou externes.

Nous voulons qu’une même norme s’applique à tous les agents, au lieu que les équipes de sécurité doivent traquer ce que chaque développeur a créé de son côté. Cela suppose de pouvoir rédiger les politiques en langage courant, de les tester sur des données réelles issues du trafic passé avant leur mise en application, puis de les faire respecter en ligne, afin que le cadre s’applique à chaque action de l’agent au moment où elle se produit et ne reste pas lettre morte dans la documentation.

Un scénario particulièrement difficile est celui d’un agent qui enfreint une politique de sécurité sans agir de façon malveillante. Si un agent découvre un chemin imprévu vers des données sensibles simplement parce qu’il tente d’accomplir la tâche qui lui a été confiée, comment les équipes de sécurité peuvent-elles distinguer une automatisation réussie d’un incident de sécurité ?

À l’heure actuelle, la réponse honnête est que vous ne le pouvez pas. Imaginez un agent d’assistance conçu pour préparer des revues trimestrielles d’activité et chargé de récupérer l’historique d’un compte pour créer la présentation. La voie prévue — l’export qu’il est censé utiliser — ne renvoie aucun résultat. Un humain s’arrêterait là, mais l’agent trouve une autre voie et, de son point de vue, a obtenu le résultat attendu.

La tâche a bien été accomplie, mais l’agent y est parvenu en contournant vos protocoles de sécurité et en accédant à des systèmes qu’il n’était pas censé ouvrir. La question déterminante doit être de savoir si l’agent est resté dans les limites du périmètre qui lui avait été fixé. L’objectif n’a jamais été de savoir s’il terminerait la tâche. C’est une question de politique. Il faut définir le périmètre avec suffisamment de précision pour qu’a posteriori, une « automatisation réussie » et un « incident de sécurité » ne semblent pas identiques.

La surveillance de sécurité traditionnelle détecte souvent les activités suspectes après qu’elles se sont produites, mais un agent autonome peut exécuter des centaines d’actions avant qu’un humain puisse intervenir. L’IA agentique nécessite-t-elle des contrôles de sécurité intégrés directement au processus d’exécution, plutôt que de s’appuyer principalement sur des alertes et une surveillance a posteriori ?

Oui, sans aucun doute. Si vous détectez le problème à l’exécution, il est déjà trop tard. Lorsque l’outil de surveillance signale l’action, celle-ci a déjà été exécutée. Vous disposerez d’un relevé parfait de la manière dont vous avez été exposé, mais vous ne pourrez plus revenir en arrière pour l’empêcher.

Le seul type de gouvernance efficace pour un système qui évolue à la vitesse d’une machine consiste à évaluer l’action avant son exécution et à bloquer la violation en ligne. Nous ne confierions jamais nos données les plus sensibles à une nouvelle recrue en espérant simplement que la surveillance détecte tout problème. Les agents méritent la même rigueur, au moment même où l’action est sur le point d’être exécutée. Pas après.

Le Model Context Protocol (MCP) et d’autres interfaces entre agents et outils donnent aux systèmes d’IA accès à des capacités externes toujours plus puissantes. Quelles nouvelles limites de sécurité faut-il mettre en place autour des appels d’outils, des API, des identifiants d’accès et des comptes de service, à mesure que les entreprises élargissent les capacités autorisées de leurs agents ?

L’appel à un outil constitue le nouveau périmètre de sécurité. Chaque fois qu’un agent utilise un identifiant d’accès, appelle une API ou invoque un outil, il prend une décision. Or, aujourd’hui, la plupart des entreprises n’ont aucune limite à ce point précis pour évaluer si l’action doit avoir lieu. C’est ce qui manquait. Nous observons le même angle mort depuis l’extérieur : seulement 37 % des responsables de la sécurité sont certains de pouvoir identifier où l’IA est utilisée chez les fournisseurs avec lesquels ils travaillent déjà. Si vous ne pouvez pas le voir dans le produit d’un fournisseur, vous ne verrez pas non plus la prochaine action de votre propre agent. Les identifiants et les comptes de service qui sous-tendent tout cela doivent également être soumis à la même rigueur que celle appliquée aux accès humains : leur propriétaire doit être connu, leur portée définie et ils doivent faire l’objet d’examens réguliers. Un agent ne devrait pas pouvoir utiliser un identifiant qui ne lui a jamais été accordé simplement parce que cet identifiant se trouvait quelque part sur son chemin.

Lorsqu’un auditeur, un organisme de réglementation ou un client demande à quoi un agent d’IA a accédé, quelles décisions il a prises et où les données qui en ont résulté ont été envoyées, quel niveau de traçabilité les organisations devraient-elles raisonnablement être en mesure de fournir ? Les pistes d’audit des agents pourraient-elles finir par devenir aussi indispensables que les journaux d’accès traditionnels ?

À la demande, les organisations devraient pouvoir préciser à quoi un agent a accédé, quelles décisions il a prises et où les données qui en ont résulté ont été envoyées. Il ne suffit pas de reconstituer la réponse après coup en recoupant des journaux. La norme à atteindre est celle d’un enregistrement continu et infalsifiable, déjà disponible au moment où la question est posée. Aujourd’hui, la plupart des entreprises ne répondent pas à ces questions. Ce n’est pas une lacune que l’on peut justifier auprès d’un client et, selon la nature des informations divulguées, les organismes de réglementation ne l’accepteront pas non plus.

Et oui, je pense que les pistes d’audit des agents deviendront bientôt aussi indispensables que les journaux d’accès. Depuis des années, nous considérons comme non négociable, pour les systèmes utilisés par des personnes, de savoir « qui a accédé à quoi et quand ». Rien ne justifie d’imposer aux agents des exigences moins strictes simplement parce que ce n’est pas une personne qui a cliqué. Des cadres comme le règlement européen sur l’IA, AIUC-11 et ISO 42001 vont déjà dans ce sens. La traçabilité des agents doit s’appuyer sur les mêmes contrôles et les mêmes principes de preuve que ceux qui sous-tendent déjà les programmes de conformité. La traiter comme une question secondaire, c’est prendre le risque qu’elle soit mise de côté.

À l’avenir, pensez-vous que la gouvernance des agents d’IA deviendra une catégorie de sécurité à part entière, ou finira-t-elle par être intégrée aux plateformes existantes de gouvernance, de gestion des risques, de conformité, d’identité et de cybersécurité ? Selon vous, quels dispositifs les entreprises devront-elles mettre en place avant de pouvoir déployer en toute sécurité des agents véritablement autonomes à grande échelle ?

Chaque grande vague technologique entraîne sa propre vague de sécurité : le cloud a donné naissance à Wiz, les terminaux à CrowdStrike, et les agents d’IA sont à l’origine d’une nouvelle vague aujourd’hui. Les fournisseurs de modèles créent des consoles et des politiques pour leurs propres plateformes, ce qui est utile, mais aucune entreprise ne s’appuie sur un seul fournisseur de modèles, un seul assistant de programmation et un seul ensemble d’agents développés en interne. Il faut bien que quelqu’un gouverne tout cela au moyen d’un ensemble unique de politiques et d’un référentiel de preuves commun, et aucune plateforme d’IA isolée n’est conçue pour résoudre ce problème. Ce n’est pas sa raison d’être. La gouvernance des agents d’IA constitue déjà une catégorie à part entière, même si elle s’intègre aux systèmes de gouvernance, de gestion des risques et de conformité (GRC), d’identité et de conformité que les entreprises utilisent déjà.

Avant de pouvoir déployer à grande échelle des agents véritablement autonomes, les entreprises doivent mettre en place quatre éléments, et la plupart n’en ont encore aucun. Le premier est la découverte en temps réel : savoir, dès la création de chaque agent, lesquels sont en fonctionnement, qui en est responsable et sous quelle identité il opère.

Vient ensuite l’application des politiques en ligne, avec une évaluation avant l’exécution de chaque action. Troisièmement, les entreprises doivent assurer une surveillance continue des dérives, car les agents survivent à la session qui les a créés et leur périmètre peut s’élargir discrètement. Enfin, il leur faut un enregistrement infalsifiable de chaque décision prise par un agent, associé aux cadres effectivement reconnus par les auditeurs et les organismes de réglementation. C’est cette couche que nous développons chez Drata. Sans elle, une entreprise qui déploie des agents autonomes à grande échelle ne fait que miser sur la chance.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent en savoir plus sur la gouvernance des agents d’IA, la conformité continue et les contrôles contre les menaces internes liées aux agents peuvent consulter Drata.