Des vulnérabilités visant des outils qui accordent aux modèles un accès aux fichiers, aux paquets logiciels ou à l'exécution de code ont été publiées cette semaine. La recommandation qui accompagne ces publications est simple et rarement suivie : inventoriez tous les services qui donnent ce type d'accès à un modèle, appliquez les correctifs, et isolez sérieusement vos expérimentations d'agents.
Nous documentons les attaques visant les agents depuis des mois. Celles-ci changent de cible, et le déplacement est instructif.
Le déplacement de la cible
Jusqu'ici, les attaques que nous avons couvertes visaient le modèle ou son contexte : du texte invisible dans un courriel, une injection via la mémoire persistante, des blocs de raisonnement chiffrés réutilisables.
Ces nouvelles vulnérabilités visent autre chose : les outils qui entourent le modèle. Le serveur qui lui donne accès à vos fichiers, le gestionnaire de paquets qu'il utilise, l'environnement dans lequel il exécute du code.
C'est un déplacement logique. Ces couches sont souvent installées rapidement, dans un contexte d'expérimentation, avec des permissions généreuses parce que restreindre demande du travail. Elles constituent le maillon faible.
Pourquoi c'est plus grave que ça n'en a l'air
Une injection dans le contexte du modèle produit une mauvaise réponse. Une vulnérabilité dans l'outil d'exécution produit une exécution de code sur votre machine.
La différence est de nature. Dans le premier cas, l'attaquant manipule ce que le modèle dit. Dans le second, il utilise l'agent comme point d'entrée vers votre infrastructure.
Et ces environnements sont souvent connectés à des choses sensibles : vos dépôts de code, vos identifiants d'accès, vos bases de données. C'est ce qui les rend utiles, et c'est exactement ce qui les rend intéressants pour un attaquant.
Voici le schéma qui se répète dans toutes les organisations. Quelqu'un installe un outil pour tester une idée, avec des permissions larges parce que c'est juste un essai. L'essai fonctionne, on l'utilise un peu plus, on oublie qu'il tourne. Six mois plus tard, un composant expérimental disposant d'un accès complet fonctionne en permanence sans être surveillé. Ce n'est pas un problème d'IA, c'est un classique de la sécurité informatique. L'IA l'aggrave parce que ces outils s'installent en quelques minutes.
Ce qu'il faut faire
Quatre mesures, par ordre d'efficacité.
Inventoriez. Listez tous les services qui donnent à un modèle un accès aux fichiers, aux paquets ou à l'exécution. La plupart des organisations découvrent à cette occasion des choses qu'elles avaient oubliées.
Appliquez les correctifs. Le conseil paraît banal et reste le plus efficace. Nous avons documenté avec une campagne visant 460 systèmes que les attaques exploitent massivement des failles déjà corrigées.
Isolez pour de bon. Un environnement d'exécution doit être réellement séparé : pas d'accès réseau non nécessaire, pas d'identifiants du système principal, des permissions minimales. Nous avons montré dans notre article sur les tests de sécurité qu'une isolation logicielle n'est jamais parfaite. Raison de plus pour l'empiler.
Surveillez les sorties réseau. Un agent compromis doit envoyer ce qu'il a récupéré quelque part. C'est souvent le signal le plus facile à repérer.
Ce qu'il faut retenir
Cette série d'incidents confirme ce que nous écrivons depuis le début de l'été : chaque capacité qui rend un agent utile élargit sa surface d'attaque, et il n'existe pas de version puissante et sans surface.
Ce qui change avec ces vulnérabilités, c'est que la cible n'est plus l'intelligence du système mais la plomberie autour. C'est plutôt une bonne nouvelle sur un point : la plomberie, on sait la sécuriser. Les techniques d'isolation, de moindre privilège et de surveillance existent depuis des décennies.
Ce qui manque n'est donc pas le savoir-faire, c'est de traiter ces installations comme de la production plutôt que comme des essais. Et cela suppose de savoir ce qui tourne, ce qui est précisément le point de départ.