La sécurité d'un agent dépend d'abord de l'endroit où il s'exécute, et non de son comportement

Quand les équipes d'ingénieurs évaluent des agents IA, les premières questions portent généralement sur leurs capacités. Quel modèle est le plus performant ? À quelle vitesse peut-il écrire du code ? Quel est le retour sur investissement ? La sécurité, si tant est qu'elle soit abordée, a tendance à venir en second plan.

Patrick Dawkins, ingénieur logiciel principal chez Upsun, pense que c’est une erreur.

Depuis un an, il met en place l’infrastructure qui permet aux agents IA de fonctionner en toute sécurité au sein des équipes d’ingénierie. Sa conclusion, ce n’est pas que les modèles d’IA soient intrinsèquement dangereux. C’est plutôt que la plupart des équipes les utilisent dans des environnements qui n’ont jamais été conçus pour eux.

Le problème des ordinateurs personnels

Quand un agent tourne sur l’ordinateur portable d’un développeur, il a généralement besoin de trois choses pour faire quoi que ce soit d’utile, et c’est quand ces trois éléments sont réunis que le risque commence. Le chercheur en sécurité Simon Willison appelle ça le « trio mortel » : donner à un agent l’accès à des données non fiables, la capacité de produire des effets secondaires, et l’accès à des informations sensibles comme les identifiants ou les données clients. « Tu es dans une zone à risque si tu as ces trois éléments ensemble », explique Dawkins.

Le problème, c’est que les agents utiles ont généralement besoin de ces trois éléments. Un agent de révision de code doit lire les données du dépôt, publier des commentaires sur GitHub ou GitLab, et s’authentifier avec les identifiants du dépôt. Ce sont précisément ces capacités qui le rendent utile, mais aussi qui le rendent risqué.

La plupart des équipes qui exécutent des agents sur leurs ordinateurs portables personnels se trouvent actuellement dans cette situation, et la majorité d’entre elles n’en ont pas conscience.

Ce que personne ne peut voir

Le problème le plus grave, ce n’est pas seulement ce à quoi les agents ont accès ; c’est ce que personne d’autre dans l’entreprise ne peut voir.

Quand un agent tourne sur la machine d’un développeur, son activité est invisible. Il n’y a pas de journal d’audit central indiquant ce qu’il a lu, quels outils il a appelés, ce qu’il a écrit sur le disque ou ce qu’il a envoyé sur le réseau. Si une attaque par injection de prompt pousse l’agent à exfiltrer des données ou à effectuer une action non souhaitée, l’enquête part de presque rien. « Tu ne vois pas si les données clients sont envoyées au mauvais endroit », explique Dawkins. « On ne partage absolument pas les données clients avec les modèles d’IA, mais les secrets, les identifiants… ça commence à sembler louche. »

Les agents qui tournent en local peuvent accéder aux identifiants, aux clés SSH, aux variables d’environnement et à d’autres fichiers sensibles qui se trouvent déjà sur la machine d’un développeur. On ne leur demande peut-être pas de les utiliser. Mais ils sont accessibles, et un agent fonctionnant sous l’effet d’une invite malveillante ou mal conçue peut y accéder.

Le passage aux outils cloud au cours de la dernière décennie visait en partie à résoudre précisément ce problème au niveau de l’infrastructure. Les équipes d’ingénierie ont cessé d’exécuter des serveurs sur des machines individuelles, car la gouvernance, la visibilité et la gestion des incidents devenaient ingérables à grande échelle. La même logique s’applique aux agents. La plupart des équipes n’ont pas encore fait le lien.

Les garanties avant les garde-fous

Dawkins fait une distinction que la plupart des discussions sur la sécurité des agents négligent : la différence entre les garanties et les garde-fous.

Les garanties sont structurelles et appliquées au niveau du système. Donner à un agent un jeton OAuth en lecture seule signifie qu’il ne peut pas écrire sur ce système, peu importe ce qu’on lui demande de faire. Limiter l’accès au réseau, appliquer le principe du moindre privilège à chaque outil et API auxquels l’agent peut accéder, et l’exécuter dans un bac à sable éphémère qui est détruit après chaque exécution sont autant de garanties. Ces protections s’appliquent même si le modèle se trompe.

Les garde-fous, c’est différent. Marquer les données d’entrée non fiables pour que le modèle les traite avec le scepticisme qui s’impose, c’est un garde-fou. Filtrer la sortie de l’agent pour détecter et supprimer les identifiants avant que quoi que ce soit ne soit publié où que ce soit, c’est un garde-fou. Renforcer les invites pour réduire la vulnérabilité aux attaques par injection, c’est un garde-fou. Dawkins précise clairement que ces mesures peuvent réduire considérablement le risque, mais que les contrôles probabilistes ne sont pas la même chose que les contrôles structurels. « Ce ne sont pas des garanties », dit-il.

La plupart des équipes se tournent d’abord vers les garde-fous parce qu’ils sont plus faciles à mettre en place progressivement. Dawkins soutient que ce sont les garanties qui doivent passer en premier. Des garde-fous posés sur un système structurellement permissif ne constituent pas une base solide. Ce ne sont que des rustines.

À quoi ça ressemble vraiment

Le but n’est pas de réduire les capacités des agents ; c’est de limiter l’ampleur des dégâts en cas de problème. Un agent qui tourne dans un environnement structurellement solide va quand même rencontrer des cas limites et produire des résultats inattendus. La question, c’est de savoir si le système qui l’entoure est conçu pour contenir ça avant que ça ne devienne un problème.

Un agent qui tourne dans un bac à sable isolé et éphémère, avec des identifiants à portée limitée, dont les résultats passent par une couche de validation avant d’atteindre un humain ou un système externe, et qui nécessite une validation humaine explicite pour toute action ayant des conséquences durables, est nettement plus sûr qu’un agent tournant sans surveillance sur un ordinateur portable. Les capacités sont les mêmes. La différence, c’est la nature du mode de défaillance.

« Il faut que ce soit observable, traçable, contrôlable, interruptible », explique Dawkins. « Tout ça pour avoir un minimum de confiance. »

Cette confiance ne vient pas du fait de croire que le modèle va se comporter correctement en toutes circonstances. Elle vient de la conception du système, qui permet de contenir les conséquences d’un dysfonctionnement — qu’il s’agisse d’une hallucination, d’une injection de prompt ou d’un outil mal configuré — avant qu’elles ne se propagent. 

C’est un problème d’ingénierie différent de celui sur lequel la plupart des équipes se concentrent aujourd’hui, mais c’est celui-là qui déterminera si les agents IA deviendront une infrastructure de production ou resteront des outils expérimentaux.