Agents IA : assistant pratique ou porte ouverte aux pirates ?

Soyons honnêtes : nous attendions tous le moment où l'IA cesserait d'être un simple chatbot bavard pour se mettre à faire des choses. Réserver des billets, déboguer du code, gérer des serveurs. L'ère des agents IA est arrivée, mais elle s'accompagne d'un casse-tête que beaucoup de développeurs se sont appliqués à ignorer. Trail of Bits a publié une analyse qui agit comme une douche froide : vos agents « sécurisés » sont une faille de sécurité potentielle grande comme le Grand Canyon.

Le cœur du problème saute aux yeux, mais nous refusons obstinément de le voir. Nous donnons aux modèles de langage accès à des outils : système de fichiers, terminal, API. Pour dormir tranquilles, les ingénieurs bâtissent en général leur défense sur des listes blanches (allowlists) de commandes autorisées et placent un humain dans la chaîne de décision. L'idée : si l'IA tente quelque chose d'étrange, l'humain le remarquera et l'interdira. Cela semble logique ? En pratique, tout s'effondre.

Trail of Bits a montré comment cela cède sous l'effet de l'injection d'arguments. Il ne s'agit pas de l'injection shell classique, où l'on ajoute simplement du code malveillant. Ici, c'est plus subtil. L'attaquant manipule le prompt pour que le modèle utilise un utilitaire autorisé, mais avec des arguments qui en font une arme. Imaginez que vous autorisiez l'agent à utiliser la commande `curl` pour tester la connectivité, et que, sous l'influence d'un prompt caché, il télécharge un script malveillant et l'exécute. Formellement, la commande figurait sur la liste blanche. En réalité, vous venez d'offrir une RCE (Remote Code Execution) à l'attaquant.

L'espoir placé dans les filtres regex est particulièrement ironique. Filtrer la sortie d'un LLM avec des expressions régulières revient à vouloir retenir de l'eau dans une passoire. Les modèles sont trop variables et le contexte trop complexe pour que la logique rigide d'une regex attrape toutes les variantes de comportement malveillant. C'est un antipattern d'architecture qui, on ne sait trop pourquoi, survit en production dans de nombreuses startups.

Et l'humain dans la boucle ? Cela ne fonctionne que dans un monde idéal. Dans la réalité, les utilisateurs souffrent de fatigue décisionnelle. Quand l'agent demande une confirmation pour la dixième fois pour une action anodine, la vigilance s'émousse. Et si l'attaque est bien camouflée, même un ingénieur expérimenté peut passer à côté du piège dans un ensemble de flags de ligne de commande. Nous reportons la responsabilité sur l'utilisateur, qui est souvent le maillon le plus faible.

Que cela signifie-t-il pour l'industrie ? Nous approchons d'un point où la conception naïve des agents IA devient dangereuse. Brancher LangChain sur un terminal en espérant que tout se passe bien n'est plus une option. Il faut une isolation complète de l'environnement d'exécution (sandboxes), des limites de droits strictes au niveau du système d'exploitation plutôt que de l'application, et l'abandon de l'illusion qu'un LLM peut se modérer lui-même.

L'essentiel : la sécurité des agents IA ne peut pas reposer sur la confiance envers le modèle ou l'utilisateur. Si votre agent a accès au monde réel, considérez qu'il est déjà compromis. Êtes-vous prêt à ce que votre « assistant intelligent » supprime la base de données de production ?