Vin Sharma, cofondateur et PDG de Vijil – Série d’entretiens

Vin Sharma est cofondateur et PDG de Vijil. Il apporte plus de 30 ans d’expérience dans les domaines de la cybersécurité, des logiciels libres, de l’informatique en nuage et de l’infrastructure de l’IA. Avant de fonder l’entreprise, il a dirigé des travaux d’ingénierie en apprentissage profond chez AWS pour Amazon SageMaker et Amazon Bedrock, développé des infrastructures de centres de données chez Intel et occupé des postes en gestion de produit et en ingénierie chez Hewlett-Packard. Il a commencé sa carrière par des tests automatisés en équipe rouge sur des systèmes UNIX de confiance, une expérience qui nourrit aujourd’hui sa volonté de rendre les agents d’IA d’entreprise fiables, sécurisés et sûrs.

Vijil fournit une infrastructure de confiance pour les agents d’IA d’entreprise, qui aide les organisations à évaluer leur comportement, à appliquer des contrôles et à renforcer leur résilience tout au long du cycle de vie des agents. Son approche associe tests, sécurité et rétroaction continue afin d’aligner le comportement des agents sur les objectifs et les politiques de l’organisation. Dans cet entretien, Sharma explique comment définir et mesurer la confiance, pourquoi les tests des agents diffèrent des approches classiques de la sécurité logicielle et quelle supervision les entreprises doivent mettre en place à mesure que les agents gagnent en autonomie.

Vous avez passé plus de 30 ans à travailler dans des entreprises comme AWS, Intel et Hewlett-Packard avant de fonder Vijil. Qu’est-ce qui vous a finalement convaincu que la confiance et la sécurité de l’IA constituaient un problème suffisamment important et non résolu pour justifier la création d’une entreprise ?

Avant de rejoindre une jeune entreprise spécialisée dans la sécurité, il y a 30 ans, j’étudiais l’IA et l’apprentissage automatique aux cycles supérieurs. Depuis, j’ai travaillé au sein d’équipes produit qui ont intégré une sécurité de niveau militaire à des systèmes d’exploitation fondés sur Unix et Linux, conçu des serveurs Web sécurisés pour les services bancaires en ligne, développé des environnements d’exécution de confiance pour l’informatique en nuage et intégré le chiffrement à des plateformes d’analyse de données. Plus récemment, j’ai bouclé la boucle en contribuant chez AWS à la création de services d’IA et d’apprentissage automatique prêts pour l’entreprise. Ce parcours m’a convaincu qu’intégrer la confiance à un système d’intelligence est plus difficile que de construire le système intelligent lui-même. Alors que l’industrie de l’IA semble largement déterminée à accroître les capacités des agents, je crois que nous devons investir autant de ressources dans la mise en place de mécanismes évolutifs de supervision et de contrôle au sein de ces agents. Sans ces mesures et ces mécanismes adaptés aux besoins propres à chaque organisation, la première vague d’adoption enthousiaste s’éteindra sur les bancs de sable des risques et du retour sur investissement, car les entreprises ne pourront pas prouver que leurs agents agissent dans leur intérêt.

Vijil repose sur l’idée que de nombreux agents d’IA ne sont jamais mis en production parce que les entreprises ne peuvent pas vérifier adéquatement leur fiabilité, leur sécurité et leur innocuité. Quels sont les principaux déficits de confiance que vous observez lorsque les entreprises passent des prototypes d’IA à des déploiements en production ?

Le principal obstacle au déploiement d’un nombre croissant d’agents toujours plus autonomes tient à la capacité des organisations à définir le comportement attendu de leurs agents et à vérifier que ceux-ci se comportent comme prévu. Mais cela ne suffit pas : elles doivent aussi pouvoir le faire à l’échelle et à la vitesse auxquelles les agents fonctionnent. Il va donc de soi que nous avons besoin d’un moyen permettant aux agents de mesurer et de modifier le comportement d’autres agents. Deux des principaux défis consistent à savoir quoi mesurer — autrement dit, ce que signifie un bon comportement pour un agent — et quoi modifier : quels composants du système d’agents régler pour susciter le comportement voulu par son donneur d’ordre ? Il peut s’agir du modèle et de ses paramètres, de l’invite système, des instructions de l’utilisateur, du cadre d’exécution de l’agent ou du graphe des systèmes multi-agents.

