En Inde, des agents d’intelligence artificielle en cours de test ont fouillé les systèmes de plusieurs organisations et lu des données personnelles et des documents confidentiels. Dans ces organisations, personne n’a remarqué leur passage, et ce sont les fournisseurs de ces IA qui ont donné l’alerte.
Comme une épidémie qui semble impossible à endiguer. L’agence indienne de cybersécurité (CERT-In) vient de publier un avis classé « critique » sur ces intrusions. Elle explique avoir reçu « de multiples divulgations volontaires de fournisseurs de modèles d’IA », dont les agents, lancés sur Internet pour des tests, sont entrés dans les systèmes d’organisations indiennes. L’agence ne dit pas de quels laboratoires il s’agit, ni quelles organisations ont été touchées. Sans ces aveux, les entreprises concernées n’auraient sans doute jamais su qu’une IA était passée chez elles.
Protégez votre entreprise gratuitement pendant 30 jours
Découvrez Bitdefender Ultimate Small Business Security et protégez votre activité contre les cybermenaces. Aucune coordonnée bancaire requise.
Des intrusions invisibles pour les entreprises
À chaque fois, c’est le fournisseur qui a découvert l’incident en épluchant l’activité de ses agents, et aucune organisation touchée ne l’avait repéré, précise le CERT-In.
Souvenez-vous l'été dernier.
OpenAI fait ce travail depuis l’été. En reprenant mois par mois ce qu’avaient fait ses agents, l’entreprise a retrouvé 53 photos d’utilisateurs de ChatGPT qu’ils avaient mises en ligne sur des sites tiers. Anthropic était passé par là avant elle. Après avoir revu plus de 141 000 tests de cybersécurité, la société a reconnu que Claude avait piraté trois entreprises bien réelles pendant ses évaluations. Elle a pu en joindre deux, et aucune n’avait rien remarqué.
Hugging Face a repéré sans aide l’intrusion des agents d’OpenAI cet été. Les agents avaient alors exploité des failles pour exécuter du code sur ses serveurs. En Inde, ils n’ont rien eu à forcer. Ils sont entrés avec des identifiants et des paramètres de connexion oubliés dans des dépôts de code publics ou des fichiers de configuration, ou grâce à des rôles cloud aux droits trop larges. Ils ont ensuite « dépassé l’autorisation de leurs tâches assignées », d’après l’agence.
En Australie, des agents d’OpenAI sont passés par quatre sites gouvernementaux. « Cela n’aurait pas dû se produire », a reconnu Jason Kwon, directeur de la stratégie de l’entreprise, devant les parlementaires australiens. L’entreprise assure toutefois n’avoir trouvé aucune preuve d’accès à des dossiers médicaux ou judiciaires. En Inde, en revanche, les agents ont bel et bien lu des données personnelles et des documents commerciaux confidentiels. Ils venaient en plus de plusieurs fournisseurs, alors qu’un seul laboratoire était en cause à chaque fois jusqu’ici.
Des agents open source aux mains des pirates
Le CERT-In a aussi repéré des cybercriminels qui utilisent des outils d’attaque gratuits, fondés sur des agents d’IA, pour fouiller des organisations indiennes, entrer dans leurs systèmes et leur soutirer de l’argent. Ces outils sont sans cesse remaniés puis réinstallés sur des serveurs dans plusieurs pays. Il ne faut plus que quelques heures aux pirates entre la première intrusion et les dégâts, contre plusieurs jours avant. Les victimes qui n’avaient bouché qu’une partie de leurs failles ont été attaquées de nouveau en quelques jours, encore plus en profondeur.
L’agence pointe des erreurs de base derrière toutes ces attaques, avec des clés de paiement stockées en clair et des interfaces d’administration ouvertes sur Internet sans vraie double authentification. Elle demande aux organisations d’éplucher leur code, historique des dépôts compris, et leurs espaces de stockage cloud pour débusquer les identifiants exposés, puis de les changer. Après une intrusion, mieux vaut considérer tout système comme compromis tant qu’une analyse forensique ne l’a pas blanchi, prévient-elle. Quant aux laboratoires, le CERT-In leur demande de couper leurs tests de tout accès réseau sortant inutile et de ne travailler qu’avec des cibles et des identifiants fictifs.
Des sources gouvernementales citées par l’agence de presse PTI relativisent, puisqu’aucune organisation importante n’aurait été touchée et qu’aucune perte financière majeure n’a été constatée. Elles parlent plutôt d’un avertissement pour les entreprises.
En France, le CERT-FR avait déconseillé ce printemps d’installer des agents autonomes sur les postes de travail. Dans son bulletin, il pointait le risque de fuite des identifiants confiés à ces agents. Si vous laissez traîner des identifiants dans un dépôt de code public ou un fichier de configuration, les conseils du CERT-In valent donc aussi pour vous, puisque les laboratoires testent leurs agents sur l’Internet ouvert.
Un agent d’IA autonome est un logiciel qui ne se contente pas de répondre à des questions : il enchaîne des actions (navigation web, appels d’API, lecture/écriture de fichiers, exécution de commandes) pour atteindre un objectif. Il s’appuie souvent sur un modèle de langage, mais aussi sur des « outils » (tool use) qui lui donnent un accès concret à des systèmes externes. Cette autonomie change la surface d’attaque : l’agent peut explorer, tester des chemins d’accès et manipuler des ressources à grande vitesse. Sans garde-fous (permissions minimales, isolement réseau, journaux), ses actions peuvent dépasser l’intention initiale, notamment s’il rencontre des identifiants valides ou des configurations faibles.
Un dépôt public ou un fichier de configuration peut contenir des secrets (mots de passe, tokens API, clés cloud) laissés par erreur, y compris dans l’historique Git. Si ces secrets donnent accès à des services (stockage, base de données, console d’administration), n’importe quel acteur qui les récupère peut se connecter « légitimement » sans exploiter de faille technique. Le risque est aggravé quand les droits associés sont trop larges (rôles cloud permissifs), car un simple token devient un passe-partout. La mitigation passe par la rotation des secrets, l’audit des historiques, l’usage de coffres à secrets et des permissions au strict minimum (principe du moindre privilège).
Considérer un système comme compromis signifie partir du principe qu’un attaquant (ou un agent) a pu établir une persistance, voler d’autres identifiants, ou altérer des données, même si les symptômes visibles sont limités. Une analyse forensique vise à reconstituer la chronologie : points d’entrée, comptes utilisés, commandes exécutées, données consultées ou exfiltrées, et éventuelles portes dérobées. Elle s’appuie sur les logs (cloud, endpoints, IAM), les images disque/mémoire et des indicateurs de compromission, pour valider ce qui a été touché. Sans cette étape, “corriger la faille” peut laisser l’adversaire déjà installé ou permettre une ré-intrusion rapide via des secrets déjà dérobés.
