Chaque agent est une identité, et presque personne ne le gère ainsi

Voici une question à vous poser sur votre organisation. Si, mardi dernier à 14 h 32, un agent d’IA que vous exploitez a fait quelque chose qu’il n’aurait pas dû faire, pourriez-vous dire de quel agent il s’agissait, de quels identifiants il disposait, à quoi il avait accès et qui l’avait autorisé ? Si la réponse est « il faudrait regarder quel compte de service l’équipe utilisait », vous avez précisément le problème dont traite cet article.

Des travaux présentés cette année à Black Hat montrent que 88 % des organisations ont signalé un incident de sécurité, avéré ou suspecté, impliquant un agent d’IA. Seules 22 % d’entre elles gèrent les agents comme des identités distinctes. Environ un quart ont mis en place une restriction par finalité (purpose binding) ; un cinquième environ disposent d’un coupe-circuit pour l’IA ; moins d’un tiers ont une prévention des pertes de données propre à l’IA. Et l’index de sécurité des identités de BeyondTrust constate que les trois quarts des enquêtes menées à leur terme impliquaient des identités ou des privilèges.

L’incident de Hugging Face, c’est la même histoire, racontée dans un laboratoire de recherche. Si les agents sont allés aussi loin, c’est qu’une instance Artifactory auto-hébergée était partagée entre toutes les exécutions et restait joignable quand internet ne l’était pas. Personne ne s’était demandé sous quelle identité opérait chaque bac à sable, ni à quoi cette identité avait accès – parce que personne ne voyait les bacs à sable comme des identités. On les voyait comme des tâches.

C’est un échec bien connu, avec un nouveau protagoniste. Il y a vingt ans, les organisations ont appris à leurs dépens que les comptes de service – des identifiants utilisés par des logiciels et non par des personnes – devaient être inventoriés, limités dans leur périmètre et renouvelés régulièrement, comme n’importe quelle autre identité, parce que les attaquants les visaient en priorité. Les agents sont des comptes de service capables de raisonner sur la manière d’utiliser leurs privilèges. Toutes les leçons de l’époque des comptes de service s’appliquent, avec une marge d’erreur plus faible.

Gérer un agent comme une identité suppose quatre choses. Chaque instance d’agent reçoit sa propre identité, pour que ses actions puissent lui être attribuées. Les identifiants sont limités à la tâche et expirent avec elle, si bien que le rayon d’impact est borné dans l’espace et dans le temps. Les flux sortants sont contrôlés et journalisés, parce que c’est sur le réseau qu’un agent confiné cesse de l’être. Et il existe un inventaire, parce qu’on ne peut pas gérer ce qu’on n’a pas recensé – et la plupart des organisations ont déjà branché plus d’agents qu’elles ne le pensent.

La lecture approfondie est un guide pratique de ces quatre mesures, avec notamment une méthode pour retrouver les agents que vous avez déjà déployés.