Comment Vijil définit-elle et mesure-t-elle la « confiance » dans un agent d’IA, et quels signaux ou référentiels comptent le plus pour déterminer si un agent est prêt à fonctionner au sein d’une entreprise ?

Nous définissons la confiance comme le bénéfice attendu de la délégation à un agent autonome, pondéré à la baisse en fonction du risque qu’il trahisse nos intentions. Un agent est donc digne de confiance s’il se comporte correctement dans des conditions normales, perturbées et hostiles et, en cas de défaillance, limite l’ampleur des dégâts. Nous pouvons alors mesurer la confiance selon trois piliers : la fiabilité, la sécurité et l’innocuité. Les agents sont fiables lorsqu’ils fonctionnent comme prévu dans diverses conditions, sécurisés lorsqu’ils fonctionnent comme prévu dans des conditions hostiles, et sûrs lorsqu’ils peuvent limiter les risques commerciaux, juridiques et techniques.

Les agents d’IA peuvent se comporter de façon imprévisible, car ils combinent modèles, outils, sources de données, mémoire et systèmes externes. En quoi les tests d’un agent diffèrent-ils des tests classiques de sécurité des applications ou de l’évaluation habituelle des modèles ?

Les défaillances des logiciels traditionnels sont désormais bien comprises. De manière générale, elles comprennent l’incapacité à traiter des entrées mal formées, les faiblesses de la logique et de la conception des systèmes, les bogues d’implémentation, les vulnérabilités cachées aux attaques et les effets secondaires indésirables des résultats produits. Les tests visant à détecter ces défaillances sont, à juste titre, prévisibles. Les agents élargissent considérablement la surface des défaillances, au point que l’évaluation des modèles, les tests unitaires, les tests d’intégration, les tests de sécurité des applications, les tests d’intrusion et les contrôles de conformité ne permettent plus de l’examiner adéquatement. Pour tester cette nouvelle surface de risque propre aux agents, nous avons besoin de nouvelles mesures et de nouveaux mécanismes qui évaluent leur comportement au regard de l’objectif défini par leur donneur d’ordre, des profils de leurs utilisateurs et des politiques de l’organisation, du secteur et de la région où ils fonctionnent.

Vous avez notamment dirigé des projets d’ingénierie en apprentissage profond pour Amazon SageMaker et Amazon Bedrock. Quelles leçons tirées de la mise en place d’infrastructures d’IA chez AWS ont le plus influencé votre approche de la sécurité et de la fiabilité des agents chez Vijil ?

La leçon la plus déterminante a été qu’il était bien plus efficace de repérer les problèmes de fiabilité, de sécurité et de conformité des services dès les premières étapes du développement que d’attendre la veille du lancement, comme on le faisait traditionnellement, ou pire, que le service soit en production et de se réveiller au son des appels signalant une panne.

Vijil ne se concentre pas seulement sur les tests des agents avant leur déploiement, mais aussi sur leur protection et leur amélioration continue en production. Quels types de risques ne deviennent visibles qu’une fois qu’un agent commence à interagir avec de vrais utilisateurs, des données réelles et des systèmes d’entreprise ?

Le monde réel a une capacité infinie à nous surprendre. Or, un agent surpris est un agent sujet aux erreurs. Personne ne s’inquiète d’un agent qui commet une erreur en générant un mème. En revanche, un agent conçu pour aider ou remplacer un conseiller financier, un assistant juridique, un avocat, une infirmière, un médecin, un patient ou tout professionnel d’un secteur où il faut pouvoir prouver le respect d’obligations fiduciaires ne peut fonctionner que si les niveaux de tolérance sont strictement définis et soigneusement surveillés, et si le comportement de l’agent est rapidement rétabli.

À mesure que les entreprises déploient des agents de plus en plus autonomes, capables d’agir plutôt que de simplement générer des réponses, comment le modèle de sécurité doit-il évoluer ? Les notions traditionnelles, comme les autorisations, l’identité et le contrôle d’accès, sont-elles suffisantes ?

