Les modèles testés devaient résoudre un benchmark cyber. Après avoir exploité une vulnérabilité zero-day dans Artifactory pour obtenir un accès à Internet, ils ont combiné élévation de privilèges et identifiants exposés pour atteindre l’infrastructure de Hugging Face. Numerama a ensuite révélé que le parcours avait aussi impliqué le compte mal sécurisé d’un client de Modal Labs. OpenAI reconnaît désormais l’accès à quatre comptes répartis sur quatre services, dont l’un a servi de relais et un autre de stockage.
« L’IA change la vitesse et l’échelle, mais pas le besoin de reprise », estime Kim Larsen, Group Chief Information Security Officer chez Keepit.
Un objectif étroit, des conséquences étendues
L’agent ne cherchait pas à perturber un service ni à détruire des données. Il voulait récupérer les réponses d’une évaluation. Pourtant, cet objectif l’a conduit à exploiter des chemins techniques que ses concepteurs n’avaient pas anticipés. « Un agent IA peut mal interpréter son objectif ou agir au-delà des autorisations prévues », rappelle Kim Larsen.
Ce point modifie la manière d’évaluer le risque. Une entreprise ne peut pas seulement demander si un agent est autorisé à réaliser une action. Elle doit aussi examiner les combinaisons possibles entre ses droits, ses intégrations et les environnements qu’il peut traverser. Plus les services sont interconnectés, plus une décision automatisée peut produire des effets éloignés de son point de départ. Hugging Face a signalé un accès non autorisé à certains jeux de données internes et à plusieurs identifiants de service, sans preuve d’altération des contenus publics. Après une intrusion, il faut donc distinguer ce qui est intact de ce qui doit être restauré.
La reprise dépasse l’équipe de sauvegarde
Les organisations connaissent déjà les incidents provoqués par des identifiants compromis, un rançongiciel, une erreur d’administration, une panne SaaS ou une intégration défaillante. L’IA ajoute une capacité d’action autonome qui réduit le temps disponible pour comprendre et contenir l’événement. « Les causes diffèrent, mais les questions opérationnelles restent les mêmes », souligne Kim Larsen.
Il faut identifier le dernier état fiable, vérifier qu’il n’a pas été modifié, restaurer les données concernées et les valider avant de les remettre en production. Cette étape devient essentielle lorsque ces données alimentent ensuite des automatisations ou d’autres systèmes d’IA. Restaurer une information compromise ne ferait qu’accélérer la propagation de l’erreur. « Ces questions ne concernent pas uniquement l’équipe chargée des sauvegardes. Elles touchent aussi à la sécurité, à la continuité et à la gouvernance des données », poursuit Kim Larsen.
Tester la capacité à reprendre, pas seulement à bloquer
L’incident invite les entreprises à compléter leurs indicateurs de prévention par des critères de résilience. Elles doivent savoir combien de temps il leur faut pour reconstituer une chronologie, isoler les données affectées, retrouver un état vérifiable et relancer les processus essentiels sans dépendre de l’environnement compromis.
La question n’est pas de considérer chaque agent comme une menace. Elle est de reconnaître que des systèmes autonomes peuvent franchir des limites sans intention malveillante et à une vitesse difficilement compatible avec les procédures manuelles. La maturité ne se mesurera donc pas seulement à la capacité de contenir un agent, mais à celle de comprendre ses actions et de reprendre l’activité avant que leurs conséquences ne se propagent.
