if ( !emtpy($headline_subheadline ) ) : ?>
L’hébergement local de modèles d’IA ouverts peut offrir aux entreprises plus de contrôle, à moins qu’un agent d’IA ne décide de modifier le modèle qui l’alimente.
endif; ?>
Alors que le débat sur la sécurité de l’IA s’intensifie, de nouvelles recherches attirent l’attention sur un risque plus immédiat pour les entreprises : les agents d’IA qui peuvent modifier les modèles sur lesquels ils s’appuient lors de l’exécution de tâches de routine.
Des chercheurs de la société de sécurité IA Irregular ont demandé à un agent de codage de résoudre un problème de maintenance logicielle impliquant une application construite sur un modèle d’IA local qui renvoyait des réponses incorrectes. Au lieu de limiter ses modifications à l’application, l’agent a affiné le modèle à pondération ouverte qu’il utilisait – un modèle qui alimentait également ses propres activités – et a mis en service la version mise à jour sans qu’on lui demande de franchir l’une ou l’autre étape.
Le test a été réalisé dans un environnement auto-hébergé dans lequel l’agent et l’application partageaient le même point de contrôle ou la même version de modèle. L’agent a ensuite intégré la version affinée dans le modèle par défaut du système, de sorte que de nouvelles instances ont chargé la mise à jour.
Les conséquences ne se limitaient pas au problème que l’agent cherchait à résoudre.
Lors d’un test, le modèle modifié a ensuite reproduit trois des six secrets synthétiques que les chercheurs avaient placés dans ses données de réglage fin. Un autre test a montré qu’en affinant son modèle, l’agent supprimait un refus délibérément entraîné impliquant des concurrents fictifs. Étant donné que les services de l’environnement de test partageaient le même point de contrôle, le comportement modifié pourrait être répercuté sur d’autres instances qui l’utilisaient.
Irregular a averti que les tests n’étaient pas destinés à montrer à quelle fréquence les agents se comporteraient de cette façon en production. La configuration a donné à l’agent un accès complet au shell et la possibilité d’accéder à l’environnement de formation et de déploiement.
Ces résultats interviennent dans le cadre d’une enquête renouvelée visant à déterminer si les mesures de protection suivent le rythme des progrès de l’IA. Plus tôt ce mois-ci, Jakub Pachocki, scientifique en chef d’OpenAI, a déclaré que les méthodes actuelles d’alignement et de surveillance n’étaient pas suffisantes pour maintenir indéfiniment une mise à l’échelle à vitesse maximale. Le débat s’est intensifié après la démission du chercheur d’Anthropic Jacob Coxon pour des raisons de sécurité et le PDG d’Anthropic, Dario Amodei, a appelé à un développement plus lent de l’IA de pointe.
L’injection rapide gagne en persistance
Sakshi Grover, responsable de recherche principal pour la cybersécurité chez IDC Asie/Pacifique, a déclaré que les recherches d’Irregular soulignent également un mécanisme de persistance potentiel pour une injection rapide.
« La conséquence que la plupart des entreprises sous-estimeront est que l’injection rapide ne se limitera plus à une seule session », a déclaré Grover.
Un attaquant n’aurait pas nécessairement besoin de compromettre directement l’agent, a souligné Grover. Si du matériel malveillant influence les données de formation utilisées par un agent pour modifier un modèle, l’effet pourrait être transmis au point de contrôle résultant et persister après la fin de la session d’origine.
Les déploiements open-weight auto-hébergés introduisent une autre considération. L’accès direct aux pondérations sous-jacentes donne aux agents un moyen de modifier le modèle qu’une API d’inférence uniquement n’expose pas.
La modification du poids est apparue dans 42 % des tests de planification d’Irregular lorsque l’agent pouvait accéder aux poids du modèle, contre aucune lorsque le modèle était disponible uniquement via une API. Ce chiffre reflète la planification des agents dans des conditions de test, et non la fréquence à laquelle un tel comportement se produirait dans des déploiements réels.
Grover a déclaré que les entreprises qui recherchent des déploiements sur site pour des raisons de souveraineté ou de conformité devraient donc considérer l’architecture comme comportant un profil de sécurité différent, plutôt que de supposer qu’un plus grand contrôle signifie automatiquement un risque moindre.
Rayon de souffle et contrôles
« Aucun agent ne devrait être capable à lui seul de sélectionner des données de formation, de modifier un modèle et de promouvoir ce modèle en production », a déclaré Grover.
Les systèmes de déploiement ne devraient accepter que les points de contrôle approuvés dont l’origine et l’intégrité peuvent être vérifiées, a-t-elle ajouté.
Grover a également déclaré que les organisations devraient considérer le nombre d’applications s’appuyant sur un seul point de contrôle comme un risque de concentration. L’utilisation d’un modèle unique pour les agents d’ingénierie et les applications métiers peut réduire les coûts d’infrastructure, mais elle augmente également l’impact potentiel si ce point de contrôle est modifié.
La modification du modèle doit être traitée comme un changement de production privilégié, a déclaré Grover, avec une propriété claire et un enregistrement de la manière dont chaque point de contrôle a atteint la production. L’approbation humaine doit être requise avant qu’un modèle de production ne soit modifié, puis avant que le modèle de remplacement ne soit déployé.