Non. À mesure que les agents deviennent des acteurs au sein d’une organisation, ils doivent se voir attribuer des identités uniques et vérifiables, ainsi que des rôles qui encadrent leur comportement et leurs composants fonctionnels (des outils disposant d’autorisations d’accès aux ressources), conformément à des politiques obligatoires de contrôle d’accès. Leur comportement doit faire l’objet d’une surveillance continue afin de repérer tout écart par rapport à leur objectif prévu, et ils doivent être orientés de manière à rester résilients en cas d’attaque.

Vijil est passé d’un tour d’amorçage de 6 millions de dollars à une série A de 17 millions de dollars, tout en constituant une équipe fondatrice d’une vingtaine de personnes et en atteignant son premier million de dollars de revenus récurrents annuels. Quelles décisions ont été les plus importantes pour passer d’un concept technique initial à une adoption commerciale ?

Nous avons décidé très tôt de créer une couche de confiance qui s’intègre à la plateforme choisie par le client, tout en anticipant que les entreprises chercheraient de plus en plus à personnaliser davantage leurs systèmes multi-agents reposant sur des modèles ouverts, à en contrôler les composants de façon plus granulaire et à en réduire le coût. Miser sur le long terme en construisant une couche de plateforme plutôt qu’un produit ponctuel nous confère des avantages concurrentiels, mais crée aussi des conditions difficiles : trouver des entreprises prêtes à encadrer des agents à grande échelle est moins simple que de vendre un service de migration à l’identique.

Vous avez commencé votre carrière en 1995 en élaborant des tests automatisés d’équipe rouge pour des systèmes UNIX sécurisés. Près de trois décennies plus tard, en quoi les principes de l’équipe rouge ont-ils évolué lorsque le système testé est un agent d’IA capable de raisonner, de s’adapter et d’utiliser des outils externes ?

Historiquement, l’équipe rouge consistait à tester les défenses d’une organisation face à une attaque coordonnée. Les principes généraux restent valables. Nous devons toujours coordonner des attaques dans des conditions contrôlées afin de sonder les vulnérabilités de l’organisation testée. Toutefois, les exercices d’équipe rouge scénarisés pour tester des systèmes logiciels, qui ont marqué une période intermédiaire, ne suffisent plus, car les agents d’IA ne sont pas des logiciels déterministes : ils sont conçus pour s’adapter à leur environnement, si bien qu’il est impossible de reproduire une même attaque de manière prévisible. Je soutiens qu’il faut traiter les agents comme des entreprises. Les tests d’équipe rouge des agents doivent donc nécessairement s’adapter à leur objectif, sonder tout écart par rapport aux intentions de leurs utilisateurs, ainsi que leur volonté et leur capacité à contourner les politiques de leur environnement.

À l’avenir, pensez-vous que des tests indépendants et des normes mesurables de confiance pour les agents d’IA deviendront des conditions préalables à leur déploiement en entreprise ? Que doit-il se passer à l’échelle du secteur pour que ce niveau de garantie devienne une pratique courante ?

Aujourd’hui, les concepteurs évaluent les capacités des agents, les équipes rouges testent leur résistance aux injections de prompt et aux jailbreaks, et les équipes GRC commencent tout juste à vérifier leur conformité réglementaire. Très peu d’organisations mettent en place un dispositif de vérification du comportement qui fonctionne en continu en arrière-plan pendant tout le cycle de vie de l’agent, à mesure que les modèles, les outils, les ressources, les processus et l’environnement cible évoluent. Plus important encore, Vijil aide les entreprises de manière unique en reliant le comportement réel de l’agent en production à sa spécification, dans une boucle de rétroaction qui améliore continuellement l’agent. Les agents qui résistent aux attaques sont ceux qui s’adaptent pour rester résilients.

Merci pour cette excellente interview. Les lecteurs qui souhaitent en savoir plus sur les tests, la protection et l’amélioration continue des agents d’IA en entreprise peuvent consulter Vijil.